При освещении в СМИ вируса NotPetya не сообщалось, что он мог наделать еще больше зла. Например, брутфорс на парламент Великобритании. Это является еще одним напоминанием того, что brute force остается глобальной угрозой:
Это также наводит нас на важные вопросы — в первую очередь, как такое могло произойти:
Подобные проблемы заставляют задуматься о том, что нужно глубже исследовать этот тип атаки.
Определение brute force
На данный момент существуют два основных метода взлома в Сети: использование человеческих ошибок или догадки. Допущенные ошибки лежат в основе множества атак: фишинг (ошибка пользователя ), использование недостатков конфигурации (ошибка администратора ) или уязвимости нулевого дня (ошибка разработчика ). Но на предположениях основан другой тип атак — brute force .
Чаще всего брутфорс атаки используются для подбора учетных данных. Хотя их можно применять для взлома URL-адреса .
Классическая brute force атака — это попытка «угадать » пароль в ПК, когда злоумышленник завладел зашифрованным его значением.
Оно позволяет хакеру использовать мощные компьютеры для тестирования большого количества паролей без риска быть обнаруженным. С другой стороны, такая brute force атака не может быть первым этапом. Для этого злоумышленник должен уже иметь копию зашифрованных паролей.
Онлайн-атака — это, когда злоумышленник пытается взломать функцию входа в систему или приложение с помощью подбора учетных данных. Так как ему не нужно сначала получать зашифрованные пароли, хакер может использовать этот метод при попытке проникнуть в систему.
Имеют ли место brute force атаки онлайн?
Одновременно подобрать имя пользователя и пароль непросто. Большинство систем при неудачном входе в систему не сообщают, что было введено неверно: имя пользователя или пароль. Первый шаг, который предпринимает злоумышленник — это попытка атаковать известных пользователей.
Хакер может находить имена пользователей, используя открытые исследования. Во многих организациях, например, логины пользователей имеют предсказуемую структуру, основанную на имени сотрудника. Простой поиск в LinkedIn позволяет выявить большое количество имен пользователей.
Тем не менее, этот тип классической brute force атаки онлайн является скорее гипотетической. Причина проста: у большинства современных систем и приложений есть встроенная блокировка. Если пользователю не удается войти в систему за несколько попыток, учетная запись блокируется и для ее разблокировки требуется вмешательство администратора.
Сегодня такая защита от брутфорса создает больше головной боли для IT-отделов , чем для злоумышленников. Обработка таких блокировок становится более насущным вопросом, чем обнаружение brute force.
Исключение составляют пользовательские приложения. Хотя традиционный вход в Windows не может быть использован для brute force , новое веб-приложение, разработанное специально для предстоящей маркетинговой кампании, вполне для этого подходит.
Рост количества случаев credential stuffing
В то время как классические онлайн-атаки с использованием brute force , идут на убыль, credential stuffing только набирает обороты.
Credential stuffing — это атака, в которой злоумышленники используют пары имя пользователя / пароль, украденные с общедоступных сайтов, чтобы проникнуть в атакуемую систему.
Количество успешных атак на общедоступные сайты увеличивается, и злоумышленники публикуют базы учетных данных или продают их на подпольных биржах. Предположение, которое слишком часто оправдывается, заключается в следующем: люди используют одинаковое имя пользователя и пароль на разных сайтах.
Подбор пароля брутфорсом при Credential stuffing позволяет обойти блокировку, поскольку каждое имя пользователя вводится только один раз. Использование известной пары имя пользователя / пароль увеличивает вероятность успеха с меньшим количеством попыток.
Поскольку в качестве контрмеры блокировка не эффективна, организации часто применяют двухфакторные механизмы аутентификации. Двухфакторная аутентификация требует, чтобы у пользователя было что-то еще помимо пароля. Например, номер мобильного, на который пользователь может получить текстовое сообщение.
Поскольку двухфакторная аутентификация громоздка, успешная аутентификация обычно одобряется на основе любого «аналогичного » доступа. «Аналогичный » доступ может представлять собой использование одного и того же устройства или географического местоположения.
Многие из нас сталкивались с сайтами, требующими двухфакторной аутентификации при обращении с нового устройства, публичной сети или во время поездок.
Хотя двухфакторная аутентификация является надежным решением, она имеет существенные недостатки: при ней изменяется пользовательский интерфейс и она предполагает интерактивный вход в систему.
Нет ничего более раздражающего, чем натолкнуться на двухфакторную аутентификацию при входе со смартфона. В результате эта опция часто оставляется на усмотрение пользователя в качестве дополнительного варианта. Поэтому возникает необходимость в системе обнаружения, связанной с использованием аналитики, которая бы распознавала метод брутфорса.
Обнаружение brute force атак
Часто рекомендуемый метод обнаружения brute force атак связан с определением классических атак. Это обнаружение нескольких неудачных попыток входа в систему для одного пользователя за короткий промежуток времени.
Многие рекомендации для начинающих при создании правил корреляции SIEM (Security Information and Event Management ) делают упор на обнаружение brute force атак именно по такому сценарию. Хотя это изящный и простой путь, но он предназначен для определения практически несуществующего вектора атак.
Фактор, который дает возможность идентифицировать brute force атаку при аутентификации — это большое количество неудачных попыток входа в систему. Но поскольку пользователь не может быть ключом к обнаружению, система должна сосредоточиться на другом ключе, чтобы связать поток событий, составляющих атаку.
Один из методов — отслеживание неудачных попыток аутентификации с одного IP-адреса . Но публичные IP-адрес а становятся более дорогими, поэтому все больше пользователей получают общий IP-адрес .
Чтобы справиться с этой проблемой, механизм обнаружения должен определять нормальную скорость соединений или сбоев от исходного IP-адреса , чтобы установить, какой будет ненормальная скорость. Тем самым принимая во внимание тот факт, что несколько пользователей могут подключаться к одному и тому же IP-адресу .
Детектор также может использовать отпечаток устройства (комбинацию свойств в событии аутентификации, характерных для устройства ) для дифференциации конкретного источника из числа тех, которые используют один и тот же IP-адрес . Но это не может быть основным фактором, а лишь способствует проверке потенциального злоумышленника. Большинство таких отпечатков находятся под контролем злоумышленника и могут быть подделаны.
Распределенные брутфорс атаки, например, путем использования ботнета или перенаправления через сеть прокси-серверов TOR , еще больше усложняют задачу. Отслеживание источника становится неэффективным. Фильтрация устройств может работать до определенной степени. Особенно если атака выполняется одним источником, но через несколько маршрутов. В качестве дополнительной меры можно использовать информацию о потенциальных угрозах, которая помогает идентифицировать доступ с известных узлов бот-сетей или прокси-серверов.
Практика обнаружения атак
До сих пор мы предполагали, что события, анализируемые для установления атаки, являются ярко выраженными. Любое событие неудавшегося входа в систему определяется как успешная или безуспешная попытка, а имя пользователя всегда находится в одном поле и имеет один формат.
Но обработка потока событий для подготовки их к анализу и обнаружению брутфорс также является проблемой, которую нужно рассматривать отдельно.
В качестве примера возьмем Windows , самый распространенный источник. Событие входа в систему Windows (идентификатор события 4624 ) и событие неудачного входа Windows (идентификатор события 4625 ) регистрируются локально на каждом компьютере. Это делает более сложным сбор информации. Это также означает, что злоумышленник, который владеет компьютером, может заблокировать ее получение. Контроллер домена регистрирует событие аутентификации, которое может использоваться как прокси для события входа в систему.
Когда поймем, какие события отслеживать, нам все равно нужно знать, как правильно идентифицировать успешную или безуспешную попытки входа в систему. Успешная или безуспешная попытки локального входа — это отдельные события, которые для аутентификации контроллера домена помечаются внутри события.
Приведенные ниже результаты поиска в Splunk (в поисковом хранилище GoSplunk ), которые я использовал для идентификации успешных и безуспешных попыток входа в Windows , демонстрируют уровень знаний, необходимых для извлечения такой информации из событий. Это даже без учета аутентификации контроллера домена.
source="WinEventLog:security" (Logon_Type=2 OR Logon_Type=7 OR Logon_Type=10) (EventCode=528 OR EventCode=540 OR EventCode=4624 OR EventCode=4625 OR EventCode=529 OR EventCode=530 OR EventCode=531 OR EventCode=532 OR EventCode=533 OR EventCode=534 OR EventCode=535 OR EventCode=536 OR EventCode=537 OR EventCode=539) | eval status=case(EventCode=528, "Successful Logon", EventCode=540, "Successful Logon", EventCode=4624, "Successful Logon", EventCode=4625, "Failed Logon", EventCode=529, "Failed Logon", EventCode=530, "Failed Logon", EventCode=531, "Failed Logon", EventCode=532, "Failed Logon", EventCode=533, "Failed Logon", EventCode=534, "Failed Logon", EventCode=535, "Failed Logon", EventCode=536, "Failed Logon", EventCode=537, "Failed Logon", EventCode=539, "Failed Logon") | stats count by status | sort - count
Обнаружение атак через Cyber Kill-Chain
Обнаружение brute force атак является непростой задачей при защите от брутфорса WordPress . Ни один из методов обнаружения, описанных выше, не дает 100-процентной гарантии результата, а злоумышленники в свою очередь постоянно совершенствуют методы противодействия их обнаружению.
Брутфорс (от английского brute force — полный перебор или метод «грубой силы») – один из популярных методов взлома паролей на серверах и в различных программах. Заключается он в том, что программа-взломщик пытается получить доступ к какой-либо программе (например, к почтовому ящику) путем перебора паролей по критериям, заданным владельцем данной программы: по словарю, по длине, по сочетаниям цифр, да в принципе таких критериев существует множество.
Способ взлома брутфорсом является достаточно долгим, но мощным, поэтому остается на вооружении у хакеров и по сей день, а с учетом все увеличивающихся мощностей компьютеров и пропускной способности интернет-каналов останется на вооружении еще на долгое время.
Данный способ подбора паролей очень хорош тем, что пароль в конце концов взламывается, но это может занять весьма и весьма долгое время, зачастую даже столетия. Так что данный способ взлома оправдывает себя не всегда, если пользователь-владелец взламываемого сервиса вел себя достаточно хитро и не использовал простых паролей типа «123», «qwerty» и тому подобных, а использовал и заглавные, и строчные символы, плюс ко всему этому задействовал и цифры, и разрешенные специальные символы. Если пароль при всем этом обладает еще и достаточной длинной (около 10 символов), то ему взлом методом брутфорс а практически не грозит.
При брутфорсе чаще всего используется словарная атака – подбор паролей идет из текстового файла заранее составленного (выпрошенного, купленного, украденного, скачанного бесплатно) словаря. Данный способ атаки очень эффективен при массовом взломе, допустим, аккаунтов интернет-мессенджера ICQ, когда злоумышленник, допустим, пытается взломать некий диапазон ICQ-номеров. При этом существует довольно большая вероятность, что при атаке по словарю ему это удастся. Примерами могут служить неоднократные факты взлома.
С 2005 года значительно увеличилось также количество атак, осуществляемых на защищенные SSH-сервисы. Даже если у вас на сервере установлено самое новейшее программное обеспечение, это вовсе не значит, что подобрать пароль к нему невозможно, если межсетевой экран бездействует или настроен неправильно или недостаточно. Так что для увеличения невозможности взлома настройте свой файервол должным образом, это поможет оградить вас от неприятных сюрпризов в дальнейшем.
Программ для проведения брута на просторах Интернета выложено очень много, также существует большое количество бесплатных и платных словарей к ним.
Так что если вы крутой хакер и хотите все взломать, то дерзайте, а если законопослушный пользователь – усложняйте все свои пароли до недосягаемых для брутфорс а высот.
Ну и напоследок поговорим немного о математической стороне брута.
Как говорит Википедия, любая задача (!!!) из класса NP может быть решена путем полного перебора. Но все это может потребовать экспоненциального времени (!!!).
При разработке различных криптографических шифров метод тотального перебора используют при оценке его (шифра) стойкости к взлому. При этом новый шифр считается достаточно стойким, если не существует более быстрого метода его взлома, чем полный перебор всех возможных ключей. Такие криптографические атаки, как и брут , являются самыми действенными, но и занимают зачастую очень много времени.
При знании некоторых условий метод брута паролей использует отсев неприемлемых значений (пустых паролей, одних и тех же повторяющихся символов и т.д.). В математике этот метод называется метод ветвей и границ.
Также при брут е используются методы распараллеливания вычислений, когда одновременно перебираются несколько паролей. Осуществляется это двумя методами: методом конвейера и методом брут а из непересекающихся подмножеств всех возможных паролей.
На этом мы заканчиваем статью, посвященную брутфорсу, и очень надеемся, что приведенная в ней информация окажется вам, наш дорогой и уважаемый читатель, полезной как в хакинге, так и в развертывании компьютерных систем безопасности.
И хотя информация в статье является далеко не полной, но мы надеемся, что вы поняли из ее содержания, в каком направлении вам следует двигаться далее.
У каждого из команды ][ свои предпочтения по части софта и утилит для
пен-теста. Посовещавшись, мы выяснили, что выбор так разнится, что можно
составить настоящий джентльменский набор из проверенных программ. На том и
решили. Чтобы не делать сборную солянку, весь список мы разбили на темы – и в
этот раз коснемся утилит для подбора пароля к различным сервисам.
Brutus AET2
Платформа: Windows
Последний релиз программы был в 2000 году. У тулзы давно нет официального
сайта. Но при этом Brutus AET2
по-прежнему является одним самых шустрых и
продвинутых брутфорсеров для основных Интернет-протоколов. Если нужно подобрать
пароль для HTTP (на тех страничках, где используется авторизация по
логину/паролю), произвольному веб-сервису с авторизацией через форму, почтовому
аккаунту, файловому или Telnet серверу, знай: Brutus
– отличный вариант.
В общем случае для подбора пароля нужно указать хост и порт сервиса, выбрать
протокол, установить количество используемых потоков (максимум — 60), а также
таймаут. В целях анонимности можно подключить сокс или прокси. В зависимости от
протокола также указывается ряд дополнительных параметров. Например, для подбора
пароля на каком-то сайте (тип брутфорса — HTTP Form), необходимо указать метод
(POST или GET), обозначить параметры формы (в Brutus встроено простое средство
для их анализа), а в случае необходимости подделать cookie, включив
соответствующую опцию.
Подбор осуществляется двумя способами: по словарю, причем у проги есть
несколько встроенных утилит для работы с большими списками паролей, или же с
использованием тупо сгенерированных паролей. В последнем случае необходимо
обозначить символы, которые будут использоваться для составления пасса.
Не секрет, что попытки подбора пароля методом перебора (брутфорс) - постоянное явление. Подбирают пароли к серверам и виртуальным машинам, к админкам сайтов и FTP-аккаунтам, к почтовым ящикам и социальным сетям.
Обычно брутфорс идет в фоновом режиме и практически не заметен для владельцев ресурсов, т.к. не создает значительную нагрузку и не мешает работе сайта, по крайней мере до тех пор, пока злодеи не проникнут на сервер:)
1 августа началась, пожалуй, самая мощная в рунете брутфорс-атака на сайты, созданные с помощью самых распространенных бесплатных CMS: Wordpress, Joomla! и др.
И вот как это было:
Мода на мега-брутфорс дошла и до нас
Похожая атака на Wordpress-сайты была предпринята в апреле этого года. Эта атака затронула в основном западные ресурсы и российские пользователи и хостинг-провайдеры ее не заметили. На этот раз ботнет направлен прежде всего на взлом русскоязычных сайтов.
Первые публичные сообщения об атаке появились 2 августа. На самом деле, аномальная активность в нашей системе мониторинга была заметна еще первого числа. До этого нагрузка, создаваемая ботами, была не так заметна. Возможно, это были пробные запуски, но мы предполагаем, что активная работа началась с малого количества зараженных машин. По мере подключения новых участников, нагрузка на инфраструктуру росла и ко 2 августа ее почувствовали на себе все российские хостинг-провайдеры и их клиенты.
На графике выше может показаться, что что-то начало происходить еще 31 июля, я даже выделил этот момент красной линией. Как показало дальнейшее исследование, это была локальная аномалия, вызванная не началом атаки, а нагрузкой на одной из нод. По этому графику с детализацией легко выявить источник аномалии:
Зная ноду, можно углубиться дальше и узнать, кто именно создает нагрузку:
Как видим, повышенная активность в одном из клиентских виртуальных серверов. При этом у соседей по серверу все хорошо и на других нодах все в норме. Отсюда мы делаем вывод, что случай не имеет отношения к исследуемой атаке, т.е. большой брутфорс начался 1 августа.
Борьба с ботами
Поведение ботов было стандартным: они обращались к типовой странице авторизации CMS. Например, для WP это страница wp-login.php. В первой фазе атаки обращения были достаточно топорными: боты сразу делали POST логина и пароля в форму без предварительного получения страницы (GET). Таким образом, на этом этапе их было очень легко отличить от настоящих пользователей, которые сначала получали страницу, а потом уже вводили логин и пароль.Используя эту особенность, боты достаточно быстро были заблокированы. Естественно, после этого злоумышленники внесли коррективы в поведение ботов. Они научились делать GET-POST и работать с куками.
После этого из возможных вариантов прикрытия остались:
1) переименование страницы авторизации;
2) ограничение доступа к админскому разделу по ip-адресам (белый список, географический или иной принцип деления);
3) двойная авторизация.
Переименование страницы авторизации
хорошо подходит конкретно для Wordpress, т.к. в результате ничего не ломается и можно продолжать работу. Но не факт, что этот способ хорошо работает для других CMS. В системе вполне может быть привязка к конкретному названию скрипта.
Таким образом, этот способ не подходил для нас как хостинг-провайдера, т.к. мы просто не можем пойти и переименовать всем клиентам файлы без их ведома. Это может сделать только сам клиент.
Ограничение доступа к админке по белому списку ip-адресов подходит далеко не всем, т.к. во-первых, практически всегда интернет-провайдеры выдают динамический адрес, который может меняться от сессии к сессии, а во-вторых, это исключает возможность доступа к админке извне, например, с мобильного устройства. Этот вариант также был отметен, как нерабочий.
Ограничение по географической принадлежности ip работает только в случае, если у ботнета есть ярко выраженный «регион проживания», например, Вьетнам или Индия. Опять-таки для принятия единых мер на крупном хостинге такой способ не подходит, т.к. сразу находятся зарубежные клиенты, которые попадают под действие этих фильтров.
Двойная авторизация — способ, который мы в итоге применили к сайтам, подверженным атакам на нашем шаред-хостинге. Мы установили дополнительную страницу авторизации, которая выдается при попытке обращения к админке без определенных кук. Пройдя нашу дополнительную авторизацию один раз, легитимный пользователь получает особую куку и может спокойно войти в админку CMS. При этом боты не могут пройти через страницу и не только не могут осуществлять подбор пароля к CMS, но и не создают большой нагрузки на сервер.
Судя по новостям хостинг-провайдеров, многие воспользовались похожим методом, но установили жутко секретные пароли, узнать которые клиент мог только по запросу в техническую поддержку или в персональной электронной рассылке.
Мы сочли такой сверх-секретный подход избыточным и некорректным по отношению к клиентам. Порой доступ в админку нужен срочно, а писать заявку, звонить или искать искомое письмо от хостера может быть очень неудобно. Поэтому данные для дополнительной авторизации мы указали на странице в явном виде, исходя из простого предположения, что боты не умеют читать и думать, а учить их конкретно для нашего случая - слишком трудоемкое и неблагодарное злодейское занятие.
Примерно так выглядит страничка с дополнительной авторизацией (простите, было не до красивого оформления страницы):
Также мы отказались от использования классической http-авторизации по причине того, что всплывающее окно с запросом логина и пароля - не самый удобный способ рассказать клиенту что случилось с его CMS и отчего он видит этот запрос. Такое окно блокирует браузер, пугает и мешает сориентироваться.
Наблюдения
Помимо борьбы с ботами нам было весьма интересно понаблюдать за тем, как координируются и распределяются их усилия. Судя по аналитике из нашей системы, количество одновременных запросов на 1 хостинговый ip-адрес устойчиво держалось не более 30 для каждой CMS, вне зависимости от количества атакуемых сайтов на этом адресе. Таким образом, если на одном ip-адресе размещались сайты и на Wordpress, и на Joomla!, то количество одновременных обращений держалось на уровне 60 штук. Это достаточно много для shared-хостинга.Если сайт переставал отвечать — запросы к нему мгновенно прекращались. Это разумно, т.к. злоумышленникам выгоднее оставить жертву в живых. Тем не менее, 60 одновременных запросов — достаточно большой поток, чтобы его гарантированно заметили и владельцы сайтов, и хостинг-провайдеры. Есть мнение, что злодеям разумнее было бы брутфорсить в 3-4 раза меньшим потоком запросов. В этом случае деятельность ботнета была бы гораздо менее заметна.
Активная фаза атаки начиналась вечером и продолжалась всю ночь. Адреса сайтов ботам отдавались в алфавитном порядке.
Таким образом, вечером начинали страдать сайты на букву А, а ближе к утру — сайты на Z. Им в этом смысле повезло чуть больше.
И вновь продолжается бой
Сейчас атака все еще продолжается, хотя и в существенно сниженном темпе. Нам удалось минимизировать ущерб от атаки для пользователей shared-хостинга. В зоне риска остаются пользователи выделенных физических и виртуальных серверов, т.к. централизованно прикрыть доступ к админке CMS в этом случае нельзя и меры по защите должны быть приняты администратором сервера.Спасибо за внимание! :)
Всем успехов в борьбе с ботами. способы для самостоятельной защиты озвучены выше. Если у вас есть классный готовый рецепт — прошу в комменты!
