Компания
315,76
рейтинг
17 июля 2014 в 13:05

Разработка → MAYHEM — многоцелевой бот для *NIX-серверов. Расследование Яндекс.Безопасности

UPD. Спустя несколько часов после публикации на Хабре англоязычная версия этого исследования команды Безопасного поиска Яндекса вышла на Virus Bulletin. Чуть больше деталей и ссылки на библиографию.

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



Изначально MAYHEM представляет собой php-скрипт, который после запуска определяет архитектуру системы (x86 или x64) и наличие прав на запись в текущую директорию. Эти привилегии в подавляющем большинстве случаев есть у пользователя, под которым запущен веб-сервер, и в данном случае их достаточно для работы бота.



После php-скрипт убивает все запущенные под текущим пользователем процессы “/usr/bin/host”, извлекает из себя shared object для нужной архитектуры (x86 или x64) и запускает процесс “/usr/bin/host” с подгрузкой в него shared object при помощи техники LD_PRELOAD.

Техника LD_PRELOAD довольно хорошо описана. Она позволяет загрузить shared object в адресное пространство процесса раньше оригинального исполняемого файла. Также эта техника позволяет осуществлять подмену функций, например, стандартной библиотеки. Вкратце, если подгружаемый через LD_PRELOAD объект экспортирует какую-то функцию, которая совпадает с функциями из других shared objects, то будет использоваться именно эта функция.

Таким образом, техника LD_PRELOAD позволяет с легкостью перехватывать функции, чем и пользуются злоумышленники. В данном случае вредоносный объект перехватывает функцию “exit”.

После старта и получения управления вредоносный shared object удаляет переменную окружения LD_PRELOAD и свое тело с диска, а затем производит еще несколько антиотладочных приемов. В результате на диске не остается практически никаких следов его присутствия.

Далее, если все в порядке, происходит расшифрование конфигурации, которая находится в сегменте данных этого объекта. Конфигурация шифруется при помощи алгоритма XTEA (32 раунда) в режиме ECB.



В конфигурации содержится всего три параметра: URL командного сервера (С&C), имя файла со скрытой файловой системой и размер скрытой файловой системы.

После первоначальной настройки бот определяет, создана ли уже скрытая файловая система. Если нет, он создает ее. Скрытая файловая система представляет собой образ диска с файловой системой FAT, каждый блок которой шифруется алгоритмом XTEA (32 раунда, режим ECB). Работа с FAT происходит при помощи open source библиотеки FAT 16/32 File System Library, а ключи шифрования вырабатываются из номера блока в файловой системе и зависят только от этого номера. Данная файловая система используется для хранения служебных файлов и плагинов бота.



Если файловая система успешно инициализирована или была создана ранее, бот переходит к своим основным функциям. Сначала он оповещает командный сервер (C&C) о начале работы и далее получает и выполняет его команды: скачивает нужный плагин и задания к нему, создает некоторое количество рабочих потоков и приступает к исполнению задания.

Как уже было сказано ранее, бот расширяет свою функциональность при помощи плагинов. В ходе исследования нам удалось обнаружить и проанализировать некоторые из них. Набор плагинов позволяет ботнету выполнять следующие задачи:

  1. Поиск сайтов, уязвимых к Remote File Inclusion (RFI). На скриншоте показан кусочек списка, который используется для тестирования сайта.



  2. Определение имен пользователей для сайтов на базе Wordpress CMS. Бот получает от командного сервера список сайтов под управлением Wordpress и в процессе работы получает для каждого такого сайта список зарегистрированных пользователей. Делается это при помощи запроса следующего вида: <адрес сайта>/?author=<ID пользователя>. ID пользователей перебираются в диапазоне от 1 до 5. В дальнейшем собранные данные используются для подбора паролей.
  3. Поиск страниц авторизации для сайтов на Joomla и Wordpress. Бот получает от C&C список сайтов и в процессе работы пытается получить страницы /wp-login.php или /administration/. В случае успеха он возвращает командному серверу список сайтов, на которых данные страницы были найдены.
  4. Перебор паролей к страницам авторизации CMS и ISP-панелей. Этот плагин настраивается при помощи гибкой системы правил и позволяет перебирать пароли для практически любых страниц авторизации. Пример настройки этого плагина можно увидеть на скриншоте ниже.



    Для перебора злоумышленники используют словарь, состоящий из 17911 паролей с длинами от 1 до 32 символов. Облако из этих паролей служит заглавной картинкой к этому посту.
  5. Поиск страниц с заданной тематикой. Плагин получает список сайтов, обходит их рекурсивно (глубина обхода задается в конфигурации) и собирает адреса страниц, которые удовлетворяют определенному набору правил. Пример такого набора правил представлен на скриншоте ниже.



  6. Плагины для перебора паролей FTP-аккаунтов, плагины для обхода диапазонов IP-адресов, поиска phpMyAdmin и так далее.
  7. Отдельно стоит остановиться на плагине для эксплуатации уязвимости HeartBleed. Несмотря на то, что многие системные администраторы уже обновили OpenSSL, в интернете все еще остается довольно большое количество уязвимых серверов.

