Как проверить modx на вирусы

Что такое MODX?

MODX (Модэкс или Модикс) — это бесплатная система управления содержимым (CMS) с элементами фреймворка для разработки веб-приложений.

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

ТОП-3 уязвимости MODX

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

3 место. 11 июля 2018

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

Кодовые названия вирусных атак CVE-2018-1000207 и CVE-2018-1000208.

Взлом проходит по 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 позволяет заразить не только хакнутый сайт, но и его “соседей”.

Найти и удалить вирусные файлы, обновить CMS до последней версии.

2 место. 27 октября 2018

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

Найти и удалить вирусные файлы, обновить сниппет до последний версии.

1 место. 24 апреля 2019

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

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

Зайти через SSH или FTP на свой сервер и удалить этот каталог.

Обнаружение вирусов на живых примерах

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

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

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

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

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

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

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

Этот японский вирус был удален из MODX с помощью утилиты ai-bolit. О работе с данной программой написано далее.

Базовые советы, как предупредить заражение сайта на MODX

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

Меня заразили. Что делать?

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

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

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

Поиск и удаление вирусов. Как лечить?

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

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

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

2) Заходим на сервер через ftp по известным ip, login и password при помощи FTP клиента (WinSCP или Filezilla).

3) В корень копируем содержимое папки ai-bolit: ai-bolit.php (ранее правленый) и AIBOLIT-WHITELIST.db.

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

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

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

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

  Закалка MODX или как защитить сайт от вирусов?

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

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

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

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

  Заключение

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

  
  

  ВНИМАНИЕ!

  Обновление MODX Revolution до версии 2.6.5 должно считаться обязательным.
  Критические уязвимости безопасности затрагивают все версии до 2.6.4 включительно.

  Злобные и суровые хакеры добрались до нашей несравненной MODX Revo. Сообщения о массовом заражении сайтов начали появляться примерно с 20 июля. Примечательно, что обновление, частично закрывающее используемые лазейки, появилось за восемь дней до этого. Но, вероятно, разработчики не совсем верно оценили масштабность возможных атак и уведомили о двух найденных и закрытых версией 2.6.5 уязвимостях в стандартном режиме, то есть без лишней шумихи.

  Найденные уязвимости

  Исправление 2.6.5 появилось практически сразу, уже 12 июля. Чуть позже было обновлено до версии 1.7.1 и дополнение Gallery. Пропустив эту новость, многие оказались наказаны.

  Заражение сайтов

  Массовые взломы начали происходить в районе 20 числа, хотя при внимательном рассмотрении файлы с вредоносным кодом появились чуть раньше. Судя по информации в сети, взломанных сайтов на текущий момент очень много. Заражение происходит точно на полном автомате, никак не вручную. Это настоящий конвейер Генри Форда, в плохом смысле, конечно.

  
  

  Опознать сайт взломанный через уязвимость CVE-2018-1000207 несложно, взлом происходит всего по 2-3 типовым сценариям. Характерный признак – наличие файлов dbs.php и cache.php в корне сайта. Иногда добавляется майнер Монеро (xmr). Кроме того, может резко возрасти нагрузка на сайт.

  Очень часто заражают еще одну папку: /assets/images. Все файлы с расширением .php из этой папки можно удалять.

  Будьте внимательны, если на аккаунте размещается несколько сайтов, в группу риска попадают ВСЕ сайты. Вирус спокойненько так, но быстро переберется на все ваши проекты из одного акка.

  Есть и хорошая новость. Базы данных не затронуты. На текущий момент.

  /index.php и /manager/index.php.

  В верхней части содержится код, который перенаправляет посетителя на другой сайт.

  Что с этой бедой делать

  Если вам посчастливилось пройти мимо неприятности, срочно произведите обновление до версии 2.6.5. Не забудьте обновить Gallery до версии 1.7.1 (обновление появилось 20 июля). Сделайте бэкап сайта и озаботьтесь дополнительными мерами безопасности: переименованием каталогов core, manager и connectors. Закрыть от несанкционированного доступа служебные директории также настоятельно рекомендую.

  Если сайт заражен, проведите его восстановление их архива, созданного до 19 июля и срочно-срочно обновите сайт, до той же 2.6.5. В общем, смотри предыдущий абзац.

  Нет архива? Печаль. Вспоминайте про день бэкапа. Недолго вспоминайте, сайт все равно надо восстанавливать. А вот про js-скрипты лучше забыть. Из них вытащить уцелевшее представляется невозможным, там происходит замена содержимого всего файла. Если скрипты можно скачать у разработчика, не страшно, если они самописные, тогда… Пытайтесь восстановить из памяти или старых заначек))).

  Зараженные php-файлы (бэкдоры) можно найти по дате модификации (изменения). Обратите внимание на index.php там, где их быть не должно, cache.php, accesson.php, dbs.php.

  Но по моему мнению, проще и надежнее сделать обычную переустановку MODX, сделав сначала бэкап, пусть даже с вирусней, так на всякий пожарный, и скопировав конфигурационный файлы:

  • config.core.php
  • connectors/config.core.php
  • core/config/config.inc.php
  • manager/config.core.php

  Затем следует удалить все файлы php и зараженные файлы .js. Загрузить сохраненные конфиг-файлы обратно, накатить/обновить MODX, переустановить имеющиеся компоненты.

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

  Если вы еще ни разу не задумывались о безопасности своих сайтов, поздравляю вас, ваши сайты скорее всего заражены какой-нибудь гадостью.

  Уверены, что это не так? Я буду искренне рад ошибиться. Но практика говорит об обратной тенденции. Огромная армия "веб-разработчиков" ни разу не обновляла движок, не просматривала логи, не проверяла наличие посторонних файлов, не меняла годами пароли. Сплошь и рядом встречаешь вопросы о древних версиях движка, а ведь это потенциальные "счастливчики", которые с высокой степенью вероятности являются частью ботнета.

  Безопасность - это то, что может и должно делать вас настоящим параноиком. И как настоящий параноик вы должны делать все, чтобы не заразиться каким-нибудь трояном, дорвеем или шеллом.

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

  Вот несколько профилактических советов, которые не уберегут вас, но хотя бы помогут снизить риск:

  Начну с самого банального и уже миллион раз сказанного. Никогда не используйте простые пароли! 123456, qwerty, password, admin, test и т.д. ЗАБУДЬТЕ ИХ НАВСЕГДА! Пароль должен состоять из случайного набора букв и цифр. Записывайте эти пароли и меняйте как можно чаще. И вообще, для кого я в левой колонке генератор паролей повесил?

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

  — Извините, Ваш пароль используется более 30 дней, необходимо выбрать новый!
  — розы
  — Извините, слишком мало символов в пароле!
  — розовые розы
  — Извините, пароль должен содержать хотя бы одну цифру!
  — 1 розовая роза
  — Извините, не допускается использование пробелов в пароле!
  — 1розоваяроза
  — Извините, необходимо использовать как минимум 10 различных символов в пароле!
  — 1грёбанаярозоваяроза
  — Извините, необходимо использовать как минимум одну заглавную букву в пароле!
  — 1ГРЁБАНАЯрозоваяроза
  — Извините, не допускается использование нескольких заглавных букв, следующих подряд!
  — 1ГрёбанаяРозоваяРоза
  — Извините, пароль должен состоять более чем из 20 символов!
  — 1ГрёбанаяРозоваяРозаБудетТорчатьИзЗадаЕслиМнеНеДашьДоступПрямоБляСейчас!
  — Извините, этот пароль уже занят!

  Про пароли и так вроде бы все всё знают, поэтому двигаемся далее. Знаете ли вы, что большинство сайтов на MODX имеют пользователя admin, причем это пользователь с административными правами? У вас не так? Поздравляю! Но большинство просто не догадывается использовать какой-то другой логин для администратора, потому что "так было в уроках". Ну а теперь представьте, что у вас администратор с логином admin и паролем 123456. И уверяю вас, таких умников хватает. Ах, да, вторым по популярности пользователем является manager. Беден и скуп русский язык на английские слова.

  Кстати, вы уже 15849 посетитель, который неожиданно для себя решил попробовать подобрать логин и пароль к этому сайту :)

  В сравнении с предыдущими двумя пунктами это не менее серьезно, но чтоб вы знали, 99,99% сайтов MODX Evolution имеют один и тот же адрес панели управления, и это не смотря на то, что теперь его можно легко менять. Смена адреса админки конечно же не гарантирует 100% защиты сайта, но потенциальному взломщику может усложнить процесс. Если вы настоящий параноик, вы знаете что нужно делать ;)

  Для остальных рассказываю:

  Каждый движок обладает признаками, по которым его можно определить с высокой степенью вероятности. Есть такие и у MODX. Но это не означает, что вы должны сообщать всем прохожим, что ключ от вашей квартиры лежит под ковриком в подъезде. Да, кстати, этот сайт сделан на Джумле.

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

  Скрипты, модули, плагины, сниппеты - сколько всего интересных разработок, которые так и хочется использовать в своих проектах! Фу-фу-фу! Очень часто мы сами закачиваем вирусы на свой сервер. Это тот случай, когда самым опасным и уязвимым элементом сайта является его администратор!

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

  Помимо непосредственной безопасности сервера, о которой вам никто ничего рассказывать не будет, у виртуальных хостингов есть еще одна повсеместная беда. Общественные IP адреса, которые вам выдают на виртуальном хостинге, очень часто попадают в блеклисты. Происходит это по понятным причинам, чем больше сайтов на одном IP тем выше вероятность заражения какого-нибудь сайта и как следствие блокировки IP. По этой причине НИКОГДА не заводите почтовый сервер на виртуальном хостинге. А если все таки нужна почта на домене, лучше используйте яндексовскую почту для доменов. Хостеры как могут борятся с этой бедой, но за блеклистами следует следить и самостоятельно, например, с помощью этого сервиса, и напоминать хостеру при необходимости.

  Риск попадания в блеклисты резко снижает наличие выделенного IP, но за все в этом мире надо платить.

  Настоящий параноик хочет только одного, да и этого немного, да почти что ничего, а конкретно он хочет защищенного соединения с сервером. Поэтому, если есть возможность, которую должен предоставить хостер, отказывайтесь от FTP в пользу SSH. Что это и с чем едят, советую изучить заочно. Скачайте SSH-клиент, например WinSCP и наслаждайтесь процессом. Если же ваш хостинг не предоставляет вам такого удовольствия, а предлагает влачить жалкое существование по FTP каналу, то ни в коем случае не храните свои пароли в FTP-клиенте. И пусть вам сопутствует удача.

  Визуальный контроль ни коим образом не обезопасит, но вы имеете шанс своевременно узнать о взломе. А чем раньше вы это узнаете, тем проще будет решить проблему. В первую очередь уделяйте внимание системным сообщениям. Информация о том, что были изменены системные файлы является пожарной тревогой. Срочно ищите что было изменено и к чему это привело.

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

  Делайте бекапы. И этим все сказано. Кто не сохранился, я не виноват.

  Большинство пользователей едят перед компьютером и сильно пачкают едой клавиатуру. Еда гниет и из клавиатуры начинают расползаться страшные и вредные вирусы. Поэтому, обязательно мойте руки до, после и желательно вместо клавиатуры. И это не шутка. Но если быть чуть ближе к теме, то под личной гигиеной я подразумеваю чистоту и безопасность тех устройств, через которые вы подключаетесь к серверу или работаете с сайтом. Не пренебрегайте проверками своего компьютера. Именно через ваш компьютер злоумышленникам проще всего добраться до вашего сайта.

  Итак, вы прониклись и стали настоящим параноиком в безопасности вашего сайта. Но вас все равно взломали. А я предупреждал, что советы советами, а вирусы все равно не дремлют, в отличии от вас. И первый вопрос, что делать? Ну и далее по классику, кто виноват?

  1. В первую очередь необходимо установить хронологию событий. Надо выяснить когда и как это произошло. Помогут в этом access_log и error_log. Если вы не знаете как их посмотреть, обратитесь к хостеру.

  2. Смените все пароли!

  3. Просканируйте файлы сайта скриптом AI-bolit или попросите об этом своего хостера. Анализ подозрительных файлов поможет выявить угрозы.

  4. Проверьте антивирусом все компьютеры, с которых осуществлялся доступ к сайту. Надеюсь, объяснять, что проверяемый компьютер должен быть на это время отключен от интернета, не нужно?

  5. Помните, я говорил вам про бекапы? Если выявить и устранить угрозу не получается, восстановите сайт из резервной копии и обратитесь за помощью к специалистам.

  
  

  Всем добрый вечер!

  В предыдущей статье я попытался описать общие шаги при заражении сайта. В комментариях пообещал рассмотреть какой-либо конкретный случай. И вот, он мне представился. Конечно, жаль, что это не всеми так любимый Wordpress, но данный вид заражения там я тоже встречал, а процесс лечения в общих чертах совпадает. Приступим.

  Заходим на хостинг, всюду видим страшные предупреждения:

  
  

  Подключимся через ssh и будем смотреть.

  Сразу нас встречает множество файлов stylewpp.php:

  
  

  Вообще их было около 4000, это я уже успел поудалять =)

  По своему опыту знаю, что эти файлы создаются через планировщик, поэтому идем туда через панель. Если нет доступа к панели управления, то используем команду:

  Видим задание на ежеминутное копирование stylewpp с нашего же сайта:

  
  

  
  

  Код обфусцирован и довольно сильно, с первого раза не расшифровать, но по созданным stylewpp и анализу последствий - делаем вывод, что наш сайт (да и сервер), используется в целях майнинга.

  Посмотрим содержимое корневой директории:

  
  

  По структуре похоже, что сайт скорее всего на MODx, также невооруженным глазом видим и множество того, что скорее всего к нему не относится.

  Рассмотрим содержимое некоторых:

  - форма, позволяющая грузить все, что душе угодно;

  - это интереснее, с помощью данного скрипта можно создать своего пользователя.

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

  Будем чистить и вариантов у нас несколько:

  1.) Убирать все вручную или какими-нибудь автоматизированными средствами (про них напишу отдельно в следующий раз);
  2.) Что-то убрать руками, ядро заменить оригинальными файлами CMS;

  В данном случае я выбираю 2-й вариант, так как, это минимизирует шанс на то, что что-то останется после лечения. Почему? Из опыта и вида заражения. Как минимум, присутствуют файлы с нулевыми правами, названием, начинающимся с точки. Автоматизированные средства такое не увидят, из корневой директории удалим, но может быть зарыто и глубже. Можно искать такие файлы через ssh (первая команда ищет файлы с нулевыми правами, вторая скрытые файлы):

  find ./ -type f -name ".*"

  Но зачем, если можно поступить гораздо проще?

  Прежде всего нужно узнать версию MODx. Для этого пробуем пробиться в админку, временно (или навсегда =) меняя пароль какого-либо юзера с правами админа на свой:

  . Есть и другие способы узнать версию MODx, например через phpmyadmin, но в данном случае мне удобнее так.

  
  

  Имеем MODX Revolution 2.4.3-pl, смотрим на официальный сайт MODx в разделе "

  ": Released Feb 11, 2016 with 33,603 downloads

  Сайт сильно запустили. О необходимости обновления нужно обязательно написать в отчете (и в случае повторного заражения уже будет виноват сам клиент, так как неактуальная версия CMS, тем более на столько - является основанием для снятии с гарантии).

  Забираем "Traditional"-версию с полным пакетом для установки. Версия "Advanced" служит для обновления и не совсем подходит для полного восстановления ядра:

  
  

  Удаляем задание на создание stylewpp из cron, используем команду для редактирования файла заданий:

  или удаляем из планировщика все:

  Теперь удаляем все созданные планировщиком stylewpp (любым способом, через ssh, ftp или панель управления).

  Обязательно делаем бекап!

  Подключаемся через FTP, и убираем из корневой директории все, кроме пользовательских папок. Далее (действует только для MODx):

  
  

  7.) Желательно зайти в панели администрирования в менеджер пакетов и переустановить каждый из них;
  8.) В панели очищаем кэш и выполняем перегенерацию URL через меню "Управление" .

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

  1.) Смена паролей всех пользователей;
  2.) Смена пароля БД;
  3.) В корневой и папке core переименовываем ht.access на .htaccess ;
  4.) Устанавливаем причину заражения. Несложно догадаться, что скорее всего проэксплуатировали устаревший MODx, который содержит кучу CVE. Ну например вот эту

  . Но произошло это уже давно, поэтому определить 100% не получится, так как логи, увы, так долго не хранятся;
  5.) Делаем резервную копию очищенных файлов (на тот случай, если поломают до того, как клиент успеет обновить CMS);
  6.) Запускаем антивирус на хостинге (если таковой имеется) для того, чтобы хостер мог снять санкции или пишем письмо в тех.поддержку с просьбой об этом;
  7.) Пишем отчет клиенту || если делаем для себя - обязательно обновляемся.

  чт, 11/21/2019 - 12:00

  
  

  
  

  Я администрирую сайты с 2012 года. Специализируюсь на безопасности: удаляю вредоносные скрипты, устраняю уязвимости. Лечил как небольшие блоги, так и крупные интернет-магазины. Сегодня поделюсь инструментами, с помощью которых проверяю сайт на вирусы и удаляю их.

  Эта статья не для новичков: понадобится знание основ HTML, PHP и JS, а также умение работать в консоли.

  Что такое вирусы и как они попадают на сайт

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

  На сайте вирус, если:

  1. На страницах появился контент, который владелец не добавлял.
  2. Сайт стал работать медленнее.
  3. При переходе на него пользователи видят другой ресурс.
  4. Упала посещаемость из поиска.
  5. На хостинге появились новые папки.

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

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

  Убедиться в заражении

  Если есть подозрение на вирус, но уверенности нет, надо убедиться в заражении. Для этого я проверяю сайт через онлайн-сканеры, а также в нескольких браузерах и поисковиках.

  Онлайн-сканеры помогают быстро найти вредоносный код, но я никогда не полагаюсь только на них: не все вирусы можно найти автоматически. Вот несколько сервисов:

  Один из признаков заражения — редирект. Это когда при переходе на ваш сайт пользователи видят другой ресурс. Заражённый сайт с компьютера может открываться нормально, а с телефона посетителей будет перекидывать на фишинговую страницу или страницу с мобильными подписками. Или наоборот.

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

  Поисковые системы автоматически проверяют сайты на вирусы. Заражённые ресурсы они помечают серым цветом и подписью с предупреждением.

  Чтобы проверить свой сайт, введите адрес в поисковую строку Яндекса или Google. Если увидите предупреждение, значит, сайт заражён. Посмотрите вердикты и цепочки возможных заражений.

  Способ не универсальный! Поисковые системы находят вредоносный код не сразу. Кроме того, вирус можно научить проверять источник запроса и прятаться от поисковиков. Если такой вирус увидит запрос из поисковой системы, скрипты не отработают — поисковая система не увидит подвоха.

  Еще один вид вируса — дорвеи. Они встраивают на сайт свой контент.

  Найти и удалить зловредов

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

  Вредоносные скрипты часто добавляют в исходный код сайта (в браузере нажите Сtrl+U). Проверьте его на наличие посторонних JS-скриптов, iframe-вставок и спам-ссылок. Если найдёте — удалите.

  Проверьте все JS-скрипты, которые подключаются во время загрузки страницы, нет ли в них посторонних вставок. Обычно их прописывают в начале и в конце JS-скрипта.

  Все посторонние вставки удалите.

  Действительно, не всегда вредоносный скрипт — это отдельно подключенный файл, часто модифицируют один из существующих файлов. Если код обфусцирован, понять его не удастся. В таком случае стоит выяснить, в каком файле он находится.

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

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

  Ростислав Воробьёв, сотрудник техподдержки ISPsystem

  Если известно, когда взломали сайт, то вредоносный код можно найти по всем файлам, что были изменены с тех пор.

  Например, взлом произошел несколько дней назад, тогда для вывода всех PHP-скриптов, которые были изменены за последние 7 дней, нужно использовать команду: find . –name '*.ph*' –mtime -7

  После выполнения команды нужно проанализировать найденные PHP-скрипты на возможные вредоносные вставки.

  Это действительно помогает уменьшить список подозреваемых PHP-файлов, которые могут содержать зловредов. Однако не всегда зловреды в PHP-файлах. Немного модифицировав .htaccess файл, можно создать файл с разрешением .jpg, в нём разместить PHP-код и веб-сервер будет исполнять его как обычный PHP, но с виду это будет картинка — пример реализации.

  Ростислав Воробьёв

  Директории upload/backup/log/image/tmp потенциально опасны, так как обычно они открыты на запись. В большинстве случаев именно в них заливают shell-скрипты, через которые потом заражают файлы сайта и базу данных. Такие директории нужно проверять на возможные вредоносные PHP-скрипты.

  Например, каталог upload можно проверить командой: find /upload/ -type f -name '*.ph*'

  Она покажет все PHP-файлы в каталоге upload.

  После анализа заражённые файлы можно удалить вручную или командой: find /upload/ -name '*.php*' -exec rm '<>' \;

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

  Ростислав Воробьёв

  Все папки на хостинге нужно проверить на множественные php и html файлы в одной директории, сделать это можно командой:

  find ./ -mindepth 2 -type f -name '*.php' | cut -d/ -f2 | sort | uniq -c | sort –nr

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

  Быстро проверить сайт на вирусные скрипты можно командой:

  find ./ -type f -name "*.php" -exec grep -i -H "wso shell\|Backdoor\|Shell\|base64_decode\|str_rot13\|gzuncompress\|gzinflate\|strrev\|killall\|navigator.userAgent.match\|mysql_safe\|UdpFlood\|40,101,115,110,98,114,105,110\|msg=@gzinflate\|sql2_safe\|NlOThmMjgyODM0NjkyODdiYT\|6POkiojiO7iY3ns1rn8\|var vst = String.fromCharCode\|c999sh\|request12.php\|auth_pass\|shell_exec\|FilesMan\|passthru\|system\|passwd\|mkdir\|chmod\|mkdir\|md5=\|e2aa4e\|file_get_contents\|eval\|stripslashes\|fsockopen\|pfsockopen\|base64_files" <> \;

  Либо можно использовать grep без find.

  grep -R -i -H -E "wso shell|Backdoor|Shell|base64_decode|str_rot13|gzuncompress|gzinflate|strrev|killall|navigator.userAgent.match|mysql_safe|UdpFlood|40,101,115,110,98,114,105,110|msg=@gzinflate|sql2_safe|NlOThmMjgyODM0NjkyODdiYT|6POkiojiO7iY3ns1rn8|var vst = String.fromCharCode|c999sh|request12.php|auth_pass|shell_exec|FilesMan|passthru|system|passwd|mkdir|chmod|md5=|e2aa4e|file_get_contents|eval|stripslashes|fsockopen|pfsockopen|base64_files" ./

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

  Совпадений будет много, большинство найденных файлов не будут зловредами, так как модули CMS тоже используют эти функции.

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

  Часто во время взлома и заражения сайта вредоносный код добавляют в базу данных. Для быстрой проверки базы данных на вирусы нужно зайти в phpmyadmin и через поиск ввести по очереди запросы