Замысловатый троян под WordPress

Автор: Денис Синегубко

Троян (или троянский конь) – программа, под видом красивой обертки незаметно проворачивающая всякие темные дела. Типичный вредонос под WordPress представляет собой плагин или тему (обычно пиратскую), которая содержит дыру или отсылает спам или генерирует дорвей или инжектирует ссылки или делает все вместе взятое. Общая схема заражения довольно проста: вебмастер устанавливает полезное дополнение, внутри которого упакован троян.

Недавно мне на глаза попалась находка, которую я бы назвал «замысловатый» троян – вредонос (устанавливается без ведома вебмастера), расширяющий функциональность WordPress.

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

Главный вредоносный файл wp-core.php кладется в корневую директорию сайта, после чего в index.php добавляется следующий код:

if ( file_exists( 'wp-core.php' ) ){ require_once( 'wp-core.php' ); }

Подобная вставка выглядит очень подозрительно и говорит о том, что файл wp-core.php установлен искусственно и в обход всех соглашений и стандартов.

Заглянем вовнутрь wp-core.php.

Защита от брутфорса в wp-core.php

Wp-core.php содержит более 500 строк кода. Начало файла говорит о том, что wp-core.php – часть пакета, отвечающего за безопасность WordPress, который «Защищает WordPress CMS от брутфорса и используется редирект на основе 302-й ошибки для защиты от утечки поискового веса страницы». Далее говорится, что файл должен быть загружен напрямую самым первым.

Рисунок 1: Начало файла wp-core.php

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

В середине файла начинается самое интересное.

Вначале в файл wp-login.php инжектируется защита от брутфорса.

Рисунок 2: Код, изменяющий файл wp-login.php

Из рисунка выше видно, что добавляется обработчик на событие «onsubmit» на форме авторизации. Обработчик устанавливает в cookie переменную antibot_ajax. Далее проверяется, если в куках вышеуказанная переменная отсутствует, авторизация отклоняется. На первый взгляд, кажется, что код и правда защищает от ботов, которые не используют JavaScript. Не сказать, что решение идеальное, но и не несущее каких-то вредоносных функций.

Далее переходим к секции Auth 2nd level:

Рисунок 3: Секция Auth 2nd level

Эта секция уже выглядит более подозрительно, поскольку инжектируется зашифрованный код (опять в файл wp-login.php). После расшифровки код выглядит весьма невинно и выполняет именно то, о чем написано вначале: «второй шаг аутентификации». Если имя/пароль правильны, из базы данных извлекается эл. почта, заменяются звездочками все символы, начиная с третьего и до знака «@», после чего пользователя просят ввести полный адрес:

Рисунок 4: Форма для подтверждения электронного адреса

Даже если бот поддерживает JavaScript и прошел первый уровень проверки, на втором уровне от бота потребуется знание электронного адреса (т.е. скорее всего этот уровень пройден не будет). То же самое касается злоумышленника, которые подобрал имя/пароль.

У пользователей, подтвердивших свой адрес, в куках устанавливается переменная WP_FLV_EMAIL_CONFIRMED на 10.000 дней (т.е. не нужно каждый раз подтверждать свой адрес).

В последней части кода происходит добавление wp-core.php в файл index.php (см. в начале статье). Скрипт постоянно следит, чтобы «защита от брутфорса» была постоянно включена. В случае удаления, код вновь добавляется в файл wp-login.php.

Рисунок 5: Изменение файла index.php

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

На первый взгляд ничего подозрительного. Верно? Не спешите с выводами. Как было сказано ранее, файл wp-core.php содержит более 500 строк кода. К защите от брутфорса относится менее 100 строк. Вопрос напрашивается сам собой. Для чего нужен остальной код? (около 80% файла wp-core.php)

Вредоносная часть файла wp-core.php

Остальная часть кода не имеет никакого отношения к защите WordPress. На самом деле, все делается с точностью наоборот.

Например, можно вывести список всех почтовых адресов из базы WordPress (хотя, эта функция чуток дырявая и будет работать далеко не везде). Кому нужна дополнительная аутентификация, если для получения списка почтовых адресов никакой авторизации не требуется?

Также устанавливается открытый редиректор. Теперь злоумышленники могут использовать сайты с подобной «защитой от брутфорса» для спама, фишинга и распространения вредоносов. Все посетители будут перенаправляться на сайты, на которые укажут хакеры.

Создание дорвеев

Основная функция wp-core.php – управление дорвеями под фармацевтическую тематику. Если в URL’е блога присутствует специальный параметр (например, «th» - http://www .example .com/?th=doryx+150mg+exclusivity) вместо появления человеческого текста генерируется дорвей.

Если посетители не боты и приходят с популярных поисковых систем, происходит перенаправление на TDS (traffic directing system, система распределения трафика). В качестве параметра передается ключ посещенного дорвея. На данные момент используются следующие TDS’ки:

• hxxp:// alltds .com/v2/search.html?key=…
• hxxp:// besttdsfarma .com/site/search?q=…

Рисунок 6: Редиректы, обнаруженные сервисом Unmask Parasites

Перед редиректом вредонос устанавливает в cookie параметр URL’а дорвея (например, для URL’а ?th=doryx+150mg+exclusivity в cookie установится имя «th»). Следующие 100 дней тот же самый пользователь при повторном посещении (даже не из поисковой системы) будет перенаправлен снова.

Если у посетителя отсутствуют нужные cookie или посетитель пришел не из поисковой системы или это бот, тогда отображается спам-страница со множеством фармакологических ключей и ссылок на другие дорвеи, созданные по той же технологии.

Содержимое дорвеев хранится в файле wp-admin/update-backup.db.

Атаке подвержен не только WordPress

Следует упомянуть, что, хотя вредонос заточен под работу с WordPress (специфическая защита от брутфорса, пути и имена файлов, возможность генерации дорвея на основе текущей темы и т. д.), другие PHP-сайты, использующие index.php в качестве основного индексного файла, также уязвимы. Единственное отличие - не будет задействована функция, заточенная под WordPress, и дорвей будет генерироваться на основе заранее подготовленного шаблона из файла update-backup.db, который, в случае с сайтом не на базе WordPress, будет находиться в коревой директории.

Заключение

Вредонос представляется мне весьма странным.

• Троян нацелен все PHP-сайты и инжектирует себя в файл index.php (который можно найти практически на каждом PHP-сайте). Однако в то же время, главная цель – сайты на базе WordPress.
• По причине того, что главная цель – WordPress, используется имя файла wp-core.php, которое выглядит правдоподобно в WordPress, но весьма странно в Joomla или vBulletin.
• Инъекции в файлы Index.php и wp-login.php наряду с файлом wp-core.php легко детектируются большинством плагинов, отвечающих за безопасность, которые проверяют целостность файлов в WordPress. Чтобы инъекции выглядели менее подозрительно, вредонос содержит код, добавляющий полезный функционал в WordPress.
• Хотя «защита от брутфорса» работает, автор вредоноса почему-то поместил код в середину wp-core.php, а не в начало, где код был бы более заметен. Первые не закомментированные строки того файла сразу вызывают подозрение. Зачем заморачиваться с защитой, если у того, кто понимает PHP-код, сразу поймет, в чем дело, а для того, кто не знаком с PHP, вполне достаточно простых комментариев.
• Обычно хакеры скрывают вредоносный код в больших легитимных файлах. Как правило, за основу берется код из плагина или модуля. В данном случае я не смог найти источник «кода, защищающего от брутфорса». Либо этот фрагмент кода взят из менее популярного плагина, либо был написан с нуля.