Аккумулируем базовые знания, методы атак и нюансы самой популярной open-source CMS в рамках одного доклада.
9 декабря 2022 года я выступил на митапе «Клуба неанонимных багхантеров» от BI.ZONE. Там я рассказал об экосистеме WordPress: затронул структуру этой CMS, перечислил ее сильные и слабые места, а также упомянул тонкости базовой функциональности, о которых порой забывают владельцы сайтов. К сожалению, большая часть информации просто не влезла в тайминг. Поэтому публикую дополненную версию доклада здесь.
ИНТРО
О чем речь?
На митапе я рассказал о базовой структуре WordPress, ее особенностях с точки зрения атакующего, слабых местах, малоизвестных опциях. Разумеется, я не обошел вниманием предопределенные роли, способы сбора информации о цели, типичные методы обеспечения защиты, методы атак и пост-эксплуатации.
Почему CMS WordPress?
Не секрет, что WordPress — самая популярная open-source CMS из всех представленных на рынке. По данным W3Techs на февраль 2023 года, 43,1% всех сайтов работают под управлением CMS WordPress, а количество сайтов с этой системой управления пока продолжает расти. Среди всех известных систем управления доля WordPress составляет 63,4%, что делает ее безусловным лидером в этой нише. Кроме того, в одном только официальном репозитории wordpress.org более 60000 плагинов и более 9000 тем оформления.
Еще один фактор — существование багбаунти- и плагбаунти-программ для этой CMS, включая приватные, а также возможность получить CVE ID, заявить о себе сообществу и общий невысокий входной порог. Все это может обеспечить дополнительный интерес со стороны исследователей безопасности, пока система находится на пике популярности.
А теперь о насущном: порядка 90% уязвимостей в этой системе управления приходится на плагины, на темы — всего 6%. Оставшиеся 4% — уязвимости ядра WordPress. Есть где развернуться и исследователю, и злоумышленнику.
Цель доклада
Основные цели моего доклада — обзор и структурирование базовых представлений о CMS WordPress и восполнение недостающих фрагментов информации. Также я рассказываю о малоизвестных опциях, способах атаки на данную систему управления контентом и необходимом для этого инструментарии.
Второстепенная цель доклада — обратить внимание на классические ошибки при взломе сайтов под управлением этой CMS.
СИСТЕМА
Структура CMS WordPress
Ничего необычного в структуре движка нет: 3 директории (./wp-admin/*, ./wp-includes/* и ./wp-content/*) и 16 файлов в корне установочной директории, из которых стоит отметить только ./wp-config.php и ./xmlrpc.php. В первом хранится информация для подключения к базе данных и некоторые тонкие настройки системы, второй используется для удаленного доступа к сайту, если такая функциональность нужна и настроена.
Со стороны атакующего будет большой глупостью вмешиваться в работу директорий ./wp-admin/* и ./wp-includes/*. Любая активность в них будет оперативно выявлена многими плагинами безопасности, так что это явно лишний риск быть обнаруженным. Даже если на этапе перечисления плагин безопасности выявлен не будет, это не дает 100%-й гарантии, что защиты у сайта нет вообще.
Наибольший интерес для злоумышленников представляет третья директория — ./wp-content/*, внутри которой хранятся файлы плагинов (./wp-content/plugins/*), тем оформления (./wp-content/themes/*), конфигурационные файлы плагинов безопасности и плагинов оптимизации, загруженные медиафайлы (./wp-content/uploads/*), резервные копии и даже лог ошибок (./wp-content/error.log). Иными словами, эта директория предназначена для постоянного создания, обновления и удаления файлов и директорий внутри нее, и по этой же причине там есть где оставить свой след атакующему с минимальным риском обнаружения.
Упомяну и WordPress REST API (он же WP REST API, WP API). Функциональность большая, гибкая, и разработчики иногда заигрываются с ней, напрочь забывая о безопасности, что на выходе открывает атакующему некоторые интересные возможности. Для наглядности перейдите по ссылке и посмотрите раскрытые отчеты.
Изначально и без должного внимания со стороны администратора WP API может быть довольно информативен для атакующего. Примеры: 1 (посмотрите маршруты — routes), 2, 3 (сначала посмотрите как гостевой пользователь, а потом войдите в свой аккаунт).
В некоторых случаях WP API дает атакующему возможность скомпрометировать сайт — к примеру, как это случилось с этим плагином, автор которого напрочь забыл о безопасности. Очень нехитрым способом у злоумышленника появлялась возможность перезаписывать данные в таблице wp_options.
Слабые места CMS WordPress
Если с ядром CMS WordPress все в общих чертах очень даже неплохо, что подтверждает статистика, то к самым слабым местам движка я в первую очередь отнесу разработчиков.
Так уж исторически сложилось, что писать плагины и темы оформления для этого движка может любой желающий, равно как и добавлять результаты своих трудов в официальный репозиторий, продавать их через маркетплейсы или собственные сайты.
Да, добавляемые в репозиторий плагины и темы оформления проходят модерацию команды WordPress Plugins, а код должен соответствовать стандартам WPCS, но везде есть нюансы.
Главное: большую часть кода пишут новички и любители, что, разумеется, напрямую затрагивает вопрос безопасности. И тут же мы сталкиваемся со второй проблемой — хрупким эго разработчиков.
Зачастую, когда разработчик получает информацию о содержащейся в его продукте уязвимости, он воспринимает это на свой счет: якобы он сам глуп, его код ужасен, продукт небезопасен, не стоит своих денег и так далее. Это находит отображение либо в довольно агрессивных ответах, либо в банальном игнорировании попыток установить контакт. И это тоже очень известная проблема.
Другая ситуация — разработчик получил всю нужную ему информацию, справился с патчем, закрыл уязвимость и решил это отметить каким-то особенным и оригинальным способом вместо банальных слов благодарности:
Это лишь малая часть подобных попыток обесценивания со стороны разработчиков, но суть отображает вполне ясно. Причем, заметьте, все эти остроты появились после закрытия уязвимости, при тестировании патча.
Стоит ли пояснять, что подобное пренебрежение оттолкнет даже самых мотивированных и этичных исследователей? А реальная картина с патчами нередко выглядит следующим образом:
В итоге все же лучше оставаться в рамках профессиональной этики. Это win-win для обеих сторон при минимальных временных затратах и гарантия дальнейших коммуникаций, если таковые будут нужны. А они будут нужны, поверьте.
Еще разработчики нередко любят писать инструкции по обеспечению защиты для сайта под управлением CMS WordPress, и выглядит это приблизительно так:
Казалось бы, всего четыре простых шага, по выполнении которых автор гарантирует полную безопасность сайта своим подписчикам. Мой короткий с ним диалог «о насущном» позволил пролить свет на ситуацию, в результате чего он косвенно признал неправоту, а чуть позже удалил запись на своем канале. И все же: что тут не так?
Во-первых, nulled-плагины и темы оформления — давно известная и обсуждаемая тема. Многих устраивают сопутствующие риски ради экономии денег. Очевидно, что от вареза лучше отказываться, но воз и ныне там. Во-вторых, обновления, тем более автоматические, — далеко не всегда хорошо и безболезненно. Напомню о произошедшем не так давно казусе, когда автоматическое обновление положило на лопатки сайт CEO WordPress и Automattic:
Опытные разработчики, веб-мастеры и администраторы сайтов прекрасно знакомы с ситуацией вокруг обновлений, поэтому уже давно укоренилась практика отключать автоматическое обновление и для ядра, и для плагинов, и для тем оформления, отдавая предпочтение либо отсутствию обновлений вообще, либо ручным обновлениям. В общем, второй совет также весьма спорный. Про SSL-сертификат комментировать особо нечего, этот пункт тут появился по принципу «все пишут, и я напишу». Заключительный пункт, разумеется, повествует о необходимости установки плагина безопасности. На этом вопросе я остановлюсь подробнее, но чуть позже.
Следующее слабое место CMS WordPress — обилие XSS и CSRF в плагинах и темах. Особенно стоит выделить именно XSS-вектор атак, так как он и по сей день весьма болезненно отрабатывает против движка. Самым ярким примером, наверное, будет классическая полезная нагрузка XSS 2 Admin:
Ее итогом станет создание аккаунта с ролью администратора.
Идем далее. «Из коробки» имеем доступ к ./wp-admin/theme-editor.php и к ./wp-admin/plugin-editor.php — это редакторы кода тем оформления и плагинов прямо в админпанели. Комментировать тут особо нечего.
Дальше по списку у нас, собственно, сам инсталлятор WordPress вместе с таблицей wp_options. Суть в том, что если удалить или очистить таблицу, то будет автоматически перезапущен процесс установки движка. А это, в свою очередь, позволит злоумышленнику самому завершить процесс установки с аккаунтом администратора на руках. Аналогичного эффекта можно добиться путем изменения префикса таблиц БД в файле ./wp-config.php - $table_prefix.
Путаница с пользовательскими правами или полное непонимание данной темы — еще одна проблема экосистемы WordPress. Обычное дело, когда пользователь обладает гораздо большим набором прав, чем того требует функциональность отдельно взятого плагина или всего сайта целиком. Как итог — доступ рядового пользователя к ./wp-admin/customize.php (функционал кастомизации сайта), ./wp-admin/widgets.php (страница настройки виджетов сайта) или, что еще хуже, к ./wp-admin/options.php (все настройки сайта). Хоть первые две страницы и дают нежелательный доступ к настройкам и возможность вносить существенные правки в работу сайта, но вот с потенциалом третьей им не сравниться.
Если есть доступ к ./wp-admin/options.php без использования полноценного аккаунта администратора сайта, то я вас поздравляю — это джекпот.
Во всем многообразии доступных настроек самыми востребованными будут эти три: users_can_register=1, default_role=administrator и admin_email=hacker@domain.tld. Первой опцией разрешаем регистрацию на сайте, если она закрыта. Вторая опция установит для всех новых зарегистрированных аккаунтов права администратора сайта. Третью советую поменять, чтобы администратор сайта не получал на почту уведомления о происходящем на сайте. После этого уже можно завершать текущую сессию, регистрироваться штатным способом и получить в итоге полноценный аккаунт администратора сайта без каких-либо ограничений.
Одна из возможных реализаций такого сценария на примере плагина: Controlled Admin Access < 1.5.2 — Improper Access Control & Privilege Escalation.
Защита CMS WordPress: мифы, легенды и реалии
Эта система управления не лишена мифов и легенд. Далее я упомяну самые известные из них.
Миф № 1: хватит установленного плагина безопасности
Реальность: у ряда разработчиков, веб-мастеров и администраторов сайтов встречается убежденность, что любой установленный плагин безопасности спасет от всех атак даже самых мотивированных злоумышленников, а бонусом кофе утром в постель обеспечит. На деле же нередко бывает так, что этот самый плагин безопасности забывают активировать в админпанели после его установки, ну или забывают о его тонкой настройке, что сводит эффективность такого плагина почти до минимума.
Миф № 2: если не хватит одного, то точно хватит второго установленного плагина безопасности
Реальность: этот миф популярен среди бывалых, которые уже давно напуганы общей ситуацией вокруг уязвимостей, атак и заражений сайтов под управлением CMS WordPress, поэтому они перестраховываются, устанавливая два или три плагина безопасности. Как и в мифе № 1, этот винегрет из плагинов также не всегда активируется. А если активируется, то между такими плагинами начинается конфликт, при котором они распознают друг друга как вредоносные компоненты или банально выдают фатальные ошибки.
Миф № 3: если не использовать аккаунт admin, то проблем не будет
Реальность: один из популярных, но не работающих рецептов харденинга WordPress-инсталляции — отказ от пользователя с логином admin. Выцепить актуальный логин администратора сайта можно разными путями, так что этот рецепт былой силы не имеет.
Миф № 4: сложный пароль = гарантия безопасности
Реальность: само понятие «сложный» применительно к политике паролей у всех разное. Для кого-то сложным будет и пароль Moskva2023. Справедливости ради замечу, что с некоторых пор «из коробки» WordPress генерирует относительно сложные пароли самостоятельно, при этом оставляя за пользователем право назначить нужный ему пароль. По своему опыту скажу, что сгенерированными надежными паролями пользуются редко, предпочитая варианты в духе Moskva2023.
Миф № 5: SSL-сертификат гарантирует защиту от взлома
Реальность: этот миф напрямую связан с отсутствием понимания, зачем и для чего вообще сертификат нужен; более того, не всегда эти сертификаты даже корректно устанавливаются.
Миф № 6: если спрятать {Х}, то атакующий не сможет {Y}
Реальность: игра в прятки обычно излишне нагружает систему и иногда запутывает самого администратора сайта. К примеру, есть большие любители поменять страницу входа в админпанель сайта со стандартного /wp-login.php на что-то вроде /knsdfjnwoelasmasf-wemf.php. В итоге, как вы понимаете, у администратора сайта есть 100%-я гарантия самому себе перекрыть доступ в админпанель, а атакующий спокойно продолжит атаку. То же самое касается попыток анонимизировать движок, переименовав стандартные директории ./wp-admin, ./wp-content и ./wp-includes. Этот недуг лечится путем прямого обращения, к примеру, к файлу стилей админпанели или к jquery.js: //domain.tld/wp-includes/js/jquery/jquery.min.js.
Миф № 7: в случае взлома администратор сразу все заметит
Реальность: нет, нет и еще раз нет. Если администраторы что-то и замечают, то чаще всего это отработка от хостера, который рассылает письма с предупреждениями о заражении сайта, в более редких случаях — блокировка сайта или отдельного сервиса вроде рассылки писем. Да и то это при условии, что хостер вообще подобные услуги предоставляет. Триггернуть администратора может и WAF, если таковой имеется, но это не гарантия того, что администратор насторожится и начнет смотреть, кто копает под сайт. Мой личный рекорд с сохранением доступа к сайту через бэкдор — 2 года, притом что сайт регулярно обновлялся.
И еще немного бессмертной классики:
1. Автоматические обновления зачастую отключены, причем это касается как самой CMS, так и плагинов и даже тем оформления.
2. Запрещается выполнение файлов с расширением .php в директории ./wp-content/uploads/*.
3. В /robots.txt попадают интересные страницы сайта — к примеру, с той же новой «секретной» страницей логина.
4. База не вычищается от ненужных данных, в том числе от лишних пользовательских ролей.
5. Борьба с брутфорсом ведется посредством директив в .htaccess.
Предопределенные роли
«Из коробки» WordPress имеет ряд предопределенных ролей: подписчик (subscriber), участник (contributor), автор (author), редактор (editor) и администратор (administrator). В режиме мультисайта (это сеть виртуальных сайтов) есть еще одна роль — суперадминистратор. У каждой роли свой набор прав — разрешение на выполнение тех или иных действий в системе. При этом каждая старшая роль наследует права предыдущей роли. К примеру, подписчик может лишь изменять свой профиль и оставлять комментарии к материалам сайта, если опция комментирования не закрыта. Участник наследует все права подписчика и при этом уже имеет право добавлять записи, сохраняя их в черновиках, чего не может делать подписчик, и так далее.
Важно знать, что в WordPress всего две базовые, низко привилегированные роли — подписчик и участник, в то время как все последующие роли считаются уже привилегированными, поэтому там более реален вектор атаки с повышением прав в системе.
Наличие разных базовых ролей вместе с возможностью создавать свои собственные сказывается и на вопросах безопасности, начиная с репортов и заканчивая неправильным распределением пользовательских прав в плагинах. Это привело к тому, что в отчетах об уязвимостях указание authenticated в заголовке создавало путаницу и непонимание, какая именно минимальная пользовательская роль требуется для успешной эксплуатации уязвимости. Так, WPScan сперва начали обозначать уязвимости, выполнение которых возможно только с правами администратора сайта, как admin+, а позже эта практика была успешно применена ко всем уязвимостям в базе вообще. Проще говоря, было Authenticated Persistent XSS — стало Subscriber+ Persistent XSS. Символом + обозначается возможность эксплуатации уязвимости для старших пользовательских ролей. Коротко и ясно.
ПЕРЕЧИСЛЕНИЕ
Общие сведения
На старте первое, что мы все так или иначе делаем, — визуальный осмотр. Наибольший интерес, разумеется, вызывают два вопроса: свежесть и функционал. Первый дает общее представление о сайте, понимание, забыт он или время от времени обновляется, а второй позволяет представить потенциально слабые места. После этого уже можно начинать сбор всей возможной технической информации: версия установленного движка, список активных плагинов и темы оформления, их версии, наличие либо отсутствие плагина безопасности и/или WAF. Далее стоит выцепить всех пользователей сайта, по возможности понять их роли в системе, посмотреть, что нам даст WP API (в первую очередь маршруты), и завершить осмотр поиском уже раскрытых уязвимостей под установленные на сайте версии плагинов, темы оформления, а может, и под сам движок.
Разумеется, проще этап сбора информации автоматизировать, тем более что для этого уже давно придумано несколько полезных и весьма известных инструментов.
Автоматизация
Никакой экзотики: WPScan, Nuclei, CMSmap, cURL, Plecost и Burp Suite.
WPScan, полагаю, в представлении не нуждается — это самый полный по функциональности сканер WordPress. Из наиболее востребованного: определение версий ядра движка, плагинов и тем оформления, возможность перечисления пользователей, брутфорс и выявление бэкап-файлов. Пару лет назад проект был странно монетизирован, поэтому без указания API-ключа сканер более не предоставляет информацию по обнаруженным уязвимым компонентам со ссылками на детальные отчеты. Регистрация на wpscan.com без платной подписки позволяет получить заветный API-ключ, но лимит в сутки составляет 75 запросов (по состоянию на февраль 2023 года).
Nuclei — молодой, но многообещающий сканер уязвимостей. Помимо скорости работы, стоит отметить его полезность при сканировании большого количества хостов и небольшом количестве ложных срабатываний. Шаблон для сканирования и определения WordPress-инсталляций уже есть.
Из минусов: пока что готовые шаблоны для сканирования WordPress представлены довольно скромно.
CMSmap — еще один сканер, который поддерживает работу уже по четырем известным системам управления (WordPress, Joomla, Drupal и Moodle), но какой-то особенной функциональностью не обладает. По сути — те же возможности, имеющиеся у WPScan, только в базовой форме.
cURL может помочь в тех случаях, когда по каким-то причинам нет возможности использовать сканер. Минус этого метода в том, что обычно элемент <meta> с директивой name="generator" при оптимизации (реже — харденинг) вырезается, равно как и подчищаются ссылки CSS и JS, из которых вырезается часть ?ver=[...]. Как итог — бесполезность cURL для сбора базовых сведений об исследуемом сайте.
Plecost имеет все ту же базовую функциональность, что и у конкурентов, но из-за непонятной истории с обновлениями сканер безнадежно устарел. Разработчик как-то обмолвился, что будет большое обновление в 2022 году, но этого так и не произошло.
Burp Suite упомянут постольку-поскольку. Можно запустить сканер и краулер, так что какую-то информацию это даст в любом случае. Но желательно морально подготовиться к тому, что в отчетах будет много воды. Ну и брутить аккаунты тоже можно, why not?
Подготовка
После сбора информации о цели, но перед самой атакой я советую выполнить еще одно важное действие — воссоздание функциональной копии атакуемого сайта на тестовом стенде. Для этого хорошо подойдут как песочницы WordPress (InstaWP и аналоги), так и localhost, и даже самый дешевый шаред-хостинг. Такая функциональная копия позволит нам: а) попробовать разные варианты атаки, не работая непосредственно по цели и лишний раз тем самым себя не выдавая; б) имея доступ в админпанель сайта, посмотреть функционал сайта изнутри, что может дать важную для последующей атаки информацию. Вторая опция будет особенно полезна тем, кто не имеет навыка чтения исходного кода.
Кстати, об этом. Если читать исходный код по какой-либо причине нет возможности, то остается уповать только на уже раскрытые уязвимости в ядре (core), темах оформления (themes) и плагинах (plugins). Вполне логично было бы обратиться за этой информацией на профильные ресурсы, такие как WPScan, Patchstack, Wordfence и Plugin Vulnerabilities (PV). Самым полезным окажется WPScan, потому что это единственный ресурс, публикующий для каждой уязвимости рабочий эксплоит/PoC. PV рекомендую, потому что там публикуются зиродеи и неплохие разборы некоторых уязвимостей.
Также полезные ресурсы при поиске раскрытых уязвимостей:
Отдельно упомяну WordPress Trac — инструмент, позволяющий отслеживать изменения в ядре движка, его плагинах и темах оформления, находящихся в официальном репозитории. На самом деле его функциональность значительно шире, но интересует нас по большей части именно возможность сравнивать версии файлов до и после вносимых разработчиком изменений, особенно когда они вызваны попыткой закрыть очередную уязвимость.
Чтобы не тратить время зря, базу Exploit-DB на наличие эксплоита проверять я не советую. К модерации на этом ресурсе давно есть очень конкретные вопросы после публикации ложной информации относительно ряда уязвимостей, которую они так и не удалили. Пара примеров для понимания сути происходящего:
Еще один совет: изучайте исходный код страниц сайта на предмет CSRF-токенов (nonce, security и так далее), генерируемых плагинами. В ряде случаев это может существенно упростить атаку на сайт.
ЗАЩИТА
Плагины безопасности и их особенности
Термин «плагин безопасности» собирательный и обозначает вообще все плагины, прямо или косвенно относящиеся к тематике безопасности, среди которых будут WAF, сканеры малвари, харденинг, файрволы, защита от брутфорса и прочее подобное. На фоне всех этих решений сильнее всего выделяется Wordfence Security, который по принципу all-in-one закрывает собой почти все самые актуальные вопросы безопасности: WAF, файрвол, сканер малвари, оповещение о наличии уязвимого плагина и так далее. Решение хоть и мощное, но не без недостатков: а) сканер малвари после запуска нередко съедает много ресурсов сервера, что приводит к фатальной ошибке с непредсказуемыми последствиями; б) часть очень полезного функционала доступна только по платной подписке, что подходит далеко не всем; в) их WAF неплох, но все же его можно обойти; г) сканер малвари можно обойти без особых усилий, об этом я в далеком 2019 году написал отдельную статью.
Прямой конкурент Wordfence Security по популярности — All-In-One Security (AIOS) — тоже обладает богатой функциональностью, но большая ее часть сосредоточена на харденинге системы, а заявленный WAF почему-то пропускает даже самые примитивные XSS. Причем часть важной функциональности «из коробки» не активирована, что тоже весьма странно.
Остальные плагины безопасности менее популярны и в общих чертах пытаются предложить ту же функциональность, местами реализуя ее значительно слабее. Тут исключением можно назвать лишь плагин NinjaFirewall, который показывает себя немного лучше, если сравнивать его с конкурентами. Кстати, об этом.
Plugin Vulnerabilities
На изображении выше виден результат тестирования известных плагинов безопасности по состоянию на 1 марта 2023 года от компании Plugin Vulnerabilities (PV). Суть проста: показать, что вендоры, обещающие своим пользователям и клиентам защиту их сайтов, со своими задачами справляются плохо. Сотрудники компании PV разработали решение, позволяющее тестировать их собственный плагин безопасности (Plugin Vulnerabilities Firewall), но в то же время ничего не мешает им использовать это же ПО для тестирования плагинов конкурентов, что они и делают, регулярно публикуя подобные отчеты после.
Как итог
Разочарование клиентов от плохого сервиса нередко выражается в виде негативных отзывов на wordpress.org:
А иногда бывает и вот так:
Резюмируя вышесказанное: идеального решения не существует, и все сводится, по сути, лишь к максимально возможному затруднению взлома сайта и/или к оперативному исправлению последствий в случае успешной атаки. Это, в свою очередь, не дает гарантий защиты даже от уже известных и раскрытых уязвимостей, не говоря про зиродеи. Да и никто не отменял человеческий фактор как первоисточник всех последующих проблем.
АТАКА
Нет доступа внутрь CMS WordPress
Наиболее вероятная ситуация в большинстве случаев. Вариантов тут мало, прямо скажем: поиск эксплоита под обнаруженный уязвимый плагин или самостоятельное изучение исходного кода установленных плагинов с последующим выявлением в нем уязвимостей. Второй вариант, разумеется, более требователен к уровню подготовки атакующего, но и здесь есть свои нюансы.
Во-первых, стоит обратить внимание на список изменений (changelog) исследуемого плагина. Если он подробно записан, то посмотрите, сколько раз там встречаются слова security, important, critical, vulnerability и прочие. Чем чаще встречается что-то подобное, тем больше шанс найти очередную уязвимость.
Во-вторых, упоминание патча еще не означает фактическое закрытие уязвимости, поэтому на тестовом стенде вполне можно опробовать эксплоит от предыдущей версии: может случиться так, что уязвимость не закрыта вовсе или немного изменились кондиции для ее успешной эксплуатации.
В-третьих, есть популярная практика: либо не вести подробный список изменений, либо вообще замалчивать там вопросы безопасности. В таком случае стоит проверить наличие раскрытых уязвимостей на профильных площадках — это прояснит картину.
В-четвертых, проверяйте кастомные формы регистрации на сайте, если таковые имеются. Нередко разработчики забывают о том, что пользователю нельзя давать контроль над рядом параметров, особенно если параметр устанавливает роль пользователя в системе, как это случилось с плагином uListing:
Про внимание к WP API я уже писал, и уязвимость в плагине Image Hover Effects Ultimate — хорошая демонстрация того, как это иногда бывает.
Минимальный доступ внутрь CMS WordPress
При наличии доступа в админпанель сайта я первым делом рекомендую проверять страницы ./wp-admin/customize.php, ./wp-admin/widgets.php, ./wp-admin/theme-editor.php, ./wp-admin/plugin-editor.php и ./wp-admin/options.php. Даже если они не видны в меню, что находится слева, это не показатель отсутствия доступа к некоторым из них или ко всем сразу. Такая ситуация обычно объясняется некорректно выданными правами самим администратором сайта или попыткой через сниппет убрать пункты меню для определенных пользовательских ролей, но вот от прямого доступа такие решения не защищают никак.
Вторым вполне логичным шагом было бы проверить доступную функциональность установленных на сайте плагинов. Кстати, тестовый стенд может подкинуть пищу для размышлений. В этом случае главное — помнить, что иногда разработчиками выдаются избыточные права на выполнение тех или иных действий в системе, равно как и часто встречается отсутствие проверки авторизации.
Для наглядности предлагаю взглянуть на репорт StopBadBots < 7.24 - Subscriber+ Arbitrary Plugin Installation:
Должен ли пользователь с правами уровня «подписчик» иметь возможность устанавливать в системе плагины? Очевидно, что нет.
Привилегированный доступ внутрь CMS WordPress
Тот самый случай, когда все недоработки системы начинают играть против нее: возможность добавлять HTML-код в пункты меню и в заголовки записей и страниц, обходить защиту от загрузки файлов с небезопасными расширениями (в первую очередь речь о .php, разумеется), загружать свою тему оформления или плагин с вредоносным кодом внутри, пользоваться встроенным редактором кода и многое другое. Все перечисленные возможности — целиком и полностью решения разработчиков CMS WordPress, но стоит упомянуть и более экзотические нюансы. Так, к примеру, есть возможность протолкнуть хранимую XSS в названии пользовательской роли, создать невидимого пользователя с правами администратора (этот пользователь не будет виден на странице ./wp-admin/users.php), внедрить сниппет с кодом автологина (чтобы логиниться на сайте без ввода логина и пароля) и прочее подобное. И это я упомянул только возможности самого движка, помимо которого есть еще плагины и темы оформления. В общем, есть где развернуться.
Когда я говорю про плагины и темы оформления, в первую очередь имею в виду те самые уязвимости admin+. По сути, у них всего одно преимущество — обход плагинов безопасности, которые попросту не дадут реакции на такие действия внутри админпанели, считая их легитимными. Бонус: в подавляющем большинстве случаев администратор сайта ничего не заметит.
Выбрать тоже есть из чего, начиная с обычных XSS, продолжая SQLi и заканчивая, к примеру, уже RCE.
Опять же, для наглядности посмотрите сами.
Выход из контекста CMS WordPress
Привилегированный доступ по ошибке разработчика или удачная атака с получением прав в CMS WordPress — это замечательно, но ради избавления себя от лишних проблем контекст системы управления лучше покидать при первой же возможности. Главный аргумент здесь — хрупкость системы, то есть буквально при внедрении полезной нагрузки или своего сниппета (для закрепления в системе) есть все шансы положить сайт на лопатки. Как минимум это сигнал для администратора сайта, как максимум — завершение атаки для вас. В этом плане стоит впечатлиться принципом работы той же малвари под WordPress — простые, минималистичные вредоносные вставки, отлично выполняющие свои задачи. Так же и тут: не надо пытаться протолкнуть WSO/r57/c99/Alfa/b374k при первой возможности, лучше отдать предпочтение чему-то минималистичному вроде однострочников, которые, помимо всего прочего, можно легко спрятать как от взора бдительного администратора, так и от сканеров малвари.
АУТРО
Выводы
Вспоминая вопросы после основной части доклада, я хочу особенно отметить тот, что был задан про сайт журнала «Хакер». Уже несколько лет этот сайт выступает тематическим новостным порталом, и создан он как раз на CMS WordPress, так что вполне резонно прозвучал вопрос о надежности такой системы управления.
Так вот, CMS WordPress — просто инструмент со своими плюсами и минусами, а надежность целиком и полностью зависит от знаний и навыков того, кто этим инструментом пользуется. Та же логика работает и для атакующей стороны: более тонкое понимание нюансов дает большие шансы на успешный пробив этой системы управления. Ничего сверхъестественного. Как я написал выше, в ядре движка критических уязвимостей за последние годы выявлялось мало, чего нельзя сказать о плагинах и темах оформления, и на данном этапе это большая и известная проблема.
Также напомню атакующим, исследователям и багхантерам, что краткость — сестра таланта. Учитывая хрупкость CMS WordPress, какие-то избыточно тяжелые скрипты, сниппеты, веб-шеллы или полезные нагрузки могут просто положить весь сайт целиком. Чем проще, тем лучше. Минимизируйте риски отказа системы, привлечения внимания владельца сайта, каких-то непредвиденных результатов после выполнения кода и прочее подобное. Дополнительно можно подстраховаться тем самым тестовым стендом, который я упомянул выше, — это ваш виртуальный полигон.
Плагины безопасности. Опять же, ничего нового: нужно понимать, от кого и от чего вы хотите защищать свой сайт, какими средствами вы для этого располагаете. Какие-то плагины безопасности решают задачи по харденингу, другие позволяют сканировать файлы на предмет их изменения, третьи до кучи еще поищут в файлах малварь, четвертые дадут подобие WAF. Бездумно устанавливать все подряд, где в названии есть слово security, — это моветон, и такие действия к желаемому результату не приведут.
Пост-эксплуатация. Если нет нужды сидеть в админпанели сайта, то контекст CMS WordPress лучше покидать при первой же возможности. Главную причину я уже озвучил выше — это общая хрупкость системы. Еще одна причина — риск обновлений самого сайта, когда могут быть замечены и/или удалены все закладки и бэкдоры. Тут, кстати, не будет лишним еще раз отметить полезность Admin+ XSS, которые незаметны, но отлично срабатывают, в то время как именитые плагины безопасности не сканируют БД на предмет подозрительных и потенциально опасных данных. Да, вот так просто.
Спасибо за внимание!