Таким образом, модульная структура позволяет использовать ботнет для самых различных задач. Отдельно остановимся на C&C. В ходе исследований нам удалось обнаружить три различных командных сервера. Один из них уже не функционировал, а оставшиеся два использовались для управления более чем 1400 ботами.

Мы проанализировали наиболее крупный из двух командных серверов. Общий вид системы управления ботнетом выглядит так:



Под управлением этого сервера работало около 1100 ботов. Распределение зараженных серверов по странам можно посмотреть на карте ниже. Более темный тон означает большее количество зараженных серверов.



Таким образом, основную часть ботнета составляли сервера, расположенные в России, США, Германии и Канаде.

А вот так выглядит интерфейс, позволяющий дать задание всему ботнету или отдельным группам ботов:



В момент исследования данный ботнет занимался перебором паролей для административной части сайтов на базе Wordpress CMS. На картинках ниже показан прогресс выполнения задания и часть файла с подобранными паролями — отчета о проделанной работе.





Как видно, пользователи использовали слабые пароли неустойчивые к перебору.

Таким образом, для создания ботнета из зараженных серверов отнюдь не обязательно получать доступ к серверу с правами root. Злоумышленники постоянно выдумывают новые способы эффективного использования уязвимых сайтов и серверов. На сегодняшний день они уже готовы довольствоваться даже малыми привилегиями в системе. Учитывайте это при администрировании своих серверов и разработке веб-приложений, используйте стойкие к перебору пароли, регулярно обновляйте OpenSSL и следите за безопасностью своих веб-приложений.

