Взлом WordPress через плагин: разбор реального случая

В ноябре 2018 года через уязвимость плагина WP GDPR Compliance атакующие получили возможность менять настройки WordPress и создавать учётные записи администратора. Некоторые сайты после этого перенаправляли посетителей на посторонние ресурсы. Это не история о сложном эксплойте в ядре: проблема оказалась на стыке плагина, проверки прав и привычки ставить обновления «потом».

Что произошло с WP GDPR Compliance

WP GDPR Compliance помогал владельцам сайтов выполнять требования о согласии на обработку данных. Уязвимость обнаружили в функциональности плагина, доступной через AJAX-запросы. По сообщениям исследователей безопасности, атаки начались до того, как многие администраторы успели обновиться. Уязвимыми считались версии плагина до 1.4.3; исправление вышло в версии 1.4.3.

Важна не только сама ошибка. Злоумышленники использовали возможность изменять параметры сайта, а затем — в ряде случаев — добавлять нового пользователя с правами администратора. Получив такой доступ, атакующий уже мог действовать через обычную панель WordPress: менять содержимое, устанавливать плагины или вставлять код, который перенаправляет посетителей.

Успешная атака не означала, что каждый сайт с установленным плагином обязательно был взломан. Но если уязвимая версия оставалась доступной из интернета, сайт попадал в зону риска. После появления исправления массовые сканеры могли искать сайты, которые всё ещё не обновились.

Как выглядела цепочка атаки

1. На сайте работала уязвимая версия плагина. Сам факт установки создавал потенциальную точку входа, даже если владелец давно не открывал настройки плагина.
2. Запрос доходил до обработчика плагина. Ошибка в проверках позволяла выполнить действие, которое должно было быть защищено от постороннего пользователя. Для атаки не требовался пароль администратора.
3. Менялись настройки сайта. В частности, атакующие могли включить параметры, связанные с регистрацией пользователей, или изменить роль, которую получал новый пользователь.
4. Создавалась учётная запись с повышенными правами. Если этот этап удавался, атакующий получал доступ к панели управления WordPress.
5. Использовался административный доступ. Среди наблюдавшихся последствий были внедрение перенаправлений и изменение поведения сайта для посетителей.

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

Уязвимость становится инцидентом не в момент публикации описания ошибки, а когда на сайте остаётся доступный путь от запроса без авторизации до действий администратора.

Что искать после обновления

Исправление закрывает известную уязвимость, но само по себе не удаляет учётные записи и изменения, которые атакующий мог оставить раньше. Если плагин стоял на сайте в уязвимой версии, проверьте не только номер версии сейчас, но и следы возможного доступа.

• Сверьте список пользователей с теми, кому вы выдавали доступ. Отдельно проверьте администраторов и дату создания подозрительных учётных записей.
• Посмотрите настройки регистрации и роль, которую получает новый пользователь. Значения должны соответствовать тому, как устроен ваш сайт.
• Проверьте главную страницу и ключевые страницы сайта из приватного окна браузера: нет ли неожиданных перенаправлений, всплывающих окон или подменённого содержимого.
• Сопоставьте доступные журналы веб-сервера и WordPress с периодом до обновления. Ищите подозрительные запросы к обработчикам плагина, входы в панель и создание пользователей. Точный формат журналов зависит от хостинга и настроек.
• Обновите WordPress, тему и все плагины из доверенных источников. Удалите неиспользуемые расширения, а не просто оставляйте их отключёнными.

Если обнаружили неизвестного администратора, не ограничивайтесь удалением его учётной записи. Смените пароли пользователей с административным доступом, проверьте содержимое сайта и файлы на хостинге, а при подозрении на компрометацию обратитесь к провайдеру или специалисту по реагированию. Иначе оставленный механизм доступа может создать учётную запись снова.

Почему обновления не всегда решают проблему

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

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

AJAX¹ — способ отправлять запросы из браузера без полной перезагрузки страницы. В WordPress плагины используют такие запросы для фоновых действий; сервер всё равно обязан проверять, кто отправил запрос и имеет ли этот пользователь право на операцию.

Что измерять и где подход ломается

Публичных данных, которые позволили бы честно назвать долю заражённых сайтов или среднее время атаки, недостаточно. Для собственного проекта полезнее измерять то, что можно подтвердить: сколько часов проходит от публикации критического обновления до его установки, сколько сайтов осталось на старых версиях и сколько времени занимает проверка подозрительного события.

Проверка журналов тоже не всесильна. Хостинг может хранить их недолго, а атака могла произойти до включения нужного логирования. Чистые журналы не доказывают, что сайт никогда не был скомпрометирован. Если есть признаки взлома, рассматривайте их вместе: неизвестные пользователи, неожиданные изменения файлов, перенаправления и события входа.

Инцидент с WP GDPR Compliance особенно опасен для сайтов, где один аккаунт администратора одновременно управляет контентом, пользователями и установкой кода. Разделение ролей, минимальное число администраторов, резервные копии и контроль изменений уменьшают последствия, но не заменяют обновления.

Что делать дальше

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

Если WP GDPR Compliance был установлен на вашем сайте в период до исправления, проверьте историю пользователей и настройки, а не только текущую версию плагина. При обнаружении признаков доступа действуйте как при инциденте: ограничьте доступ, сохраните копию журналов и привлеките специалиста. Инвалидация сессий и расследование файловой системы — отдельные задачи; здесь важна именно проверка того, не сохранился ли административный доступ.