Как найти скрытый бэкдор в WordPress с помощью WP-CLI и SQL
makedream٣٠ يوليو ٢٠٢٦
0
Internet Technology
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Нажимать кнопку обновления ядра на клиентском сайте WordPress — занятие не для слабонервных. Из-за страха, что темы или кастомные плагины сбойнут и экран «побелеет», обновление часто откладывается, а сайт тем временем обрастает уязвимостями. Когда нарастает тревога, что ресурс уже мог быть взломан, на помощь приходит этот практический регламент экспресс-проверки базы данных и сервера.
Злоумышленники обычно проникают незаметно. Наример, через прямое редактирование таблицы wp_usermeta в базе данных, ненавязчиво выдавая существующей учетной записи права администратора. В стандартном списке пользователей этого можно и не заметить, но прямой запрос к БД сразу всё прояснит.
`sql
SELECT
u.ID,
u.user_login,
u.user_email,
u.user_registered,
m.meta_value AS capabilities
FROM
wp_users u
INNER JOIN
wp_usermeta m ON u.ID = m.user_id
WHERE
m.meta_key = 'wp_capabilities'
AND (
m.meta_value LIKE '%"administrator"%'
OR m.meta_value LIKE '%"administrator":true%'
)
ORDER BY
u.user_registered DESC;
`
Следующий шаг — файловая система. Если в директории wp-content/uploads, где должны быть только изображения и документы, обнаруживаются файлы PHP, в девяти случаях из десяти это бэкдор. Открываем SSH-терминал и сканируем систему на наличие опасных файлов.
`bash
find wp-content/uploads/ -type f -name "*.php" -ls
find . -type f -name "*.php" -exec grep -HnE "(eval(|base64_decode(|gzinflate(|passthru(|shell_exec()" {} ;
wp core verify-checksums --include-root
`
Также необходимо изучить логи. Атаки, направленные на REST API, обычно за короткое время отправляют множество POST-запросов и получают ответы 200 или 201. Извлечем из Nginx access.log запросы с подозрительной реакцией сервера.
`bash
grep -E "POST|PUT" /var/log/nginx/access.log | grep -E "/wp-json/|rest_route=" | awk '/ {print $1, $4, $6, $7, $9}' | sort | uniq -c | sort -nr | head -n 30
`
Накатывать патчи прямо на боевой сайт — это не смелость, а скорее безрассудство. Сначала создаем стейджинг-окружение полностью скопировав базу данных и файловую систему.
`bash
wp db export production_backup.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' /var/www/html/ staging:/var/www/staging/
wp db import production_backup.sql
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid
wp plugin list --update=available --fields=name,version,update_version,requires_php --format=table
`
После завершения клонирования запускаем обновление и буквально 5 минут тестируем ключевые функции. Регистрация, вход, добавление в корзину, вызов окна оплаты, отправка формы обратной связи — лучше проверить все лично, чтобы спать спокойно.
Бывают неприятные ситуации, когда разработчик плагина не выпускает обновление, из-за чего невозможно сразу обновить ядро. В таких случаях нужно выиграть время, заблокировав доступ к определенным путям на уровне сервера или WAF. Если используется Nginx, в nginx.conf блокируем эндпоинты создания пользователей REST API и пакетной обработки для всех IP, кроме своего.
`nginx
location ~* ^/wp-json/(batch/v1|wp/v2/users) {
limit_except GET {
allow 192.0.2.1;
deny all;
}
try_files $uri args;
}
`
На случай непредвиденных обстоятельств дополнительно поднастроим скрипт бэкапа, который выгружает БД и папку uploads в S3.
`bash
#!/bin/bash
WP_PATH="/var/www/html"
BACKUP_DIR="/tmp/wp_backups"
DATE=$(date +%Y%m%d_%H%M%S)
S3_BUCKET="s3://my-wordpress-secure-backups"
mkdir -p $BACKUP_DIR
wp db export BACKUP_DIR/db_DATE.sql --path=$WP_PATH --quiet
tar -czf BACKUP_DIR/files_DATE.tar.gz -C $WP_PATH wp-content/uploads/
aws s3 cp BACKUP_DIR/db_DATE.sql S3_BUCKET/db_DATE.sql
aws s3 cp BACKUP_DIR/files_DATE.tar.gz S3_BUCKET/files_DATE.tar.gz
find $BACKUP_DIR -type f -mtime +7 -delete
`
Удаление вредоносного кода и установка патчей безопасности — это еще не конец. Злоумышленник может снова войти на сайт, используя украденные сессионные куки. Поэтому сбрасываем текущие сессии и полностью обновляем соли (salt) в wp-config.php.
`bash
wp user list --field=ID | xargs -n 1 wp user session destroy --all
wp config shuffle-salts
`
Также отключаем возможность редактирования файлов плагинов и тем прямо из админ-панели. Это минимальный защитный барьер, который предотвратит внедрение кода, даже если злоумышленник получит административные права. Добавляем следующие две строки в wp-config.php:
`php
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
`
Наконец, чтобы неавторизованные пользователи не могли просматривать список пользователей через REST API, добавим специальный фильтр в директорию mu-plugins.
`php
<?php
/**
`