Забытый плагин WordPress: как он завёл сайт в бан Google за 9 дней

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

🕵️ сначала письма перестали доходить — а не «нас взломали»

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

Первая версия — сломался почтовый плагин или закончился лимит писем на тарифе. Технический специалист компании проверяет настройки SMTP, меняет пароль от почтового ящика, отправляет тестовое письмо через форму заявки — оно доходит. Значит, дело не в форме и не в почтовом сервисе, а в чём-то, что рассылает письма отдельно от неё.

Хостинг подтверждает: с сервера действительно уходят тысячи писем в сутки, но не через штатную почту сайта, а через скрипт, о котором никто в компании не знает. Три дня уходит на переписку с провайдером и попытки вручную почистить очередь отправки. Симптом не подсказывает причину — каталог работает, оплата проходит, сайт открывается как обычно. Но пока команда ищёт проблему в почте, поисковые системы уже индексируют заражённые страницы, а Google готовит предупреждение о вредоносном сайте.

что аудит нашёл за один день — плагин трёхлетней давности без обновлений

Аудит сайта начинается не с антивирусного сканера, а со списка установленных плагинов и дат их последнего обновления. В этом случае в списке висел слайдер для баннеров на главной странице — популярный в 2019–2020 годах инструмент, автор которого перестал выпускать обновления после версии 2.4. Плагин работал, баннеры крутились, менять его никто не планировал: зачем трогать то, что не ломается.

Именно в этой версии была найдена, а потом заново открыта уязвимость: модуль загрузки изображений принимал файлы без проверки настоящего расширения. Через эту дыру на сервер положили веб-шелл — скрипт, который выполняет команды через обычный HTTP-запрос и внешне ничем не выделяется среди файлов темы, если не сверять список файлов построчно с оригинальной поставкой.

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

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

заодно нашли: пиратская тема и плагин с правами куда шире необходимых

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

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

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

⚠️ цена простоя — во что обошлись 9 дней в чёрном списке Google

Через 9 дней после первого письма-спама Google Safe Browsing включил сайт в список потенциально опасных. Посетитель, который переходил по ссылке из выдачи, видел не карточку товара, а красный экран с предупреждением — и закрывал вкладку, не дожидаясь загрузки страницы. Органический трафик не «просел» постепенно, он обнулился за один день: переход из поиска обрывался предупреждением браузера раньше, чем страница успевала открыться.

Ставка здесь не только в трафике. Через тот же веб-шелл злоумышленник получил доступ к базе заявок с сайта — именам, телефонам и почтам клиентов, которые оставляли контакты через форму обратной связи. Это персональные данные, и утечка такого рода подпадает под требования 152-ФЗ: компания обязана уведомить субъектов персональных данных и Роскомнадзор о произошедшем, а не тихо переустановить плагин и забыть про инцидент.

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

Отдельная статья расходов — время. Ответ на запрос Роскомнадзора, уведомление клиентов о возможной утечке персональных данных и работа с репутацией — это часы юриста и руководителя, а не разработчика, и они не входят в стоимость технического устранения инцидента.

📋 чем самостоятельная проверка отличается от аудита безопасности

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

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

как закрыли инцидент и сколько это стоило

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

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

Такую работу считаем по тарифу сопровождения и техподдержки — 3800 рублей в час, без абонентской платы за время, когда сайт не трогают. Сам аудит, который находит подобные плагины до взлома, а не после него, входит в аудит сайта по девяти направлениям — там проверка плагинов и прав доступа идёт отдельным блоком наравне со скоростью загрузки и SEO. Стоимость по конкретному сайту и объёму работ — в тарифах, там же видно, что входит в разовую проверку, а что — в постоянное сопровождение.

три признака, что плагин пора менять, до того как это сделает аудит

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

• ✓дата последнего обновления в карточке плагина на wordpress.org — если она старше полутора-двух лет, а версия WordPress на сайте новее, плагин с ней просто никогда не тестировался;
• ✓ответы в разделе поддержки на сайте разработчика — десятки открытых вопросов без единого ответа за полгода означают, что автор либо забросил проект, либо продал его без объявления, а новый владелец добавляет свой код без предупреждения;
• ✓права, которые плагин запрашивает при установке — слайдеру для баннеров не нужен доступ к файловой системе за пределами папки uploads, а форме обратной связи незачем создавать пользователей WordPress.

Любое из трёх — повод для внепланового аудита, а не для того, чтобы отложить проверку до следующего квартала.

❓ Частые вопросы

Как понять, что на сайте на WordPress уже стоит взломанный плагин, а не просто устаревший?

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

Обязательно ли уведомлять Роскомнадзор, если через сайт утекли только имя и телефон из формы заявки?

Да — имя и телефон уже относятся к персональным данным по 152-ФЗ, объём утечки на обязанность уведомить не влияет. Если через взломанный сайт злоумышленник получил доступ к базе заявок, компания обязана уведомить субъектов персональных данных и Роскомнадзор, а не только устранить техническую причину взлома.

Автообновление плагинов в WordPress защищает от такой уязвимости?

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

Сколько стоит устранить находки после аудита безопасности WordPress-сайта?

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

Как часто нужен аудит безопасности сайта на WordPress, если явных проблем нет?

Раз в год — минимум, и обязательно после смены разработчика, крупного обновления темы или подозрительного поведения сайта: писем, которые не доходят, странных редиректов, жалоб клиентов на баннеры. Ждать явных симптомов невыгодно — к моменту чёрного списка Google трафик уже потерян.