Редкий представитель вида brute-force: история одной атаки

В основе её лежало простое до изящества решение, выделявшее атаку из рядов ей подобных. Работая над защитой интернет-магазина одного из клиентов, мы несколько раз столкнулись с любопытной brute-force атакой, противостоять которой оказалось не так просто. Например, берутся известные учётные записи, и к ним подбираются по каким-то критериям пароли, либо генерируемые на лету, либо на основе украденных словарей. Что она собой представляла и как мы от неё все-таки защитились, читайте под катом.
Как вы знаете, «классический» brute-force — это атака методом перебора данных. Это базовый метод взлома аккаунтов.

Во-первых, они использовали большой, распределённый по разным странам ботнет из нескольких сотен заражённых компьютеров. А в описываемом мной случае злоумышленники действовали немного иначе. Такая атака долго может оставаться незамеченной. В системе мониторинга всё выглядело так, словно это были совершенно разные компьютеры, либо прокси-серверы, за которыми сидели реальные люди и обращались к сайту.

Вероятно, злоумышленники использовали словари популярных паролей и украденные списки логинов. Второй особенностью атаки, помимо сильной географической распределённости, был перебор не паролей, а логинов. Было очень похоже на ситуацию, когда обычные пользователи, подключённые через одного провайдера, никак не могут залогиниться со своими паролями. И сначала к известному паролю брался один логин, затем другой, третий и так далее. К тому же обращения к ресурсу были очень редкими – одно-два в минуту. То есть на первый взгляд ничего криминального.

Третья особенность атаки была в том, что у ботнета было очень «человеческое» поведение: клиенты обрабатывали JavaScript, принимали куки.

Когда мы её все же обнаружили, то задались нетривиальным вопросом: как защищаться? Из-за этого комплекса факторов атака довольно долго оставалась незамеченной. Но мы не стали блокировать атаку на основе этого признака, потому что в таком случае перестали бы видеть действия злоумышленника. У всех компьютеров ботнета не было каких-то особых отличительных признаков, за исключением определённой ошибки в user agent’е. С точки зрения IP-адресов ничего особенного не происходило. Нужно было выделить какие-то другие аномалии. Оставался один-единственный способ — внедрять капчу. Блокировать логины, которые совершают большое количество неуспешных попыток входа, тоже нельзя, потому что частота очень низкая, и перебирается не пароль, а логин. А тем временем злоумышленникам уже удалось подобрать правильные комбинации к некоторым учётным записям. Но заказчик очень не хотел этого делать, поскольку считал, что капча может оттолкнуть многих клиентов.

Дело в том, что в личном кабинете накапливаются бонусные баллы, которые можно использовать для получения скидки на товары. Наверняка вы недоумеваете: зачем кому-то взламывать аккаунты клиентов интернет-магазина? Вероятно, кому-то очень хотелось закупиться или продать бонусные баллы в интернете.

Но для начала нужно было настроить в системе критерии успешности входа. В итоге мы уговорили клиента внедрить капчу средствами F5: она должна была появляться после заданного числа неуспешных входов. В качестве критерия успешности входа мы выбрали передачу клиенту доменного куки. Это оказалось чуть сложнее, чем выглядело, потому что в некоторых случаях ресурс даёт одинаковый код ответа на любые попытки входа.

В страницу добавляется JS-код, и когда зараженная машина открывает эту страницу, то сообщает свой уникальный идентификатор. В последней версии F5 ASM появилась возможность реагировать на попытки подбора с точки зрения Device ID — уникального идентификатора браузера. То есть фактически с одного IP-адреса обращался один браузер. В случае с нашими злоумышленниками получилось так, что Device ID браузера был одним и тем же для каждого IP-адреса.

Если это действительно нормальный пользователь, он её решит и спокойно залогинится. Поэтому можно задать следующий критерий: если с одного браузера в течение 15 минут совершается больше 5 неуспешных попыток входа, то этому клиенту показывается капча. Но, чтобы не ослабить защиту, использовали другой критерий: если с одного IP-адреса делается больше 20 неуспешных попыток входа, опять предлагается капча. На случай, если браузер не поддерживает JavaScript, мы добавили исключения. Опять же: для нормального пользователя это не создаст проблем.

Например, ботнеты пересылают капчи на «аутсорсинг» — в Китай или Индию, где трудолюбивые местные жители за небольшое вознаграждение решают капчи и возвращают текстовые значения. Но сегодня уже есть методы обхода защиты с помощью капчи. Но и в этом случае можно предпринять соответствующие меры: даже если при решённых капчах попытки входа неуспешны, можно блокировать запросы с определенного IP или Device ID при превышении заданного числа неуспешных попыток.

После ее внедрения brute-force атака постепенно стала затухать и в конце концов прекратилась. Последний раз, когда интернет-магазин атаковали таким образом, мы обошлись капчей, и это сработало. С тех пор прошло около года — рецидивов не было.

Андрей Черных, эксперт Центра информационной безопасности «Инфосистемы Джет»