Берегите своих пользователей и свои веб-серверы.
Автор: @alextheraven
Яндекс
рейтинг 315,76

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

  • +2
    А как php скрипт попадает на сервер?
    • +6
      в 90 процентах случаев через украденный трояном пароль юзера от фтп, остальное обычно уязвимости в скриптах, панелях и прочем.
    • +4
      Последние два скриншота как раз об этом. Во-первых, слабые пароли, во-вторых уязвимые версии плагинов, использование старых версий CMS и тп. Если у вас сайт на Wordpress, то можно попробовать проверить его на наличие уязвимых плагинов при помощи сканера от команды www.wpscan.org
  • 0
    Судя по всему сталкивался с этим ботнетом.
    Заметил, что процесс /usr/bin/host работает от www-data и генерирует уйму трафика.
    serverfault.com/questions/554801/usr-bin-host-being-used-in-http-ddos-on-debian

    Если погуглить, то большинство грешит на WordPress. Вроде вычистил, по крайней мере за последние 3 месяца аномалий не было замечено.

    Может порекомендуете как еще проверить, что сервер сейчас не заражен?
    • +1
      Можно посмотреть висящие процессы /usr/bin/host, поискать на диске файлы .sd0, попробовать также find. -type f -name "*.php" | xargs grep «MAYHEM».

      Также можно попробовать проверить всю директорию Sophos'ом, мы отправляли им сэмпл, они сделали детект.
      • 0
        Спасибо за ответ. Как раз .sd0 и находил.
        Пойду читать про Sophos.
      • +1
        Немного ошибся, правильно будет
        find . -type f -name "*.php" | xargs grep «MAYHEM»
        • +1
          Ну тогда уж скорее:
          find / -type f -name "*.php" -print0 | xargs -0 grep MAYHEM
      • 0
        Поделитесь сэмплом пожалуйста в свой антивирус вставить.
        • 0
          Присылайте свой почтовый адрес в личку!
      • 0
        В случае rpm-дистрибутива можно воспользоваться rpm -V
        • 0
          Ну, если установят руткит, то это не поможет. Как и всякие chkrootkit/rkhunter. У меня есть пара своих детекторов руткитов, но, в принципе, от них тоже можно легко защититься.
          milabs описывал способ более грамотного подхода к детекту, но, иногда, его нельзя использовать, например, если у вас контейнер (VPS на OpenVZ, например).
  • +1
    А можете список паролей выложить? Хочется пробить пароли от клиентских серверов из keepass по этому списку, так, для душевного спокойствия)
    • +1
      У вас в keepass лежат словарные пароли для серверов??
  • –15
    PHP == People Have Problems
    • 0
      Тут уж PHP вообще непричем.
      • +17
        Ни при чем.
        • –6
          Не при чём.
  • +1
    Спасибо, любопытный материал, а главное — подробный.
  • +1
    То есть бот никак не защищается от возможной смерти процесса host? Никакой автозапуск, хоть бы и по крону, не предусмотрен?
    • +2
      В процессе работы в процессе host бот перехватывает управление и не дает завершиться процессу. Если же по какой либо причине процесс умер — C&C раз в какое-то время обходит такие хосты и запускает заново исходный phpскрипт
      • 0
        А если сервер перегружен? как C&C восстанавливает над ним контроль?
      • 0
        и не дает завершиться процессу
        Вот и я думаю, если он exit() перехватывает, процесс же становится неким «зомби». Как бы не зомби в привычном смысле, но все init-скрипты, ожидающие завершения, должны же сломаться, верно?
        • 0
          exit перехватывается только в одном процессе host, который запускается этим php скриптом
  • 0
    php-скрипт, который после запуска определяет архитектуру системы (x86 или x64) и наличие прав на запись в текущую директорию


    Я стесняюсь задавать такой вопрос в столь серьезном блоге, но зачем давать права на запись веб-серверу туда, откуда запускаются php скрипты?
    • 0
      Занимался этим в свое время, почти 100% сайтов имеют права на запись хотя бы в одну папку.
      Ну и к примеру этот же php скрипт можно и через ssh от пользователя запустить при наличии украденного пароля.
    • 0
      Права на запись в подавляющем большинстве случаев есть на директории, в которые из CMS (и не только) загружается контент, а также на папки кэша, логов (если таковые ведутся со стороны CMS) и т.п.
      • +2
        А при условии, что одна из самых популярных CMS Wordpress с недавних пор имеет функцию автообновления (пусть даже для минорных релизов), что свидетельствует о наличии прав на запись, рост количества зараженных серверов может быть весьма стремительным.
        • +1
          С точки зрения безопасности ещё не ясно что хуже — права на запись с автообновлением, или просто устаревшая дырявая версия (плюс всё-равно права на запись в некоторые вышеупомянутые каталоги).
  • 0
    А с FreeBSD были прецеденты заражения?
    • +1
      Да, были!
  • +3
    Я вот только не понял из текста, а как Вы получили доступ к админке ботнета? Или там аутентификация не была предусмотрена?
    • 0
      Авторизация обычно есть, но зачастую админки ботнетов содержат примерно столько же уязвимостей, сколько эксплуатируемыми ботами этой сети сайты.
  • 0
    > После php-скрипт [… ] запускает процесс “/usr/bin/host” с подгрузкой в него shared object при помощи техники LD_PRELOAD

    А можно поинтересоваться, как именно PHP-скрипт может запустить какой-либо процесс в ОС?

    На вашем скриншоте с кодом этот момент как раз не показан. Хотелось бы на него посмотреть.

    Я понимаю, что в PHP для этого существуют функции типа system() и dl(), но они у всех адекватных хостеров отключены. Поэтому на данный момент мне кажется, что проблема связана скорее с неадекватной настройкой прав интерпретатора PHP.
    • 0
      Разобрался. Как я и думал, PHP-скрипт злоумышленника запускает команды ОС через стандартную PHP-функцию system(). Вот скриншот кода: www.virusbtn.com/virusbulletin/archive/2014/07/figures/Mayhem-fig3.jpg

      По-моему именно разрешенная функция system() и является основной бедой на сервере жертвы. Так что если в вашем PHP-интерпретаторе она выключена, можете спокойно выдохнуть. А если нет, то выключите ее через php.ini.
      • 0
        На моём сервере были отключены все функции для выполнения команд ОС (типа system), а так же включен open_basedir, но «злоумышленнику» удалось обойти оба эти ограничения, так как в используемой мной версии php имелась уязвимость класса RCE в функции отправки почты. Кроме того, он воспользовался неизвестной на тот момент уязвимость в классе DirectoryIterator, которая позволяла обойти ограничение open_basedir.
  • 0
    Ради справедливости, мы проанилизировали поверхностно эту заразу еще в апреле и опубликовали часть наших изысканий в мае: тут и передали в ведущие антивирусные компании его паттерны — Kaspersky, DrWeb, ClamAW.

    Зараза очень популярная, у нас уже каждый день поддержка выгребает штук несколько таких. Источники проникновения в 99% случаев — дырявые CMS на php.
    • +1
      Мы тоже столкнулись с этим в апреле, но у нас много времени заняло само исследование, подготовка текста и т.д. Если в следующий раз найдете подобное — пришлите пожалуйста и нам.
      • 0
        У нас такой радости почти каждый день море. Но ситуация усложняется тем, что это клиентское оборудование и там соответствующая политика конфиденциальности =(

        Какова судьба libwoker? Командные центры выведены из строя?
        • 0
          см. личку
  • 0
    Способ избавиться в дальнейшем от напасти (именно от этой) — добавить в файл /etc/cron.deny строчку с www-data (у нас под ним запускается сервер). Так как зараза использует cron в процессе использования себя, это должно не дать заразить систему в случае появления очередной уязвимости.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка