5 сентября «Яндекс» выдержал крупнейшую в истории рунета DDоS-атаку. Ее инициатором оказался ботнет нового типа Mēris, управляющий более 200 тыс. зараженными сетевыми устройствами, предположительно производителей Mikrotik и Linksys. В настоящее время происходит рост мощностей этого ботнета, в том числе за счет получения им доступа все к большему парку сетевых устройств. В атаке на «Яндекс» мощность ботнета достигала почти 21,8 млн RPS (запросов в секунду). Это была крупнейшая в истории зарегистрированная атака на уровне приложения (L7 DDoS attack).
Партнер «Яндекса» компания Cloudflare подтвердила факт атаки и то, что она была самой мощной за последнее время.
В конце августа 2021 года Cloudflare рассказала, что предотвратила крупнейшую из зарегистрированных ранее DDoS-атак — в пике до 17,2 млн запросов в секунду. Cloudflare пояснила, что атака была нацелена на одного из клиентов компании, занимающимся финансовыми операциями. Злоумышленник задействовал в ней ботнет из более чем 20 тыс. зараженных устройств в 125 странах мира, чтобы отправлять HTTP-запросы в сеть клиента в течение нескольких часов. Судя по IP-адресам, большинство запросов в ходе атаки приходило из Индонезии, Индии и Бразилии.
15 сентября 2021 года MikroTik признала, что часть ботнета Mēris была из ее устройств. Компания согласилась с названием этой сети зараженных устройств, которое дали в Qrator Labs и «Яндексе». MikroTik выпустила инструкцию для пользователей, чтобы проверить сетевое устройство на возможность перехвата управления от Mēris.
MikroTik уточнила, что ботнет Mēris управляет сетевыми устройствами, которые были взломаны в 2018 году с использованием уязвимости RouterOS под номером CVE-2018-14847. Производитель тогда постарался оперативно исправить эту уязвимость, но до сих пор многие пользователи не обновили свои устройства или забыли после обновления сменить пароль.
Расследование еще продолжается, но в «Яндексе» считают важным поделиться уже собранной информацией со всей индустрией.
В конце июня 2021 года команда «Яндекса» и коллеги из Qrator Labs начали замечать признаки новой атакующей силы в глобальной сети – ботнета нового типа. Обнаруженный ботнет уже тогда обладал значительными масштабами – десятки тысяч устройств, но их количество быстро росло. Qrator Labs наблюдали 30 000 хостов в отдельных атаках, в «Яндексе» собрали данные о 56 000 атакующих устройств. Но в «Яндексе» предполагали, что истинное количество значительно больше – вероятно, более 200 000 устройств. Полная сила ботнета не видна была из-за ротации устройств и отсутствия у атакующих желания показывать всю имеющуюся мощность. Более того, устройства в ботнете являются высокопроизводительными, а не типичными девайсами «интернета вещей», подключенными к сети Wi-Fi. С наибольшей вероятностью ботнет состоит из девайсов, подключенных через Ethernet-соединение, – в основном, сетевых устройств.
Некоторые организации уже окрестили этот ботнет «вернувшимся Mirai». Но в «Яндексе» не считают такое определение в достаточной степени точным. Mirai обладал большим количеством зараженных устройств, объединенных под управлением единого командного центра, и атаковал он, в первую очередь, трафиком сетевого уровня.
Коллеги из Qrator Labs выбрали Mēris – по-латышски «чума». Такое название кажется уместным и относительно близким к Mirai по произношению.
Особенности ботнета Mēris:
- Использование конвейерной обработки (pipelining в HTTP/1.1) для организации DDoS-атак (подтверждено)
- Атаки ориентированы на эксплуатацию RPS (подтверждено)
- Открытый порт 5678/TCP (подтверждено)
- SOCKS4-прокси на зараженном устройстве (не подтверждено, хотя мы знаем, что устройства Mikrotik используют SOCKS4)
Несколько записей на форуме производителя указывают, что пользователи устройств Mikrotik с 2017 года замечали попытки взлома на старых версиях RouterOS, особенно 6.40.1. Если это правда, то имеется уязвимость, все еще активная на десятках тысяч устройств, которые не обновляются, – это очень плохие новости. Однако данные «Яндекса» и Qrator Labs указывают, что это, скорее всего, не так. В ботнете видно множество версий RouterOS последних трех лет – вплоть до последней стабильной. Наибольшая доля приходится на предпоследнюю версию.
Еще один достаточно очевидный момент – ботнет продолжает расти. В «Яндексе» есть предположение, что он может разрастаться за счет техники брутфорса (перебора паролей), хотя этот вариант не кажется основным. Вся ситуация больше указывает на то, что уязвимость либо хранилась в секрете до начала полномасштабной кампании, либо была продана на черном рынке.
В задачи команды «Яндекса» не входило исследование первопричин и поиск виновных – по этому они сосредоточились на дальнейших наблюдениях.
В последние время все мы стали свидетелями разрушительных DDoS-атак в Новой Зеландии, США и России. Все эти атаки в «Яндексе» ассоциируют с ботнетом Mēris. В настоящий момент он может перегрузить практически любую сетевую инфраструктуру, включая некоторые сети высокой надежности, специально созданные, чтобы выдерживать подобную нагрузку. Главный признак ботнета – чудовищный показатель RPS.
Cloudflare была первой компанией, которая публично рассказала об атаках подобного масштаба. В посте в блоге от 19 августа они упоминали об атаке, достигшей 17 млн запросов в секунду. «Яндекс» сообщил Cloudflare, что в сентябре наблюдали схожую картину по продолжительности и распределению стран-источников.
«Яндекс» стал одной из компаний, испытавших на себе возможности ботнета Mēris. К счастью, техническая команда «Яндекса» смогла нейтрализовать атаку и предотвратить отказ в обслуживании. Атака не повлияла на работу сервисов, и данные пользователей не пострадали. Хотя цифры все еще ошеломляют – почти 21,8 млн RPS. Это крупнейшая в истории зарегистрированная атака на уровне приложения (L7 DDoS attack).
А вот статистика роста масштаба атак ботнета Mēris на Яндекс:
7 августа – 5,2 млн RPS
9 августа – 6,5 млн RPS
29 августа – 9,6 млн RPS
31 августа – 10,9 млн RPS
5 сентября – 21,8 млн RPS
Службе информационной безопасности «Яндекса» удалось установить детали внутреннего устройства ботнета. Для взаимодействия внутри сети используются обратные L2TP-туннели, а количество зараженных устройств достигает 250 000.
Как именно «Яндекс» выдержал такое огромное количество запросов в секунду?
В «Яндексе» входящий трафик пользователей проходит через несколько инфраструктурных компонентов, работающих на разных уровнях модели ISO/OSI. Первые компоненты защищают «Яндекс» от SYN-флуд-атак. Следующие слои анализируют входящий трафик в режиме реального времени. На основе технических сигналов и других статистик система оценивает подозрительность каждого запроса. В «Яндексе» приоритет – выдать ответ живым пользователям даже в момент DDoS-атаки. Благодаря устройству инфраструктуры «Яндекса» удалось быстро горизонтально отмасштабировать компоненты уже после первых атак и «Яндекс» смог выдержать более мощные волны, не переключаясь в режим бана по IP.
Источники атак (IP-адреса), которые в данном случае не подменяются (не спуфятся), по всей видимости похожи в том, что у них открыты порты 2000 и 5678. Конечно, многие производители устройств размещают на этих портах собственные сервисы. Однако конкретная комбинация порта 2000 с «Bandwidth test server» и порта 5678 с «Mikrotik Neighbor Discovery Protocol» почти не оставляет почвы для сомнений в выводах команды «Яндекса». Хотя Mikrotik использует UDP для своего стандартного сервиса на порту 5678, на скомпрометированных устройствах обнаруживается открытый TCP-порт. Такая маскировка может быть одной из причин того, что владельцы зараженных устройств не замечали их странного поведения.
Основываясь на этом, в «Яндексе» решили проверить TCP-порт 5678 с помощью Qrator.Radar. Полученные данные удивляют и пугают одновременно.
Оказывается, в глобальной сети существует 328 723 активных хоста, отвечающих на запросы пробы по TCP на порту 5678. Конечно, не обязательно каждый из них – это уязвимый Mikrotik. Есть данные о том, что устройства Linksys тоже используют внутренний TCP-сервис на порту 5678. Возможно, Mikrotik и Linksys не единственные, но у команды «Яндекса» не было другого выбора, кроме как предположить, что 328 723 – это и есть число хостов в активном ботнете.
Важно, что открытый порт 2000 отвечает на входящее соединение цифровой подписью \x01\x00\x00\x00, которая принадлежит протоколу RouterOS. Поэтому мы считаем, что это не случайный сервер для тестирования пропускной способности, а вполне идентифицируемый.
Цитируя неофициальное описание протокола на GitHub:
Официального описания нет, поэтому все было получено с помощью инструмента WireShark и RouterOS 6, запущенной в виртуальной машине, которая подключалась к реальному устройству. (...)
Установив TCP-соединение с портом 2000, сервер всегда сначала посылает команду «hello» (01:00:00:00). Если в клиенте указан протокол UDP, TCP-соединение все еще устанавливается.
По наблюдениям «Яндекса», 65% атакующих устройств открывают SOCKS4-прокси на порту 5678, а 90-95% открывают Bandwidth test на порту 2000.
Использование конвейерной обработки HTTP (так это обозначается в HTTP/1.1, а в HTTP/2 это «мультиплексирование») делает нейтрализацию подобных атак давно забытой задачей. Дело в том, что сетевые устройства обычно установлены у легитимных пользователей. Невозможно быть уверенным, что конечная точка полностью скомпрометирована, превращена в «бота-зомби» и что в трафике атаки не занята лишь часть полосы (а остальная используется в безобидном трафике живого пользователя). В конце концов, на каком-то ресурсе могут быть зарегистрированы пользователи, пытающиеся попасть на него, даже используя скомпрометированные устройства.
Поскольку конвейерная обработка заставляет принимающий сервер отвечать на целый пакет мусорных запросов от одного источника, значит, оптимизация фронтенда может нанести еще больший ущерб при попытке ответить на каждый входящий запрос. Идет речь именно о HTTP-запросах, на которые тратится бóльшая часть используемой вычислительной мощности сервера (тем более при защищенном соединении, когда к обработке незашифрованных запросов добавляется криптографическая нагрузка).
Конвейерная обработка – основной источник проблем для всех, кто встретит этот ботнет на своей инфраструктуре. Хотя браузеры (за исключением Pale Moon) в основном не используют конвейерную обработку, боты это делают, и с большим удовольствием. Такие запросы легко распознать и нейтрализовать, ведь все-таки общепринятый в интернете консенсус относительно обработки запросов выглядит как «запрос – ответ», а не как «запрос – запрос – запрос – запрос – ответ».
В «Яндексе» наблюдали реализацию стратегии «качество против количества». Из-за конвейерной обработки запросов злоумышленники могут выжать гораздо больше запросов в секунду по сравнению с «обычными» ботнетами. В том числе – потому, что классические методы нейтрализации попытаются заблокировать атакующий IP-адрес. Однако порядка 10-20 запросов, оставшихся в буферах, будут обработаны даже после этого.
Что делать «Яндекс» в такой ситуации?
Черные списки все еще работают. Поскольку в этих атаках не происходит подмены IP-адреса источника (нет спуфинга, как уже было упомянуто), каждая жертва видит источник атаки таким, какой он есть на самом деле. Блокировки на короткий промежуток времени должно быть достаточно, чтобы предотвратить атаку и не побеспокоить конечного пользователя.
Неясно, как владельцы ботнета будут действовать в будущем. Они могут воспользоваться скомпрометированными устройствами полностью, в попытке использовать 100% доступной мощности (и по пропускной, и по вычислительной способности). Тогда «Яндексу» не останется другого способа, кроме как блокировать каждый запрос, следующий за первым от одного источника, предотвращая обработку запросов в пайплайне.
Если на целевом сервере отсутствует защита от DDoS-атак, то не только конвейерная обработка запросов может стать катастрофой, поскольку злоумышленнику потребуется гораздо меньше «рабочей силы», чтобы заполнить порог RPS жертвы. Оказалось, очень многие не были готовы к подобному сценарию.
Что дальше?
«Яндекс» направил всю собранную информацию в профильные организации. Будем надеется, что совместные усилия позволят интернету вскоре избавиться от пандемии этой «чумы».
#Meris #яндекс #ddos #mikrotik #mirai