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

Автор: Роман Чернышов    Опубликовано: 26 июля 2021

Доброго времени друзья! Недавно ко мне обратился мой постоянный клиент с проблемой возникшей на его сайта, который без видимых на то причин стал медленно работать. Лишь на один запрос к главной странице, сервер висел до 30 секунд. После изучения проблемы стало понятно, что мы имеем дело с обширным заражением сайта вирусом, множество PHP скриптов были повреждены или содержали вредоносный код. Ранее, мне уже многократно приходилось сталкиваться с подобного-рода проблемами, в том числе и на своих сайтах. Поэтому процесс поиска, лечения с устранением последствий, прошел достаточно быстро, можно сказать — по отработанной схеме. Мне уже не раз приходилось писать подобные отчеты о проделанной работе для своих клиентов, в этот раз я решил оформить его в виде статьи и поделиться с вами. Далее обо всем подробнее.

О вирусе

C котором пришлось иметь дело в этот раз

В составе: PHP Shell — файл менеджер с обширным функционалом управления на стороне сайта, также его функционал позволяет выполнять различные серверный команды, с использованием PHP команды exec(). Mailer — отправка E-mail сообщений, Redirect — использование сайта как прослойку для редиректа на другие ресурсы. Разумеется весь код обфусцирован, минифицирован и зашифрован, поэтому для его анализа придется прогнать код(несколько раз, т.к. используется многослойная шифрование кода) через деобфускатор и дешевратор. К счастью, все методы шифрования вируса сводятся в применению таких функций как Bese64, собственной реализации XOR(применение ключа через побитовое исключающее, шифрование побитовым сдвигом).

Сам же PHP код и функционал скриптов не так интересен, как правило там практически всегда можно найти то, что доступно публично, устаревшие шеллы и прочие утилиты. Каких-либо уникальных разработок в нем нет, что в какой-то мере свидетельствует об уровне компетенций его «хозяина». Часто такие решения и их описание распространяются на тематических «темных» форумах, где любой желающий(школьник) может использовать их просто следуя инструкции. Ориентированы они чаще всего на устаревшие версии CMS, неактуальные плагины, библиотеки кода и т.д., которые применяются в работе сайта.

В составе такие файлы как: wp-load.php, с содержанием вредоносного кода и части кода от CMS WordPress, что говорит о том, что вредоносный код ориентирован на работу с движком WordPress(мимикрирует, маскируется под оригинальные файлы).

Характер распространения — автоматический. О чем свидетельствует моментальное воспроизведение файлов вредоносного кода после его удаления, отсутствие попыток замаскировать его под CMS(Bitrix) на котором работает сайт(вместо этого, маскируется, как написал выше, под Worpress), а также одинаковость в названиях файлов(при повторной записи на хостинг), местах записи кода(часто в одни и те же файлы), характера действий в целом. При управляемой атаке человеком, действия были бы другими, более продуманными и разными.

Самовоспроизведение(восстановление) вируса в системе: Путем запуска непрерывного(перезапускаемого) PHP процесса, который содержит в себе вредоносный код и постоянно перезапускается(каждую секунду) с использованием команды pcntl_exec(), с последующей перезаписью файла содержащего вирус. Таким образом, если удалить файл, то он восстановиться из памяти запущенного PHP процесса.

Характер действий: Добавление вируса в оригинальные файлы CMS. Создание новых файлов содержащих только сам вирус. Запуск непрерывного процесса PHP, чтобы сохраняться в памяти сервера на случай удаление файлов. Перезапись .htaccess, с установкой собственных настроек сервера и прав доступа к каталогам.

Кто за этим стоит?

Очень интересно, кто же за всем этим стоит, кто пишет эти вирусы и кто их распространяет. Как ни странно, как правило автор вируса и его распространить разные люди, если автор еще имеет хоть какую-то квалификацию в стане разработчиков программного обеспечения, то вот распространитель, как правило представляет собой просто пользователя, который в свою очередь хорошо изучил как работать с уже готовым софтом, но увы не более того. «Хакерский софт» это как правило набор утилит в купе со скриптами эксплуатирующими уязвимости в популярных CMS, которые(как софт, так и информацию об уязвимостях) можно найти на специализированных форумах, каталогах, блогах посвященных сетевой безопасности. Такие «пользователи», которых кстати реальные хакеры(Hacker), называют крякеры(Cracker), объединяются в «хакерские» команды(если это так можно назвать, хотя они себя именно так и называют), где каждый выполняет какую-то отведенную для него роль. Вот пример саморекламы(в чем скромности им не занимать) таких нескольких объединений(все скриншоты сделаны с сайта моего клиента):

О их саморекламе. Одной из целей хакерских атак, является самолюбование с последующим вымогательством некой денежной суммы, как правило любой, начиная с пары тысяч евро и заканчивая хотя-бы мятой десяткой, на сколько удастся развести. В качестве саморекламы, на сайт жертвы загружается некая презентация, с красивыми картинками, музыкой и конечно же контактными данными. Все это сопровождается надписями: «You hacked by Ideosec team», или что-то подобное. В расчете на то, что жертва с перепугу или от безысходности свяжется с ними и попросит помилования, за вознаграждение.

