По следам хакера. Разбираемся со взломом сайта на WordPress

WordPress — одна из самых популярных CMS, давно выросшая из обычного блогового движка в конструктор, позволяющий создать веб-ресурс практически любого назначения. На нем работают интернет-магазины, форумы, каталоги, веб-хостинги, сайты поддержки пользователей и многое другое. В то же время популярность имеет и обратную cторону: сайт на WP атакуют постоянно, и если тебя еще не взломали, то только потому, что просто еще не нашли среди миллионов других подобных ресурсов.

Тревожный сигнал

Несмотря на то что WordPress развивается уже достаточно давно и код все время анализируется, уязвимости в движке находят постоянно, и можно предположить, что продолжат находить и в будущем. Нужно отдать должное разработчикам: они оперативно реагируют на все сообщения и устраняют проблемы, а простота обновлeния позволяет администраторам легко обезопасить свой ресурс. Хотя анализ показывает, что далеко не все спешат обновляться. Но вот основные проблемы безопасности WP не в самом движке. Сегодня доступно большое количество тем и плагинов, которые пишутся программистами разного уровня и нередко содержат уязвимости. Некоторые темы и плагины распространяются через сомнительные сайты и уже изначально могут содержать бэкдоры. Добавим сюда некорректные настройки сайта, неверные права и использование учетных записей по умолчанию, позволяющие атакующему спокойно подбирать парoли, — и без дополнительных мер защиты сайт на WP обречен.

Итак, имеем несколько сайтов на WP разного назначения, размещенных в VDS. Стандартная связка PHP5 + Apache 2 + MySQL. ОС Ubuntu 14.04.3 LTS. Также были установлены панель управления хостингом Vesta Control Panel и phpMyAdmin. Последним, впрочем, никто не пользовался, и, по-моему, о его существовании даже не знали, хотя журналы показали, что и то и другое тоже пытались взломать. На момент атаки движок блога, активные плагины и Vesta были обновлены до актуального состояния. Используемые темы в большинстве взяты из бесплатного каталога и подогнаны под свои условия. Бэкап SQL делался еженедельно, бэкап файлов — очень давно. Все это работало до поры до времени.

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

Следующий сигнал поступил от поисковых систем. Причем сообщения и, очевидно, алгоритмы работы у Яндекса и Google отличаются и по-разному полезны. Яндекс сообщил, что на сайте обнаружен вредоносный контент, в панели веб-мастера сайт был помечен соответствующим значком, указан предполагаемый тип (троян JS), и в поиске выводилась информация о том, что ресурс может навредить. Сразу скажу, что код, который раздражал Яндекс, был найден в файле заголовков почти всех тем в файле header.php, и после того, как он был убран, все сайты в течение одного-трех дней были признаны чистыми. Хотя в это время битва еще продолжалась.

Google прислал сообщение спустя шесть часов после Яндекса, но отметил, что на сайте обнаружен «взломанный контент», в панели можно было просмотреть список подозрительных файлов (на момент получения письма большинство было найдено и удалено). Информация сама по себе интересна, так как в ней указаны новые файлы, оставленные хакером, на которые нет прямых ссылок на сайте. Такие файлы, скорее всего, однозначно нужно будет удалять. Гугл в сообщении предлагает ссылку на «Инструмент для восстановления взломанных сайтов», позволяющий просмотреть, как выглядит сайт, и рекомендации. После удаления файлов необходимо вручную отправить на перепроверку те сайты, у которых при использовании site: в строке поиска показывает «Возможно, этот сайт был взломан». Позже Гугл убрал отметку об опасности части сайтов и начал выдавать сообщение о том, что на сайтах появилось большое количество ошибок. Проблема 404 возникла либо из-за некорректно внедренного кода, когда часть URL не работала, либо из-за того, что код ссылался на вредоносный файл, который уже был найден и удален.

Забегая вперед, скажу о результате. Атака шла с нескольких IP и массированно началась за три дня до взлома. Обнаружилось большое количество лишних файлов с расширением php, которые были разбросаны по всем каталогам, плюс каталог gopni3d с кучей HTML-файлов внутри. Здесь и шелл, и бэкдор-загрузчик, и дорвей, и рассыльщик спама. Внедрен PHP- и JS-код в тему header.php и некоторые файлы WP, включая wp-config.php. Изменен файл .htaccess. В WP появились две дополнительные учетные записи с правами администратора. Каталог SMTP-сервера /var/spool/exim4/input был завален большим количеством спам-писем.

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

Код, оставленный хакером

Первые шаги

Можно отключить сайт, остановив веб-сервер или переведя WP в режим обслуживания, но мы пока не знаем, что искать. Если отключить невозможно, то на этом этапе можно запретить регистрацию новых пользователей и комментарии, изменить пароли администратора WP и пароли к СУБД. При наличии свежего бэкапа можем восстановить сайт, затем перейти к анализу и заняться локализацией проблем и усилением защиты. Иначе придется чистить файлы вручную. Как минимум можно сразу заменить файлы WP новыми из архива, удалив предварительно старые файлы и каталоги (кроме, естественно, каталогов тем, плагинов и upload). Далее обновляем (если не сделали это раньше) движок, тему и плагины. Неактивные темы и плагины безоговорочно удаляем. Проверяем сами плагины. Хакер некоторые просто отключает, изменив название каталога (добавив знак подчеркивания в начало). Проверяем корректность файлов .htaccess, их содержимое хакер может просто обнулить. Если файл .htaccess был неправильно настроен, то к файлам сайта можно получить доступ из поисковика: site:example.org inurl:/wp-admin/. Переименуй тему, некоторые атаки идут пакетом, когда просто подбираются уязвимости к популярным темам. Переименовав тему, мы изменим URL, а значит, такая атака ее минует. Если до сих пор не использовалась капча, то ставь любой понравившийся плагин. Это снизит вероятность брутфорса. Некоторые к тому же предоставляют дополнительные возможности: блокировку IP в случае неправильного ввода несколько раз, ограничение по времени ввода, белый список. Проверять на зараженность можно как изнутри при помощи инструментов, доступных в ОС, так и через внешние сервисы. Запускаем антивирусную проверку.

$ sudo clamscan -i -r /var/www  /var/www/wp-content/plugins/akismet/_inc/img/sidebar-widescreen.php.suspected: Php.Malware.Agent-1426825 FOUND

Кроме антивируса, можно прогнать еще сканер Linux Malware Detect и скрипт AI-Bolit. Но найдут они не все.

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

В Сети доступно множество ресурсов, проверяющих, безопасны ли сайты. Не все они полезны. Некоторые, например, просто получают данные о вредоносности от API Яндекса и Гугла. Услугу проверки URL предлагают и производители антивирусов. Например, сканер от Dr.Web проверяет страницы и анализирует, есть ли редирект на другие сайты. К сожалению, кроме того, что сайт заражен, и типа вируса, больше никакой полезной информации он не дал. Ресурс 2ip.ru показал, что на сайте обнаружены iframe-вставки. К сожалению, для повторной проверки он бесполезен, так как, очевидно, запоминает результат и сообщает, что сайт заражен, когда все остальные уже считают его безопасным.

Наибольшую пользу в поиске принес онлайн-сканер SiteGuarding.com, специально разработанный для поиска специфических вредоносных программ. В отчете были не только показаны проблемные ссылки, но и дана конкретика, позволяющая в дальнейшем найти этот код в файлах при помощи grep. Проект предлагает и свой плагин WP Antivirus Site Protection, доступный из каталога плагинов WP. В бесплатной версии он сканирует файлы, проверяя их на наличие опасного кода, и выдает отчет по обнаруженным malware и файлам, показавшимся подозрительным эвристическому анализатору. Правда, выданное не стопроцентно проблема, но это уже что-то. Число сканирований ограничено, но этого достаточно, чтобы решить проблемы и некоторое время контролировать ситуацию.

Отчет плагина об обнаруженном malware

Полученную на SiteGuarding.com информацию о коде малвари скармливаем grep. Принцип простой: берем некий уникальный кусок (например, там указан URL сайта, на который идет редирект, или имя файла) и пробуем найти этот текст в остальных файлах веб-сайта.

$ grep -iR example.org /var/www/

Если при ручной разборке будут попадаться зараженные файлы, то анализируем и небольшой кусок уникального текста также предлагаем grep для поиска других аналогичных файлов. Код в файлы сайта вставляется либо в начало, либо в конец, и он, в отличие от остального, плохо структурирован, то есть идет сплошной массой. Это сразу бросается в глаза в любом текстовом редакторе, особенно с подсветкой кода. Но бывает, код специально отбивают за пределы видимой части экрана вправо или вниз. Можно составить небольшой скрипт, чтобы сразу вырезать кусок кода. Правда, остатки потом найти будет сложнее. Например, в decode использована последовательность HtI9Opn...Z. Создаем такой скрипт:

$ nano virusdel.sh  #!/bin/bash  virus='eval(base64_decode("HtI9Opn.*Z=="));'  find . -type f -name '*.php' -exec sed --in-place -e "s/$virus//g" '{}' ;

Запускаем:

$ chmod +x virusdel.sh  $ ./virusdel.sh

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

$ find /var/www/ -name confg.php

Время доступа к файлам не всегда выдает его модификацию, но вот различие в размерах файла и количестве файлов в каталоге по сравнению с оригинальным бросается в глаза сразу. И мы можем легко сравнить два каталога при помощи diff или вручную, открыв два окна в mc. Самый простой diff -aqr dir1 dir2 покажет только отличающиеся файлы без самих изменений, полный diff -ruN > out.diff выдаст информацию в стиле patch. Внутри каталогов обнаружилось большое число лишних PHP-файлов, некоторые называются похоже на файлы WP или так же, но лежат в другом каталоге. Например, class-wp-*.php, wp-config .php (с пробелом). А также всякие users.php, confg.php, about.php и случайные имена (вроде a249yh.php, их легко заметить).

Каталог /var/spool/exim4/input был буквально забит спам-сообщениями. Количество сообщений в очереди, выведенное exim -bpc, достигало нескольких тысяч. Вывод ps aux показывал процесс sendmail, пытавшийся отправить письмо от неизвестного пользователя с доменом сайта. Чтобы не рассылать спам, SMTP-сервер лучше пока остановить. При попытке очистить командой rm -rf /var/spool/exim/input/* bash вываливался с ошибкой из-за большого количества файлов. Можно использовать маску и удалять файлы по частям, но в случае с exim проще ввести

$ sudo exipick -i | xargs exim -Mrm

Права доступа

Далее следует пересмотреть права доступа — ужесточить их по максимуму. Это позволит остановить атаку, не дав хакеру продолжать модифицировать файлы. Потом можно будет вернуть нормальные права.

Извини, но продолжение статьи доступно только подписчикам

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

Уже подписан?