Защита и лечение от вирусов сайта на MODX

Модикс реализован на PHP языке. В качестве системы управления базами данных (СУБД) может быть выбрана MySQL или MS SQL. Работа системы возможна на всех популярных серверах: Apache 2.2.x, nginx 1.2.x, IIS 7.0 и прочих.

Есть 2 версии CMS: актуальная MODX Revo и динозавр MODX Evo. Настоятельно рекомендуется использовать именно MODX Revolution.

Своего врага нужно знать в лицо. Поэтому рассказываем по-порядку о последних официально зафиксированных уязвимостях.

Один из массовых взломов MODX был зафиксирован летом 2018-го.

Эти критические уязвимости позволяют удаленно загружать скрипты, удалять файлы/папки, изменять содержимое и т.д. — в общем издеваться над сайтом, как угодно. Подвержены угрозам MODX версии 2.6.4 и ниже. Так что, если вы «в танке», то советуем не тянуть с обновлением.

Взлом проходит по 2-3 классическим сценариям. Вирус выдает себя наличием файлов с подозрительными именами: dbs.php и cache.php в корне сайта (а еще бывает там майнер лежит).

Избежать заражения MODX можно при соблюдении двух условий:

• если папка connectors переименована и закрыт к ней доступ;
• переименована папка assets (при использовании компонента gallery).

Проблема в следующем. MODX передает пользовательские параметры в класс phpthumb без необходимой фильтрации. Для заражения сайта используются скрипт /connectors/system/phpthumb.php или любой другой передающий параметры в класс modphpthumb.class.php. Вредоносный скрипт получает на вход имена функций и параметры через куки. С помощью полученных данных происходит косвенный вызов этих функций. Например, если у вас установлен плагин Gallery (классика жанра), то атака может происходить через скрипт: /assets/components/gallery/connector.php.

Если сайт размещен на аккаунте виртуального хостинга без изоляции сайтов, то данный backdoor позволяет заразить не только хакнутый сайт, но и его “соседей”.

Уже через три месяца после предыдущей атаки, была зафиксирована новая уязвимость. На этот раз в сниппете AjaxSearch.

Проблема похожа на предыдущую. Из-за плохой фильтрации значения параметра ucfg (передача пользовательской конфигурации), возможен вызов бэкдора через POST обращение к сайту. «Черный ход» хранится в БД и позволяет в дальнейшем проводить успешные атаки на сайт: загрузку веб-шеллов, редактирование файлов, баз данных и прочего. Из-за того что код сохраняется в БД, он не обнаруживается сканерами файлов на хостинге и, даже в случае успешного удаления всех загруженных шеллов, у хакера все равно остается «лазейка», через которую он повторно загружает вредоносные скрипты.

Самая свежая угроза MODX зафиксирована весной 2019-го.

Был обнаружен exploit (эксплойт) для сайтов, в которых осталась директория setup. Эта «дыра» позволяет получить полный доступ к сайту, а если не повезет, то и веб-серверу.

Проверить свой сайт на такую уязвимость можно следующим образом. Введите в строку любого браузера адрес вашего домена + /setup.

Пример: www.site.ru/setup

Теперь на наглядных примерах рассказываю, как может проявлять себя вирус. Под уязвимость попал сайт на системе MODX Revolution 2.6.5-pl. Сразу стоит отметить, что внешне вирус себя особо не выдавал. Т.е. сайт не падал, не было редиректов на странные страницы, картинки отображались корректно и так далее.

Над сайтом проводились работы по сео-оптимизации, в том числе оптимизировалась карта сайта. В один не очень прекрасный день, был скачан файл sitemap.xml, для анализа его корректности. Открыв карту сайта, увидел такую картину:

В хвост url-адресов сайта прописался мусор, сгенерированный вирусом. Проверив в админке правила заполнения карты, я не нашел никаких следов деятельности паразита. Оказалось, что карту просто подменили.

Первым делом вернул корректный сайтмап, а потом сразу “побежал” в Google Search Console и Яндекс.Вебмастер за письмами счастья. Пришло уведомление только от Гугла, он оказался очень шустрым, когда не надо. В личном кабинете ожидало сообщение о нарушении безопасности.

Понятно. Далее проверил, что творится в индексе Гугла и ужаснулся. В каждый сниппет сайта попал японский текст! Как я позже узнал, это японский SEO-спам.

Гугл-бот очень старался и проиндексировал кучу зараженных страниц со скоростью света. Изначально в индексе было около 500 качественных. Проверяю реакцию поисковика и отслеживаю на allpositions.ru ситуацию с позиционированием сайта. И тут Гугл молодец. Сработал оперативно. Мигом выкинул из топ-100 все страницы. Типичная SEO-проблема.

С этим все понятно, а что думает на этот счет Яндекс? Да ничего. Вирус, как оказалось, чисто гугловый. Хоть одна хорошая новость. Почему так? Есть отличный сервис, который позволяет смотреть на сайт глазами поискового робота.

Выбираем в параметрах просмотра GoogleBot, пишем в строку адрес любой страницы и получаем результат. Японские иероглифы прописались повсюду: в дескрипшен, тайтл, микроразметку, текст.

Выбираем робота Яндекса — код выглядит естественным образом.

Вот так Гугл краулер видит страницы сайта, хотя внешне (для человеческого глаза) они никак не изменились:

Контент зараженной страницы в глазах поисковика именно таков. По сути это японский дорвей. То есть под видом качественной страницы распространяется вирусная информация. Наш сайт находят по релевантному запросу в поиске (как и должно быть), но поверх качественного контента отображается вредоносная информация. В данном случае, как я уже говорил, это видит только гугловый бот. Для человека и бота Яндекса страницы выглядят как обычные.

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

1. Делать резервные копии содержимого сайта.
2. Следить за подсказками в Яндекс вебмастере и Гугл серч консоли о состоянии безопасности сайта.
3. Проверять регулярно сайт на наличии вирусов скриптом ai-bolit.
4. Использовать последние версии патчей для админки и модулей (плагинов).
5. Следить за новостями безопасности из официального блога.

Элементарно. Как можно скорее заняться удалением зловредов. Для SEO-продвижения важно устранить проблему до того, как ее обнаружат Гугл или Яндекс боты. Если вы опередили ботов, то уже хорошо, но времени на исправление все равно немного.

Как мы убедились ранее, процесс лечения сайта сводится к 2-3 шагам.

1. Поиск и удаление вирусов.
2. Установка обновлений (патчей), закрывающих уязвимости.
3. Смена паролей, но в этом не всегда есть необходимость. Зачастую цель вирусных атак — заражение сайта для собственной выгоды, а не для кражи паролей.

Выделим 2 самых популярных способа лечения сайта от вирусов. Эти методы рабочие не только для сайтов, построенных на Модиксе, но и для всех остальных.

1. Скачать все файлы со своего сайта на компьютер и проверить их антивирусом локально. Хороший и, наверное, единственный вариант, если хостинг не «вывозит» скрипт айболита. Прогнать файлы можно бесплатными антивирусными сканерами Malwarebytes Anti-Malware, Dr.Web CureIt! или на крайняк AVZ.
2. Самое популярный и универсальный инструмент для чистки сайта — Ai-bolit.

1. Скачиваем антивирус ai-bolit для сайтов здесь.
2. Распаковываем скачанный архив.
3. Если у вас есть доступ к серверу через SSH:
   1. Копируем содержимое папки ai-bolit в корень сайта;
   2. Заходим на сервер через консольное приложение (например Putty) и переходим в корень сайта cd /путь/до/вашего/сайта;
   3. Запускаем скрипт командой (в консоли будет отображаться статус проверки):

      php ai-bolit.php

   4. После завершения проверки в корне сайта появится файл вида:

      AI-BOLIT-REPORT-<дата>-<время>.html

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

      php ai-bolit.php --mode=2

   6. После повторной проверки в отчет попадут в том числе и файлы с расширением изображений (.jpg, .png), которые также нужно почистить;

      Важно!

      В отчете могут быть и чистые системные файлы MODX, будьте внимательны

4. Если у вас доступ только через FTP:
   1. В файле ai-bolit/ai-bolit.php прописываем произвольный пароль во втором параметре в следующей строке:

      define('PASS', 'ВАШ_ПАРОЛЬ')

   2. Заходим на сервер через ftp по известным ip, login и password при помощи FTP клиента (WinSCP или Filezilla);
   3. В корень копируем содержимое папки ai-bolit: ai-bolit.php (ранее правленый) и AIBOLIT-WHITELIST.db.

      Важно!

      Cначала редактировать и только потом копировать файл ai-bolit.php, т.к. после копирования хостинг может заблокировать изменение файла.

   4. Далее перейти на сайт: https://сайт/ai-bolit.php?p=ВАШ_ПАРОЛЬ,

      где сайт - название вашего домена,

      пароль - ранее прописанный в файл ai-bolit.php.

   5. При успешном переходе по вышеупомянутому адресу начнется сканирование сайта, по окончании которого генерируется отчет. Но скрипт может не выполнить полное сканирование, из-за стандартных ограничений PHP, установленных хостером и вы увидите на экране ошибку с кодом 50x. В этом случае надо найти в панели управления хостингом, где изменить параметры php и расширить параметры memory_limit до 512mb и max_execution_time до 600 сек, при необходимости и возможности ресурсов вашего хостинга задайте большие значения параметров.
   6. Также хостер может заблокировать и запись файлов на вашей площадке, т.к. обнаружит активность вредоносных программ. В этом случае обратитесь в техподдержку с подробным описанием проблемы.
5. После завершения проверки в корне сайта появится файл-отчет вида: AI-BOLIT-REPORT-<дата>-<время>.html. Этот файл нужно скачать и открыть в браузере. В этом отчете будут указаны пути ко всем подозрительным файлам, например:
   • Файлы (в системных папках MODX), дублирующие существующие, с небольшим изменением в названиях. Такие файлы содержат закодированные данные и формы для загрузки файлов. Такие файлы необходимо удалять полностью;
   • Файлы формата jpg, но не являющиеся изображениями (например, макросы). Это проверяется открытием таких файлов текстовым редактором. Такие файлы необходимо также удалять полностью;
   • Реальные системные файлы MODX (например index.php), в которые добавлены извне строки вредоносного кода. Например команды, которые шли до комментария по умолчанию (см. ниже) — выше этого комментария кроме открывающегося тега <?php ничего не должно быть:

     <?php
     /*
     * This file is part of MODX Revolution.
     *
     * Copyright (c) MODX, LLC. All Rights Reserved.
     *
     * For complete copyright and license information, see the COPYRIGHT and LICENSE
     * files found in the top-level directory of this distribution.
     */

6. После очистки следов вируса могут пострадать системные файлы. Это решается установкой свежей версии MODX и затем всех дополнений.
7. Если сайт после очистки работает нормально, все равно обновите MODX!

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

meta name="generator" content="Joomla! 1.5 - Open Source Content Management"

или отправляется в заголовке.

Косвенные параметрами являются используемые на сайте директории, папки, плагины и прочее. Чтобы обеспечить максимальную безопасность в системе управления MODX, рекомендуется выполнить несколько настроек. Следующие инструкции направлены на защиту от определения CMS сайта.

1. Первое, что приходит на ум — обновить Модикс, его компоненты (особенно галерею) и использовать максимально высокую версию PHP. Тут думаю все понятно. В новых обновлениях латают дыры прошлых версий (и добавляют новые, но это не точно).
2. Изменить префикс для базы данных. Префикс генерируется случайным образом из букв и цифр. Например: YTr21x024_. Это мало мальски может помочь при sql-инъекциях. Изменив префикс, сделать запрос к вашей БД для «темных целей» станет сделать сложнее.
3. Если используется веб-сервер apache:
   Для пущей надежности хорошо прописать в .htaccess пару строк, чтобы скрыть файл конфигурации config.core.php:

   RewriteCond %{REQUEST_URI} ^/config.core.php*

   RewriteRule ^(.*)$ [R=404]

   Если на сервере сайта произойдет сбой, а php-файлы перестанут исполняться (будет отображаться их исходный код), то злоумышленнику будет несложно получить доступ к базе данных. Во избежании этого надо добавить в .htaccess файл следующую строку, чтобы не показывать код ошибки PHP:

   php_flag display_errors off

4. Не забываем чистить кеш в папке /core/cache/.

MODX подвержен частым вирусным атакам, как и все остальные CMS. Да, мы можем снизить риск заражения, выполнив грамотную настройку сайта, но это не панацея. Вирусы могут заползти оттуда, где их вовсе и не ждали. Поэтому не забрасывайте свои сайты и не пускайте на самотек. Своевременное обнаружение вирусов поможет избежать серьезных проблем с чисткой сайта и SEO-продвижением. Периодически проверяйте здоровье сайта, устанавливайте обновления и следите за новостями кибербезопасности.

Вирусы не дремлют и вы тоже не спите.