Возможно среди них есть и те, кто реально достоин называться — хакером, может быть в их командах есть толковые разработчики, но пока те с кем мне удалось пообщаться, написав на емаил указанный на страницах их саморекламы, оставили жалкое впечатление — после того когда они узнавали что их вирус(шелл) был безжалостно удален, а на сайте подлатаны все «дыры», что в свою очередь означает, что с жертвы денег не получить, кто-то переходил на угрозы повторить атаку, а кто-то просто клянчил(попрошайничал) прося перевести на их счет хоть какую-то сумму денег, мол якобы на жизнь: «Bro,sent me small amount money for tonigth».

Последствия

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

1. Повреждение PHP файлов сайта, что приводит к выходу из строя всего сайта(на стороне посетителя это может выглядеть как просто белый экран, пустая веб-страницы или вывод ошибки интерпретатора PHP);
2. Повреждение файлов, перезапись файла настроек веб-сервера .htaccess, из-за чего перестает работать маршрутизация mod-rewrite, перестают открываться разделы на сайте, нет доступа к админпанели и т.д.
   2.1 Множественное создание файлов .htaccess во всех доступных вирусу каталогах.
   С содержимым(само по себе оно безвредное, но эти настройки закрывают доступ к папке из вне, видимо так он защищался от чего-то.):
   Последствия: например при отправке Ajax запроса к серверу, на скрипт компонента CMS, можно получить такой результат в качестве ответа:
   
3. Добавление вируса в код оригинальных PHP файлов, с последующим его выполнением, при каждом обращении к оригинальному файлу, что приводит к снижению скорости работы сайта;
4. Добавление вируса в память сервера в виде перезапускаемого(вечного) PHP процесса. Снижение скорости работы сервера (вообще любая деятельность вируса, съедает ресурсы сервера);
5. Возможные санкции от поисковых систем(Яндекс, Google) с меткой — вирусный;
6. Возможное ухудшение поведенческих факторов(влияния пользователей на метрики) сайта, в силу того, что например: пользователи будут уходить с сайта, жаловаться и т.д.;
7. При недоступности страниц, выпадение их из индекса поисковых систем;
   
8. Удаление важных файлов без возможности их восстановления(полная потеря);
9. Повреждение базы данных;
10. Рассылка емаил спама от имени сервера(сайта), возможные санкции по IP от систем анти спама;
11. Кража данных доступа, к прочим сторонним сервисам, API и т.д., хранящихся в PHP файлах конфигурации;
12. Утечка информации из базы данных (пользователей, прочей информации).

Лечение

Каждый случай уникален, соответственно и методики лечения требуется каждый раз свои

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

1. Перезапуск процесса httpd(apache, nginx), остановка всех связных процессов на сервере, для удаления из памяти всех ранее запущенных процессов PHP (удаление вируса из памяти);
2. Удаление полностью, файлов содержащих вредоносный код в ручном режиме, если это файлы НЕ относящиеся к файлам сайта (без первого пункта, этот шаг бесполезен, т.к. вирус восстановится из памяти);
3. Удаление только вредоносного кода из файлов, если эти файлы относящиеся к файлам сайта CMS, удалять их нельзя. тут требуется деликатная работа с кодом и навык веб-разработчика;
4. Прогон всех файлов сайта через ImunifyAV (антивирус для серверных скриптов, PHP), в автоматическом режиме, с последующим ручным удалением(редактированием). Надо отметить, что на данные скрипты PHP ругается даже встроенный Windows антивирус(Защитник);
   4.1 Уместно будет прогнать сайт утилитой типа Ai-Bolit Scanner, но данное решение уже не поддерживается, также оно требует немалых ресурсов сервера т.к. работает на том же PHP, подойдет не всем, но иногда результат стоит того;
   
5. Восстановление файлов, перезаписанных вредоносным кодом(в случаях когда удален оригинальный код) на оригиналы;
6. Установка прав CHMOD на все файлы 0644, на директории 0755, CHOWN;
7. Смена всех паролей: FTP, SSH, MySQL, панель хостинга;
8. Изучение всех основных разделов сайта, используемых ими библиотек, а также служебных файлов(созданных разработчиками сайта), на предмет явных уязвимостей;
9. Удаление всех служебных(вспомогательных) PHP скриптов из корня сайта, оставленных разработчиками, которые позволяли получать всю информацию о сервере любому желающему, например разработчики часто оставляют скрипты выводящих распечатку команды phpinfo();
10. Ручной поиск по всем файлам сайта с использованием фрагментов, в качестве искомой строки, ранее найденных файлов текста кода вируса, с их(найденных файлов) последующим удалением. Например тот же .htaccess созданный вирусом, был размножен более чем по 40 тысячам папок, что разумеется нарушало работу сайта!

