Взлом WordPress и как с этим бороться.

Полученную на 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, wpconfig .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

ПРАВА ДОСТУПА

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

$ sudo chmod 400 wp-config.php

Для быстрой смены можно использовать find. Например, установим для всех файлов 644:

$ sudo find . -type f -exec chmod 644 {} +

Если меняем каталоги, то используем -type d. Также проверяем командой ls -al, кто владелец файлов. В Ubuntu/Debian обычно это www-data:www-data, но если используется панель администрирования, то будет, скорее, admin:www-data. Это тоже нужно учитывать при выставлении прав и при использовании специальных плагинов, которые могут помочь, а могут сделать сайт нерабочим.

Для проверки корректности прав можно использовать плагин Acunetix WP Security, который, кроме этого, умеет переименовывать учетную запись Admin, бэкапит базу, изменяет префикс таблиц wp_, усложняя XSS-атаку, показывает в онлайн-режиме текущую активность на сайте (включая Lookup IP), убирает некоторые заголовки и вывод отладочной информации и дает информацию для усиления защищенности.

Плагин Look-See Security Scanner верифицирует основные файлы WP, показывая отличия, проверяет конфигурацию, ищет спрятанные скрипты в основных каталогах, показывает информацию об известных уязвимостях в плагинах и темах. На самом деле подобных плагинов много, можно найти и другие, более удобные. Но увлекаться тоже не стоит: каждый лишний плагин — это еще одна потенциальная лазейка.

СМОТРИМ ЛОГИ

Журналы веб-сервера, МySQL и системные — просто кладезь информации по свалившейся проблеме. Изучая их, мы должны попытаться получить ответы на вопросы: что именно произошло, кто атакует и где искать проблему. В зависимости от настроек в логах возможна разная детализация данных, но обычно установок по умолчанию вполне достаточно, чтобы ухватиться за ниточку.

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

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

"GET /wp-admin/admin-ajax.php?action=getfile&/../../wp-config.php"

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

"POST /wp-content/themes/default/user.php"

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

$ tail -f /var/log/apache2/access.log | grep <IP-адрес>
$ cat /var/log/apache2/access.log | grep <IP-адрес>

И отправляем на блокировку iptables. Ищем в логах обращения к «запрещенным» файлам и каталогам сайта (wp-config.php, wp-admin, wp-login.php, .htaccess). Также проверяем все запросы, содержащие слова: mysql, function, connect, base64_decode, document.write, DOCUMENT_ROOT и так далее. Ничто не мешает составить команды для быстрого отбора нужных данных.

Например, выведем только IP и URL, к которым они получали доступ, подсчитаем и рассортируем:

$ cat /var/log/apache2/access.log | awk '{print $1" "$7}' | sort |
uniq -c | sort -rg

Вставив перед вызовом awk grep -i POST, можем отобрать только POST-запросы. Если добавить в конец команды | grep wp-login.php, мы увидим, сколько раз с IP пытались подключиться к определенному URL.

$ cat /var/log/apache2/access.log | awk ' { print $9 } ' | sort |
uniq -c

$ sudo apt install goaccess

$ goaccess -f /var/log/apache2/access.log

$ grep -i wp-login.php /var/log/apache2/access.log | goaccess -a >
report.html

$ MYSQL -uadmin -p
mysql> USE database;

mysql> SELECT * FROM wp_usermeta WHERE meta_key LIKE "wp_capabili-
ties";

mysql> SELECT * FROM wp_users WHERE ID = 1024;

mysql> DELETE FROM wp_users WHERE ID = 1024;

$ netstat -ant | grep 3306
tcp    0    0 0.0.0.0:3306    0.0.0.0:*    LISTEN

$ sudo iptables -I INPUT -d 127.0.0.1/8 -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

$ sudo iptables -I INPUT -s 148.251.105.254 -j DROP

$ sudo apt install fail2ban

$ sudo nano /etc/fail2ban/filter.d/wp-auth.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login.php
ignoreregex =

[wp-auth]
enabled  = true
port     = http,https
filter   = wp-auth
logpath  = /var/log/apache2/*.log

$ sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/fil-
ter.d/wp-auth.conf

$ sudo service fail2ban restart