Комментарии 45
А как php скрипт попадает на сервер?
в 90 процентах случаев через украденный трояном пароль юзера от фтп, остальное обычно уязвимости в скриптах, панелях и прочем.
Последние два скриншота как раз об этом. Во-первых, слабые пароли, во-вторых уязвимые версии плагинов, использование старых версий CMS и тп. Если у вас сайт на Wordpress, то можно попробовать проверить его на наличие уязвимых плагинов при помощи сканера от команды www.wpscan.org
Судя по всему сталкивался с этим ботнетом.
Заметил, что процесс /usr/bin/host работает от www-data и генерирует уйму трафика.
serverfault.com/questions/554801/usr-bin-host-being-used-in-http-ddos-on-debian
Если погуглить, то большинство грешит на WordPress. Вроде вычистил, по крайней мере за последние 3 месяца аномалий не было замечено.
Может порекомендуете как еще проверить, что сервер сейчас не заражен?
Заметил, что процесс /usr/bin/host работает от www-data и генерирует уйму трафика.
serverfault.com/questions/554801/usr-bin-host-being-used-in-http-ddos-on-debian
Если погуглить, то большинство грешит на WordPress. Вроде вычистил, по крайней мере за последние 3 месяца аномалий не было замечено.
Может порекомендуете как еще проверить, что сервер сейчас не заражен?
Можно посмотреть висящие процессы /usr/bin/host, поискать на диске файлы .sd0, попробовать также find. -type f -name "*.php" | xargs grep «MAYHEM».
Также можно попробовать проверить всю директорию Sophos'ом, мы отправляли им сэмпл, они сделали детект.
Также можно попробовать проверить всю директорию Sophos'ом, мы отправляли им сэмпл, они сделали детект.
Спасибо за ответ. Как раз .sd0 и находил.
Пойду читать про Sophos.
Пойду читать про Sophos.
Немного ошибся, правильно будет
find . -type f -name "*.php" | xargs grep «MAYHEM»
Поделитесь сэмплом пожалуйста в свой антивирус вставить.
В случае rpm-дистрибутива можно воспользоваться rpm -V
Ну, если установят руткит, то это не поможет. Как и всякие chkrootkit/rkhunter. У меня есть пара своих детекторов руткитов, но, в принципе, от них тоже можно легко защититься.
milabs описывал способ более грамотного подхода к детекту, но, иногда, его нельзя использовать, например, если у вас контейнер (VPS на OpenVZ, например).
milabs описывал способ более грамотного подхода к детекту, но, иногда, его нельзя использовать, например, если у вас контейнер (VPS на OpenVZ, например).
А можете список паролей выложить? Хочется пробить пароли от клиентских серверов из keepass по этому списку, так, для душевного спокойствия)
PHP == People Have Problems
Спасибо, любопытный материал, а главное — подробный.
То есть бот никак не защищается от возможной смерти процесса host? Никакой автозапуск, хоть бы и по крону, не предусмотрен?
В процессе работы в процессе host бот перехватывает управление и не дает завершиться процессу. Если же по какой либо причине процесс умер — C&C раз в какое-то время обходит такие хосты и запускает заново исходный phpскрипт
php-скрипт, который после запуска определяет архитектуру системы (x86 или x64) и наличие прав на запись в текущую директорию
Я стесняюсь задавать такой вопрос в столь серьезном блоге, но зачем давать права на запись веб-серверу туда, откуда запускаются php скрипты?
Занимался этим в свое время, почти 100% сайтов имеют права на запись хотя бы в одну папку.
Ну и к примеру этот же php скрипт можно и через ssh от пользователя запустить при наличии украденного пароля.
Ну и к примеру этот же php скрипт можно и через ssh от пользователя запустить при наличии украденного пароля.
Права на запись в подавляющем большинстве случаев есть на директории, в которые из CMS (и не только) загружается контент, а также на папки кэша, логов (если таковые ведутся со стороны CMS) и т.п.
А с FreeBSD были прецеденты заражения?
Я вот только не понял из текста, а как Вы получили доступ к админке ботнета? Или там аутентификация не была предусмотрена?
> После php-скрипт [… ] запускает процесс “/usr/bin/host” с подгрузкой в него shared object при помощи техники LD_PRELOAD
А можно поинтересоваться, как именно PHP-скрипт может запустить какой-либо процесс в ОС?
На вашем скриншоте с кодом этот момент как раз не показан. Хотелось бы на него посмотреть.
Я понимаю, что в PHP для этого существуют функции типа system() и dl(), но они у всех адекватных хостеров отключены. Поэтому на данный момент мне кажется, что проблема связана скорее с неадекватной настройкой прав интерпретатора PHP.
А можно поинтересоваться, как именно PHP-скрипт может запустить какой-либо процесс в ОС?
На вашем скриншоте с кодом этот момент как раз не показан. Хотелось бы на него посмотреть.
Я понимаю, что в PHP для этого существуют функции типа system() и dl(), но они у всех адекватных хостеров отключены. Поэтому на данный момент мне кажется, что проблема связана скорее с неадекватной настройкой прав интерпретатора PHP.
Разобрался. Как я и думал, PHP-скрипт злоумышленника запускает команды ОС через стандартную PHP-функцию system(). Вот скриншот кода: www.virusbtn.com/virusbulletin/archive/2014/07/figures/Mayhem-fig3.jpg
По-моему именно разрешенная функция system() и является основной бедой на сервере жертвы. Так что если в вашем PHP-интерпретаторе она выключена, можете спокойно выдохнуть. А если нет, то выключите ее через php.ini.
По-моему именно разрешенная функция system() и является основной бедой на сервере жертвы. Так что если в вашем PHP-интерпретаторе она выключена, можете спокойно выдохнуть. А если нет, то выключите ее через php.ini.
На моём сервере были отключены все функции для выполнения команд ОС (типа system), а так же включен open_basedir, но «злоумышленнику» удалось обойти оба эти ограничения, так как в используемой мной версии php имелась уязвимость класса RCE в функции отправки почты. Кроме того, он воспользовался неизвестной на тот момент уязвимость в классе DirectoryIterator, которая позволяла обойти ограничение open_basedir.
Ради справедливости, мы проанилизировали поверхностно эту заразу еще в апреле и опубликовали часть наших изысканий в мае: тут и передали в ведущие антивирусные компании его паттерны — Kaspersky, DrWeb, ClamAW.
Зараза очень популярная, у нас уже каждый день поддержка выгребает штук несколько таких. Источники проникновения в 99% случаев — дырявые CMS на php.
Зараза очень популярная, у нас уже каждый день поддержка выгребает штук несколько таких. Источники проникновения в 99% случаев — дырявые CMS на php.
Способ избавиться в дальнейшем от напасти (именно от этой) — добавить в файл /etc/cron.deny строчку с www-data (у нас под ним запускается сервер). Так как зараза использует cron в процессе использования себя, это должно не дать заразить систему в случае появления очередной уязвимости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MAYHEM — многоцелевой бот для *NIX-серверов. Расследование Яндекс.Безопасности