Также в поиске можно использовать другие схожие параметры файлов: дата/время создания, размер, название.

Возможные способы проникновения вредоносного кода на сайт

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

1. SSH/FTP. Пароли чаще всего крадутся с компьютера пользователя, будь то самого владельца сайта или разработчика. Любой ПК может быть заражен вирусом, который хранит передаваемые или сохраняемые(в том числе в файл-менеджерах) данные доступа. Также распространен метод подбора пароля(Брутфорс) путем перебора;
2. Размещение на сайте устаревших PHP(и прочих) скриптов, публичных модулей CMS, плагинов и т.д. Зачастую их код доступен всем желающим, на предмет изучения в них уязвимостей, это дает возможность злоумышленнику найти уязвимость и воспользоваться ею, выполнив SQL-инъекцию например. Более того, все найденные ранее уязвимости, как правило публикуются в специальных каталогах, с полным описанием как ими воспользоваться. Каталоги доступны всем желающим, без ограничений. Как правило разработчики быстро устраняют уязвимости и выпускают новые версии программного обеспечение(если повезет конечно). Но, если вы вовремя не обновитесь, велик шанс что уязвимостью воспользуются;
3. Размещение на сервере устаревшего программного обеспечения уровня операционной системы. Аналогично предыдущему пункту, но в данном случае речь о пакетах ПО для Linux/Windows;
4. Атаки типа XSS, Mitm, CSRV.

Рекомендации

Как и в случае с лечением, рекомендации для каждого случая уникальны, но есть и ряд универсальных советов, не пренебрегайте ими

1. Периодически менять пароли.
   — Админпанель, раз месяц;
   — SSH/FTP раз в месяц или после каждой работы стороннего разработчика;
   — MySQL раз в 3-6 месяцев;
   — Сторонние сервисы, API, раз в 3-6 месяцев.
2. Обновлять CMS, модули и плагины. Если на сайте есть сторонний код, не входящий в состав CMS, а просто размещенный на хостинге, также обновлять его библиотеки в ручном режиме. Ставить задачу разработчику проверять наличие обновлений сторонних библиотек хотя бы раз в пол года — год;
3. Удалять все неиспользуемые скрипты, библиотеки, размещенные на сайте;
4. Не допускать наличие на сайте служебных файлов, которые оставляют разработчики, в ходе проведения своих работ, например файлы типа: 1.php с содержимым в виде одной строки <? phpinfo(), что позволяет любому желающему зайти по адресу данного скрипта и узнать всю информацию о PHP и сервере;
5. Разделить права доступа к сайтам(если на сервере, хостинге несколько сайтов) example1.ru и example2.ru по SSH/FTP. Для каждого сайта свой доступ;
6. На сервере создать двух независимых пользователей, с ограниченным доступом к каталогам двух разных сайтов, один к example1.ru второй к example2.ru, и назначить разные права владельцев CHOWN на директории и файлы обоих сайтов. Чтобы в случае заражение первого сайта, вирус не мог при наличии привилегий добраться до второго;
7. Периодический бекап файлов и БД. Так как общий объем всего бекапа может составлять не один ГБ делать полный бекап хотя бы раз в месяц, и частичный раз в неделю;
8. Установка на сервер ImunifyAV Free (бесплатную версию), для работы в автоматическом режиме и анализом отчета раз в неделю-две;
9. (для продвинутых) В перспективе, мониторинг всех php скриптов на сайте по их хешу(хеш файла по MD5, например), чтобы в случае их изменения(или появления новых файлов) система сигнализировала об этом администратору;
10. Полное сканирование ПК всех пользователей, кто имеет доступ к SSH/FTP сайта, бесплатными утилитами типа Dr.Web CureIt и Malwarebytes Free;
11. Ручной поиск по всем файлам с использование масок по содержимому, дате и времени, размеру, именам файлов.

Оставшиеся риски

К сожалению 100% гарантии, что это не повториться дать невозможно

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

Заключение

Вирусные атаки с проникновением на сайт происходят очень часто, к сожаления в большинстве случаев причинами является то, что владелец сайта не уделяет должного внимания рекомендациям по безопасности(таким как я описал выше), более того, в подавляющем большинстве случаев владелец сайта даже не подозревает, что его сайт заражен вирусом. Такое положение дел может сохраняться годами, тем временем злоумышленник, как пиявка, будет высасывать все возможные ресурсы из сайта: рассылка спама, размещение рекламы или ссылок, кража данных, перенаправление трафика, а иногда даже майнинг на мощностях сервера или еще круче на стороне пользователей(посетителей вашего сайта) прямо в браузере используя JS(почему бы и нет?).

Я же, всегда рад оказать вам помощь в поиске и лечении(избавлении) сайта от вредоносного кода, а также в устранении последствий его работы, в том числе, применив все свои навыки веб-разработчика…

Обращайтесь!

CMS, PHP     безопасность, защита сайта, лечение от вирусов