Работая над защитой интернет-магазина одного из клиентов, мы несколько раз столкнулись с любопытной brute-force атакой, противостоять которой оказалось не так просто. В основе её лежало простое до изящества решение, выделявшее атаку из рядов ей подобных. Что она собой представляла и как мы от неё все-таки защитились, читайте под катом.
Как вы знаете, «классический» brute-force — это атака методом перебора данных. Например, берутся известные учётные записи, и к ним подбираются по каким-то критериям пароли, либо генерируемые на лету, либо на основе украденных словарей. Это базовый метод взлома аккаунтов.
А в описываемом мной случае злоумышленники действовали немного иначе. Во-первых, они использовали большой, распределённый по разным странам ботнет из нескольких сотен заражённых компьютеров. В системе мониторинга всё выглядело так, словно это были совершенно разные компьютеры, либо прокси-серверы, за которыми сидели реальные люди и обращались к сайту. Такая атака долго может оставаться незамеченной.
Второй особенностью атаки, помимо сильной географической распределённости, был перебор не паролей, а логинов. Вероятно, злоумышленники использовали словари популярных паролей и украденные списки логинов. И сначала к известному паролю брался один логин, затем другой, третий и так далее. Было очень похоже на ситуацию, когда обычные пользователи, подключённые через одного провайдера, никак не могут залогиниться со своими паролями. То есть на первый взгляд ничего криминального. К тому же обращения к ресурсу были очень редкими – одно-два в минуту.
Третья особенность атаки была в том, что у ботнета было очень «человеческое» поведение: клиенты обрабатывали JavaScript, принимали куки.
Из-за этого комплекса факторов атака довольно долго оставалась незамеченной. Когда мы её все же обнаружили, то задались нетривиальным вопросом: как защищаться? У всех компьютеров ботнета не было каких-то особых отличительных признаков, за исключением определённой ошибки в user agent’е. Но мы не стали блокировать атаку на основе этого признака, потому что в таком случае перестали бы видеть действия злоумышленника. Нужно было выделить какие-то другие аномалии. С точки зрения IP-адресов ничего особенного не происходило. Блокировать логины, которые совершают большое количество неуспешных попыток входа, тоже нельзя, потому что частота очень низкая, и перебирается не пароль, а логин. Оставался один-единственный способ — внедрять капчу. Но заказчик очень не хотел этого делать, поскольку считал, что капча может оттолкнуть многих клиентов. А тем временем злоумышленникам уже удалось подобрать правильные комбинации к некоторым учётным записям.
Наверняка вы недоумеваете: зачем кому-то взламывать аккаунты клиентов интернет-магазина? Дело в том, что в личном кабинете накапливаются бонусные баллы, которые можно использовать для получения скидки на товары. Вероятно, кому-то очень хотелось закупиться или продать бонусные баллы в интернете.
В итоге мы уговорили клиента внедрить капчу средствами F5: она должна была появляться после заданного числа неуспешных входов. Но для начала нужно было настроить в системе критерии успешности входа. Это оказалось чуть сложнее, чем выглядело, потому что в некоторых случаях ресурс даёт одинаковый код ответа на любые попытки входа. В качестве критерия успешности входа мы выбрали передачу клиенту доменного куки.
В последней версии F5 ASM появилась возможность реагировать на попытки подбора с точки зрения Device ID — уникального идентификатора браузера. В страницу добавляется JS-код, и когда зараженная машина открывает эту страницу, то сообщает свой уникальный идентификатор. В случае с нашими злоумышленниками получилось так, что Device ID браузера был одним и тем же для каждого IP-адреса. То есть фактически с одного IP-адреса обращался один браузер.
Поэтому можно задать следующий критерий: если с одного браузера в течение 15 минут совершается больше 5 неуспешных попыток входа, то этому клиенту показывается капча. Если это действительно нормальный пользователь, он её решит и спокойно залогинится. На случай, если браузер не поддерживает JavaScript, мы добавили исключения. Но, чтобы не ослабить защиту, использовали другой критерий: если с одного IP-адреса делается больше 20 неуспешных попыток входа, опять предлагается капча. Опять же: для нормального пользователя это не создаст проблем.
Но сегодня уже есть методы обхода защиты с помощью капчи. Например, ботнеты пересылают капчи на «аутсорсинг» — в Китай или Индию, где трудолюбивые местные жители за небольшое вознаграждение решают капчи и возвращают текстовые значения. Но и в этом случае можно предпринять соответствующие меры: даже если при решённых капчах попытки входа неуспешны, можно блокировать запросы с определенного IP или Device ID при превышении заданного числа неуспешных попыток.
Последний раз, когда интернет-магазин атаковали таким образом, мы обошлись капчей, и это сработало. После ее внедрения brute-force атака постепенно стала затухать и в конце концов прекратилась. С тех пор прошло около года — рецидивов не было.
Андрей Черных, эксперт Центра информационной безопасности «Инфосистемы Джет»
Автор: JetHabr
