Ботнет Mēris: расследуем крупнейшую DDoS-атаку в истории интернета
На днях в СМИ появилась информация о DDoS-атаке на Яндекс. Это правда, но не вся. Нашим специалистам действительно удалось отразить рекордную атаку более чем в 20 млн RPS — это самая крупная атака из известных за всю историю интернета. Но это лишь одна из множества атак, направленных не только на Яндекс, но и на многие другие компании в мире. Атаки продолжаются уже несколько недель, их масштабы беспрецедентны, а их источник — новый ботнет, о котором пока мало что известно.
Сегодня вместе с коллегами из Qrator Labs мы хотим поделиться текущими результатами совместного расследования деятельности нового ботнета Mēris. Расследование еще продолжается, но мы считаем важным поделиться уже собранной информацией со всей индустрией.
В конце июня 2021 года и мы в Яндексе, и наши коллеги из Qrator Labs начали замечать признаки новой атакующей силы в глобальной сети — ботнета нового типа. Обнаруженный ботнет уже тогда обладал значительными масштабами — десятки тысяч устройств, но их количество быстро растет и сейчас. Qrator Labs наблюдали 30 000 хостов в отдельных атаках, мы в Яндексе собрали данные о 56 000 атакующих устройств. Но мы предполагаем, что истинное количество значительно больше — вероятно, более 200 000 устройств. Полная сила ботнета не видна из-за ротации устройств и отсутствия у атакующих желания показывать всю имеющуюся мощность. Более того, устройства в ботнете являются высокопроизводительными, а не типичными девайсами «интернета вещей», подключенными к сети Wi-Fi. С наибольшей вероятностью ботнет состоит из девайсов, подключенных через Ethernet-соединение, — в основном, сетевых устройств.
Некоторые организации уже окрестили этот ботнет «вернувшимся Mirai». Но мы не считаем такое определение в достаточной степени точным. Mirai обладал большим количеством зараженных устройств, объединенных под управлением единого командного центра, и атаковал он, в первую очередь, трафиком сетевого уровня.
У нас еще не было возможности изучить пример вредоносного кода, который используется для заражения новых устройств данного ботнета, и мы не готовы утверждать, относится он к семейству Mirai или нет. Пока считаем, что нет, поскольку устройства, объединенные под единым командным центром, похоже, относятся только к производителю Mikrotik.
Это и есть причина, по которой мы хотели дать другое имя новому ботнету, работающему под еще не пойманным командным центром. Мы выбрали Mēris — по-латышски «чума». Такое название кажется уместным и относительно близким к Mirai по произношению.
Особенности ботнета Mēris:
- Использование конвейерной обработки (pipelining в HTTP/1.1) для организации DDoS-атак (подтверждено)
- Атаки ориентированы на эксплуатацию RPS (подтверждено)
- Открытый порт 5678 (подтверждено)
- SOCKS4-прокси на зараженном устройстве (не подтверждено, хотя мы знаем, что устройства Mikrotik используют SOCKS4)
На момент публикации этой статьи мы не знаем точно, какие именно уязвимости приводят к тому, что устройства Mikrotik подвергаются настолько крупномасштабному захвату. Несколько записей на форуме производителя указывают, что пользователи устройств Mikrotik с 2017 года замечали попытки взлома на старых версиях RouterOS, особенно 6.40.1. Если мы и правда видим старую уязвимость, все еще активную на десятках тысяч устройств, которые не обновляются, — это очень плохие новости. Однако данные Яндекса и Qrator Labs указывают, что это, скорее всего, не так. В ботнете мы видим множество версий RouterOS последних трех лет — вплоть до последней стабильной. Наибольшая доля приходится на предпоследнюю версию.
Еще один достаточно очевидный момент — ботнет продолжает расти. У нас есть предположение, что он может разрастаться за счет техники брутфорса (перебора паролей), хотя этот вариант не кажется основным. Вся ситуация больше указывает на то, что уязвимость либо хранилась в секрете до начала полномасштабной кампании, либо была продана на черном рынке.
В наши задачи не входит исследование первопричин и поиск виновных — сосредоточимся на дальнейших наблюдениях.
В последние пару недель все мы стали свидетелями разрушительных DDoS-атак в Новой Зеландии, США и России. Все эти атаки мы ассоциируем с ботнетом Mēris. В настоящий момент он может перегрузить практически любую сетевую инфраструктуру, включая некоторые сети высокой надежности, специально созданные, чтобы выдерживать подобную нагрузку. Главный признак ботнета — чудовищный показатель RPS.
Cloudflare была первой компанией, которая публично рассказала об атаках подобного масштаба. В посте в блоге от 19 августа они упоминали об атаке, достигшей 17 млн запросов в секунду. Мы сообщили Cloudflare, что в сентябре наблюдали схожую картину по продолжительности и распределению стран-источников.
График RPS DDoS-атаки на Яндекс 5 сентября 2021 года
Яндекс стал одной из компаний, испытавших на себе возможности ботнета 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. Полученные нами данные удивляют и пугают одновременно.
Глобальное распределение открытых портов 5678: чем темнее цвет, тем больше устройств
Оказывается, в глобальной сети существует 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.
Топ стран с источниками ботнета Mēris в рекордной атаке на Яндекс
Использование конвейерной обработки HTTP (так это обозначается в HTTP/1.1, а в HTTP/2 это «мультиплексирование») делает нейтрализацию подобных атак давно забытой задачей. Дело в том, что сетевые устройства обычно установлены у легитимных пользователей. Невозможно быть уверенным, что конечная точка полностью скомпрометирована, превращена в «бота-зомби» и что в трафике атаки не занята лишь часть полосы (а остальная используется в безобидном трафике живого пользователя). В конце концов, на каком-то ресурсе могут быть зарегистрированы пользователи, пытающиеся попасть на него, даже используя скомпрометированные устройства.
Поскольку конвейерная обработка заставляет принимающий сервер отвечать на целый пакет мусорных запросов от одного источника, значит, оптимизация фронтенда может нанести еще больший ущерб при попытке ответить на каждый входящий запрос. И мы говорим об HTTP-запросах, на которые тратится бóльшая часть используемой вычислительной мощности сервера (тем более при защищенном соединении, когда к обработке незашифрованных запросов добавляется криптографическая нагрузка).
Конвейерная обработка — основной источник проблем для всех, кто встретит этот ботнет на своей инфраструктуре. Хотя браузеры (за исключением Pale Moon) в основном не используют конвейерную обработку, боты это делают, и с большим удовольствием. Такие запросы легко распознать и нейтрализовать, ведь все-таки общепринятый в интернете консенсус относительно обработки запросов выглядит как «запрос — ответ», а не как «запрос — запрос — запрос — запрос — ответ».
Сейчас мы наблюдаем реализацию стратегии «качество против количества». Из-за конвейерной обработки запросов злоумышленники могут выжать гораздо больше запросов в секунду по сравнению с «обычными» ботнетами. В том числе — потому, что классические методы нейтрализации попытаются заблокировать атакующий IP-адрес. Однако порядка 10–20 запросов, оставшихся в буферах, будут обработаны даже после этого.
Что делать в такой ситуации?
Черные списки все еще работают. Поскольку в этих атаках не происходит подмены IP-адреса источника (нет спуфинга, как мы уже упомянули), каждая жертва видит источник атаки таким, какой он есть на самом деле. Блокировки на короткий промежуток времени должно быть достаточно, чтобы предотвратить атаку и не побеспокоить конечного пользователя.
Неясно, как владельцы ботнета будут действовать в будущем. Они могут воспользоваться скомпрометированными устройствами полностью, в попытке использовать 100% доступной мощности (и по пропускной, и по вычислительной способности). Тогда не останется другого способа, кроме как блокировать каждый запрос, следующий за первым от одного источника, предотвращая обработку запросов в пайплайне.
Если на целевом сервере отсутствует защита от DDoS-атак, то не только конвейерная обработка запросов может стать катастрофой, поскольку злоумышленнику потребуется гораздо меньше «рабочей силы», чтобы заполнить порог RPS жертвы. Оказалось, очень многие не были готовы к подобному сценарию.
Что дальше?
Вчера нам удалось связаться с Mikrotik и предоставить им собранные данные. Кроме того, мы направили всю собранную информацию в профильные организации. Надеемся, что совместные усилия позволят интернету вскоре избавиться от пандемии этой «чумы».
