А Вы уверены, что ваш "Любимый сайт" не рассылает втихаря спам?

Началось вся котовасия с того, что попал я однажды в бан на любимом форуме и вроде бы ни за что! После обращения к хозяину данного ресурса, от него пришло сообщение, что да, действительно бан есть и кинул ссылочку, в которой говорилось, что один из моих сайтов, который соответственно сидел на одном со мной ip заражен StealRat Infection.

Раньше я не сталкивался с такой Какой, начал изучать тему... Кстати, проверить ваш ip на данную заразу можно тут abuseat.org, где собственно и говорилось:

Информация по обнаруженной инфекции

StealRat Infection

We have detected that this IP is NATting for, or is infected itself, with the "StealRat" malware. StealRat is usually found on UNIX or xxxBSD web servers running the Drupal, Wordpress or Joomla Content Management Systems (CMS).

In short, you have to:

  • Secure the computer against further reinfection - which means making sure that all CMS installations on the computer are up-to-date and kept up to date. Almost all Stealrat infections are via security holes in stale CMS software.
  • Find the StealRat infection and remove it.

 

Заражение StealRat

Мы обнаружили, на этом IP NATting, или он заражен "StealRat" вредоносной программой. StealRat обычно находится на UNIX или xxxBSD веб-серверах, работающих под управлением Drupal, Wordpress или Joomla.

Короче говоря, вы должны:

1 Обезопасить компьютер от дальнейшего повторного заражения - это означает, что нужно убедиться, что все обновления CMS установлены до последних. Почти все Stealrat инфекции проникают с помощью дыр безопасности CMS, которая не обновляется.
2 Найти инфекции StealRat и удалите его.


Вот описание вируса StealRat и методов его поиска на сайте TrendMicro если Вы заподозрили его присутствие - очень полезная информация. А вот статья на хабре про данную заразу

Ну конечно первым делом я начал искать сами нежелательные файлы. Обнаружил много всего "интересного", включая шелл скрипт... Он лежал на двух виртуальных хостах, прятался под WordPress (а все сайты у меня на джумле, хотя и стоял до лета 2015 блог на вордпрессе, но то, что он остался от старого блога исключено, т. к. всё полностью сносилось, кроме того, папка от вордпресса в корне джумлы ну явно бросается в глаза) Итак, путь где он лежал:

 Site/wp-content/ugrade/theme-compat/popup-pomo.php

 На самом деле, запустив скрипт, волосы дыбом встали! Не понимаю каким образом, но он мог всё! Причем читал файлы, которые разрешено читать только root и легко перемещался по всему серверу до корня... Название сия чуда Dark Shell. Следов в логах о его установке не нашёл! Каким образом попал ко мне осталось загадкой.

Второе (или первое), что прям бросается в глаза в корне сайта папка Hot. Перейдя по ссылке в браузере - китайский сайт на моём домене! Причем, в индексе у гугла уже было порядка нескольких тысяч проиндексированных страниц. Вот состав папки

Дальнейшие поиски обнаружили скрипт, красиво спрятавшийся тут:

site/modules/mod_speedup/...

Соответственно такого модуля я в глаза не видел никогда.

Стандартный джумловский шаблон Beez3 тоже был нашпигован всякой хренью..

site/templates/beez3/

Тут лежал файл XPqSkLmt.php , который по всей видимости название своё поимел случайным образом.

 

Должно очень сильно насторожить!
Присутствие файла .htaccess в любой папке, отличной от корневой папки сайта, (если только его не записали Вы сами) должно включить Вам в мозгу восклицательный знак с сообщением о том, что кто-то хочет изменить правила работы вашего сайта.
Вердикт - немедленно удалить, сделав копию для изучения того, каким образом хотели изменить работу сайта.
После пары часов поиска, нашел закономерность. Все зараженные файлы или создавались заново, или в уже существующие файлы CMS перед открытием тега <?php записывался еще один исполняемый скрипт в тегах <?php ...... ?>. Но этот скрипт прятался пробелами за правую сторону экрана. Поэтому, чтобы найти зловредный скрипт нужно из консоли найти совпадения "<?php [десять пробелов]" Команда для поиска
grep -Hr '<?php                ' /адрес_до_сайта/ #после тега <?php не меньше 10 пробелов

В процессе совместных поисков выяснилось, что данному виду инфекции было подвержено огромное количество сайтов, которые были сделаны на Joomla. Проникал вирус на сайты при помощи уязвимости нулевого дня, которая была обнаружена в Джумле начиная с версии 1.5 и заканчивая 3.4.5! Как видим, уязвимость просуществовала почти десяток лет. Подробнее про неё можно почитать например тут.

На других сайтах обнаруживался несколько иной код, который вставлялся в файлы, поэтому везде поиск вируса будет индивидуальным.

Но у всех в логах при атаке присутствуют вхождения "JDatabaseDriverMysql", "eval(chr("

Вот пример строчки из лога

89.76.82.40 - - [17/Dec/2015:12:37:47 +0300] "POST / HTTP/1.0" 200 96516 "-" "}__test|O:21:\"JDatabaseDriverMysqli\":3:{s:2:\"fc\";O:17:\"JSimplepieFactory\":0:{}s:21:\"\\0\\0\\0disconnectHandlers\";a:1:{i:0;a:2:{i:0;O:9:\"SimplePie\":5:{s:8:\"sanitize\";O:20:\"JDatabaseDriverMysql\":0:{}s:8:\"feed_url\";s:60:\"eval(base64_decode($_POST[111]));JFactory::getConfig();exit;\";s:19:\"cache_name_function\";s:6:\"assert\";s:5:\"cache\";b:1;s:11:\"cache_class\";O:20:\"JDatabaseDriverMysql\":0:{}}i:1;s:4:\"init\";}}s:13:\"\\0\\0\\0connection\";b:1;}\xf0\x9dR"

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

Для начала проверяем безопасные настройки сервера

После очистки сайта от инородных включений, для быстрого мониторинга сайтов на какие-либо изменения я установил Watcher4site

Watcher4site - система, которая позволяет отслеживать все изменения файлов на вашем сайте. Позволяет обнаруживать проникновение вирусов на сайт и все изменения файлов (скриптов). Распространяется бесплатно с открытым исходным кодом. Легко устанавливается и имеет простой интерфейс. Для работы требуется PHP и MySQL. Ссылка на проект.

Удобная и очень простая штучка. Сканирует все файлы на хосте, записывает их MD5 хэш и при каждом запуске сравнивает с существующим. Есть возможность автоматизировать и запускать по крону.

Тем временем атаки с попытками использования уязвимости нулевого дня приобрели массовый характер joomlaforum весь завален сообщениями об атаках. Но при "правильной" настройке сервера, в частности, при проведении вышеуказанных атак, при отключенной функции eval, сервер просто "не скушает" данный запрос и ничего страшного не произойдёт.

В качестве PS: тот факт, что вирус попал ко мне на сайт, показывает важность правильной настройки не только CMS, но и самого сервера. Не стоит пренебрегать первоначальной настройкой Apache, PHP и т. п. Ну а лично я получил очередной хороший (или плохой) опыт... 


Добавить комментарий

Защитный код
Обновить