Что делать, если WordPress заражен SEO-спамом

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

Ладно, возможно, я слишком драматизирую, но потерпите меня, пока я готовлю сцену для этой загадочной истории. Готовый? Пожалуйста, присоединяйтесь ко мне в этом путешествии в царство призраков, спама и поисковых систем.

Вредоносное поведение

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

Владелец веб-сайта был немного расстроен, так как такое поведение часто является результатом заражения, но Jetpack ничего не обнаружил и не предупредил его. Кроме того, этих страниц даже не существовало на веб-сайте, когда они проверяли, но они все равно индексировались Google. Сумеречная зона усиливается .

Когда мы проверили подозрительные файлы, которые Jetpack Scan мог пропустить (ни один инструмент безопасности не обнаруживает 100% угроз), все стало еще более странным. Ядро WordPress и плагины не пострадали: в базе данных не было внедренных файлов или скриптов. В паре устаревших плагинов не было исправлений безопасности, WordPress отставал на одну версию (5.6), а в последнем обновлении не было серьезных исправлений безопасности. Вообще ничего подозрительного не было. Никаких обычных подозреваемых, никаких доказательств нападения; во всяком случае еще нет.

Следующим логическим шагом будет проверка журналов доступа. Возможно, это могло бы пролить свет на эту тайну. Обнаружим ли мы, что столкнулись с атакой нулевого дня, или что мы, наконец, нашли доказательство теории мультивселенной, а этот веб-сайт заражен только во Вселенной №1337? К журналам!

Как и следовало ожидать: ничего странного, кроме кучи запросов к тем спам-страницам, что вы можете видеть на скриншотах. И все они отвечали «200 ОК». Итак, страница существовала где-то во временном и пространственном континууме, или… подождите секунду… вы видите ее сейчас?

Все эти страницы указывали на одно и то же место: `/?s=`, что означало, что поисковые системы (проблема была замечена Google, но запросы поступают из Bing) индексировали страницы результатов поиска. И почему так? Насколько нам известно, краулер не выполняет поиск на странице, верно?

Парадокс индексации

Основы работы поисковой системы довольно просты, если вы занимаетесь веб-сайтами. Существует робот (или автоматизированный скрипт), который сканирует веб-страницы, индексирует их содержимое, выполняет некоторые магические действия и хранит запрашиваемые ресурсы где-то в облаке.

Имея это в виду, мы еще немного покопались в журналах, чтобы увидеть, есть ли у какого-либо из этих запросов какая-либо другая подсказка, например реферер, но безрезультатно. Все зарегистрированные запросы исходили от поисковых систем. К счастью, в одном из журналов Google Search Console была одна из ссылающихся страниц.

Теперь я думаю, что пришло время сменить нашу шляпу из Сумеречной зоны на шляпу CSI и выкопать некоторые кости веб-сайта, чтобы поместить их под микроскоп.

Опытному глазу легко увидеть, что URL-адрес ссылающейся страницы принадлежит скомпрометированному веб-сайту; к счастью, у нас хорошо натренированные глаза! Каталог `index.php` не имеет смысла и, вероятно, был добавлен, чтобы запутать владельца веб-сайта. Затем следует еще один случайный каталог и файл PHP со случайным именем, который, вероятно, является загрузчиком, получающим конечную полезную нагрузку: `cargese4/cca442201.htm`, который также является случайным. Все это характеристики заражения вредоносной программой фермы ссылок.

Быстрый поиск в Google, чтобы увидеть, что было проиндексировано для ссылающегося сайта, подтвердил, что он действительно был заражен и какое-то время распространял SEO-спам. Сайт для пищевой компании в Индии, но предлагает скидки на внедорожники в Японии — да, это спам.

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

Чтобы найти больше жертв этой спам-атаки, мы, исключительно в образовательных целях, использовали наши знания Google-фу для создания поискового запроса, который возвращал бы сайты, оканчивающиеся на .edu, которые имели `/?s=` в URL-адресе, и слово «купить» в названии. И мы получили 22 результата. Этого достаточно для нашей охоты.

Это свидетельствует о том, что объект, о котором сообщалось, был не единственным затронутым; кажется, это более распространенная проблема. Мы задумались о том, что могло заставить Google проиндексировать эти страницы. Как Googlebot связался с ними? Следующий шаг: проверка обратных ссылок.

Есть несколько онлайн-инструментов, которые предоставляют отчеты об обратных ссылках на веб-сайты; в этом исследовании мы использовали Ahrefs, но другие инструменты могут дать такие же результаты. Некоторые из вредоносных поисковых страниц перечислены в результатах, подтверждая, что мы на правильном пути.

Выбрав один из этих веб-сайтов, чтобы проверить, что происходит, мы увидели почти 5000 спам-комментариев, как вы можете видеть на следующем снимке экрана (они должны проверить Jetpack Anti-spam). Каждый комментарий ссылался на страницу поиска по сайту со спамом в запросе.

Поймать белого кролика

Как я упоминал ранее, роботы поисковых систем не выполняют запросы на страницах веб-сайтов. Но, если он найдет ссылку на него, за ним последует. И если страница не сообщает автоматизированному сценарию, что конкретная страница не индексируется, он добавит ее.

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

Теперь, когда мы понимаем проблему, как нам сообщить роботам поисковых систем, чтобы они не переходили по ссылкам на поисковые страницы (или просто отказывались их индексировать)? Лучшим способом было бы внести изменения в ядро ​​WordPress, что помогло бы защитить все сообщество (если вы хотите сообщить об ошибке или внести свой вклад в код, присоединяйтесь к нам).

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

Процитирую автора, который лучше меня описал проблему (спасибо abagtcs за отчет):

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

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

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

Это неудивительно, учитывая, что более 41% крупнейших сайтов в сети — это сайты на WordPress.

Закрытие дела

Из этого инцидента можно извлечь несколько полезных уроков:

1. URL-адрес, представленный на самых растущих страницах, плохо очищен, поэтому URL-адреса спама, которые вы видите, разделенные смайликами, на самом деле доступны для прямого клика (привет, друзья Google, это на вас); неосведомленные пользователи могут нажать на них и получить доступ к нежелательному контенту.
2. Некоторые настройки необходимы Google, чтобы избежать индексации явно спамных страниц. Судя по отчету инструмента, некоторые чистые страницы были просканированы и не проиндексированы, а спам был добавлен.
3. Злоумышленники будут использовать даже самую маленькую брешь в вашей системе, и мы должны всегда быть бдительными.
4. Всегда слушайте людей и понимайте их проблемы. Если бы мы проверяли журналы только с помощью наших собственных инструментов, мы бы не знали об этой проблеме и не смогли бы помочь исправить их сайт.
5. Поддерживайте свое программное обеспечение в актуальном состоянии. Всегда.

В Jetpack мы прилагаем все усилия, чтобы ваши веб-сайты были защищены от уязвимостей такого типа. Чтобы быть на шаг впереди любых новых угроз, попробуйте Jetpack Scan, который включает сканирование безопасности и автоматическое удаление вредоносных программ.

И спасибо Эрин Казали за освещение этой проблемы и помощь в расследовании.