Блог

Аудит WordPress? Начните со своих плагинов

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

Summary

Большинство аудитов безопасности WordPress выстроены задом наперед: они делают упор на обновления ядра и отчеты сканеров, в то время как уязвимости, которые действительно кусаются, живут в плагинах. В техническом отчете SANS говорится, что более 96% уязвимостей экосистемы происходят из сторонних плагинов, и примерно 43% из них не требуют аутентификации. В этой статье рассматривается аудит с приоритетом плагинов для небольшой внутренней маркетинговой команды на примере сайта, который был взломан, потому что все сканировали не тот уровень. Вы научитесь инвентаризировать и классифицировать каждый плагин, тестировать неаутентифицированные поверхности атаки, вручную проверять пользователей и журналы и переводить выводы на язык риска, понятный нетехническому начальнику. Результат — ежеквартальный ритуал триажа вместо упражнения для галочки.

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

Цифры это подтверждают. В техническом отчете SANS о сканировании плагинов WordPress говорится, что более 96% уязвимостей в экосистеме WordPress происходят из сторонних плагинов, темы составляют 4%, а ядро — менее 1%. Примерно 43% этих дефектов можно эксплуатировать без какой-либо аутентификации. Поэтому, когда ваш аудит тратит большую часть энергии на ядро, вы рассматриваете деревья, пока рядом в каталоге плагинов начинается лесной пожар.

Это не призыв паниковать по поводу ядра. Уязвимости ядра, такие как ошибки удаленного выполнения кода wp2shell, для которых недавно появились публичные эксплойты, должны быть исправлены в день их объявления. Но они достаточно редки, чтобы не заслуживать основного времени вашего аудита. Основное время принадлежит плагинам, и именно здесь начинается настоящий рабочий процесс.

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

Вы работаете в небольшой маркетинговой команде с сайтом на WordPress, работающим с 2017 года. На нем есть плагин регистрации на мероприятия, созданный фрилансером в 2019 году, плагин контактной формы с полем загрузки файлов и плагин слайдера, который был продан и больше не имеет публичной страницы обновлений. Это не необычный набор. Именно здесь начинается ваш аудит.


Инвентаризация плагинов — ваша политика безопасности

Проведите инвентаризацию каждого плагина и темы. Запишите версию, дату последнего обновления, жив ли вендор и пользуется ли кто-то этим плагином. Затем классифицируйте каждый по категориям: поддерживается и используется, поддерживается и не используется, заброшен, но используется, заброшен и не используется. Неиспользуемые удалите немедленно. Игнорируйте оправдание «это всего лишь $50 в месяц» — неиспользуемый плагин является обузой, а не функцией. Для заброшенных, но используемых решите: заменить или принять риск и записать его в реестр рисков, который видел ваш начальник.

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

Вектор атакиДоля известных уязвимостей WordPressПриоритет аудита
Сторонние плагиныБолее 96%Наивысший — инвентаризация, сканирование, тестирование, замена
ТемыОколо 4%Средний — только если кастомные или устаревшие
Ядро WordPressМенее 1%Низкий — обновляйте и двигайтесь дальше

Когда SecurityWeek насчитал более 8000 новых уязвимостей WordPress в 2024 году, подавляющее большинство было именно такого типа: проблемы плагинов, а не патчи ядра. Сканер сообщит вам о тех, которые были раскрыты и получили CVE. Он не сообщит вам о кастомном коде фрилансера без CVE, потому что никто никогда внимательно его не изучал. Этот ручной просмотр — ваша задача. Для более детального разбора проверок плагинов обратитесь к руководству по аудиту ваших плагинов WordPress на уязвимости.


Тестируйте как посторонний: 43%, которым не нужен пароль

Ваш сканер уже сказал вам, что всё в порядке. Теперь сделайте то, что он не может: исследуйте сайт извне, без входа в систему. Начните с каждого поля загрузки файлов, каждой формы, обрабатывающей POST, каждой конечной точки admin-ajax. Проверяет ли загрузка фактическое содержимое файла или только расширение? Куда попадают загруженные файлы и может ли веб-сервер выполнять PHP в этом каталоге? 43% дефектов плагинов, не требующих аутентификации, обычно находятся именно здесь: неаутентифицированный хранимый XSS, произвольная загрузка файлов и внедрение объектов PHP.

Плагин контактной формы позволяет посетителям прикреплять резюме. Он переименовывает файл, используя исходное имя файла посетителя, поэтому вы загружаете «resume.php», и он сохраняется в папку /uploads/contact/, которая доступна для записи по задумке. Если сервер также позволяет выполнять PHP в этом каталоге, злоумышленник только что получил веб-шелл. Fastly задокументировала активную эксплуатацию неаутентифицированного хранимого XSS в плагинах WordPress — это не нишевый риск из слайдов. Ваш тест прост: создайте файл с известным содержимым, загрузите его и посмотрите, вернется ли он с исходным именем и типом. Затем попробуйте загрузить файл .php. Если он вернется как .php, вы только что нашли эксплуатируемую дыру.

Именно здесь аргумент «но у нашего плагина безопасности есть WAF» разваливается. WAF может заблокировать известную полезную нагрузку, но правила нормализации путей, на которые он опирается, часто расходятся с тем, что на самом деле делает сервер. Руководство по тестированию веб-безопасности OWASP — лучший справочник, чем любой дашборд: в нем описывается, как методично тестировать ошибки загрузки файлов и хранимый XSS. И если вы обнаружите, что плагин заброшен, пора применить протокол очистки: скрытая опасность заброшенных плагинов WordPress объясняет, почему оставить мертвое расширение на месте хуже, чем удалить его и скорректировать рабочий процесс.


Чего не видит сканер: пользователи, журналы и старый код

Динамические тесты выявляют то, что открыто прямо сейчас. Ручная проверка выявляет то, что уже внутри. Начните с учетных записей пользователей: откройте список администраторов и посмотрите, есть ли аккаунты, которые вы не создавали. Админ с именем «support», адресом бесплатной почты и без человека за ним — это бэкдор, а не коллега. Проверьте временные метки файлов в wp-content/uploads на предмет недавно измененных, не являющихся вашим контентом. Проверьте журнал доступа сервера на запросы, похожие на команду curl бота, а не на браузер человека.

У плагина мероприятий есть загрузка «фото спикера», которая сохраняет файлы в uploads/event-headshots/. Во время теста вы находите файл, который не принадлежит вам, — небольшой PHP-файл со случайным именем. Это ваш веб-шелл. Он попал туда через ту же ошибку загрузки, которую вы тестировали две недели назад, и теперь сканер все равно его не «увидит», потому что это не уязвимость плагина; это доказательство уязвимости. Ручная проверка находит его, удаляет и проверяет журнал на IP-адрес, который его разместил. Invicti отметила, что внедрение объектов PHP в плагинах растет, и оно почти невидимо для сканирования черным ящиком, потому что вредоносный объект материализуется только во время выполнения. Единственный способ обнаружить его — читать код на предмет опасных паттернов, таких как вызов unserialize() для пользовательского ввода. Чтение нескольких сотен строк кастомного плагина дешевле, чем оплата ретейнера за реагирование на инциденты.

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


Говорим начальнику правду без паники

Вашего начальника не волнуют оценки CVSS или внедрение объектов PHP. Его волнует, что сайт ляжет, магазин не будет принимать заказы и бюджет на ИТ. Перевод прост: «У этого плагина есть известная неаутентифицированная уязвимость удаленного выполнения кода. Посторонний может удалить контент нашего сайта или установить бэкдор. Нам нужно заменить его в этом квартале». Затем покажите список приоритетов: замените плагин мероприятий, отключите загрузку файлов в контактной форме, пока она не будет правильно проверять типы файлов, смените все учетные данные администратора и запланируйте следующий квартальный обзор.

У вас также есть языковое преимущество: CISA ведет каталог известных эксплуатируемых уязвимостей, в котором точно указано, какие опубликованные дефекты активно используются в реальных атаках. Если какой-либо из ваших плагинов там есть, аргумент перестает быть теоретическим — известный эксплойт существует, и вы на счетчике. Если их там нет, все равно используйте его как стандарт того, что означает «срочно». Отслеживание CISA упрощает убеждение нетехнического начальника в том, что это не фишинговое письмо; это публичная база данных того, что злоумышленники делают прямо сейчас. Когда квартал закончится, у вас будет рабочий процесс устранения неполадок, а не разовая проверка для галочки. Рабочий процесс превращения уязвимостей в цикл исправлений поддерживает эту привычку.


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

Sources (5)