Когато Googlebot вижда друго: WordPress malware с IP-верифицирано „cloaking“ през ASN и CIDR

Един от най-неприятните сценарии при компрометиран WordPress сайт е, когато собственикът (и екипът) отварят началната страница и всичко изглежда наред, но в Google резултатите излизат спам страници, странни заглавия и описания или дори деиндексиране. В последните кампании се вижда еволюция: вместо „шумни“ редиректи, злонамереният код започва да обслужва payload селективно – основно към търсачки и техните краулъри, и то по начин, който е труден за репродуциране при ръчен тест.

Конкретният случай, който ще разгледам, е от разследване на Sucuri: модифициран index.php в WordPress, който играе ролята на gatekeeper. Ако „посетителят“ е реален Googlebot, сайтът връща външно съдържание (включително spam/SEO payload). Ако е нормален потребител – WordPress се зарежда стандартно и всичко изглежда чисто.

Какво прави атаката различна от класическото cloaking

SEO cloaking (показване на различно съдържание на търсачки и на хора) не е новост. Новото тук е нивото на верификация. Много стари скриптове се доверяват само на User-Agent (например съдържа „Googlebot“). Това се фалшифицира елементарно.

В разглеждания malware има хардкодната „библиотека“ от IP диапазони на Google, описани през ASN и CIDR, и валидиране с битови операции (bitwise). Така атакуващият не просто проверява текстов стринг, а математически потвърждава дали IP адресът на заявката попада в очакван мрежов блок. Плюс: има и поддръжка за IPv6 – нещо, което доста „масови“ cloaking имплементации игнорират.

Бързи дефиниции: ASN, CIDR и защо ги използват атакуващите

ASN (Autonomous System Number) е идентификатор на автономна система – най-практичното обяснение за нас е „официалната интернет идентичност“ на голяма инфраструктура (в случая Google). Тя обхваща набор от IP адреси, използвани от услуги като Search, Gmail, Google Cloud и реалните краулъри.

CIDR (Classless Inter-Domain Routing) е формат за описване на IP диапазон като мрежов блок, напр. 192.168.1.0/24. Суфиксът /24 определя размера на блока (маската) и позволява проверка „дали IP-то е в този диапазон“ без да се изброяват всички адреси.

Как работи инфекцията: gatekeeper в index.php

Откритият код е в основния index.php на WordPress – място, което по принцип очакваме да е стабилно и рядко пипано. Вместо винаги да boot-ва WordPress, файлът първо прави серия проверки кой е посетителят и едва после решава какво да върне.

1) Многостепенна верификация: User-Agent + реален IP диапазон

Логиката започва с проверка на HTTP User-Agent (текстовият идентификатор, който браузърът/ботът изпраща при всяка заявка и който обикновено описва клиент, устройство, ОС). Това е първи филтър. След това идва същинската защита срещу spoofing: сравнение на IP адреса спрямо списък от мрежови блокове на Google (в CIDR), за да се потвърди, че заявката идва от реалната инфраструктура, а не от някой, който просто се представя за Googlebot.

2) Bitwise валидиране на IP диапазон (CIDR match)

Ключовият момент е, че проверката не е „дали IP-то започва с…“, а реален мрежов match чрез маска (netmask). За IPv4 примерната формула е от типа:

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal)
// Ако двете страни съвпадат, IP адресът попада в CIDR блока.

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal)
// Ако двете страни съвпадат, IP адресът попада в CIDR блока.

3) Зареждане на външен payload през cURL

След като „посетителят“ бъде потвърден като легитимен Google bot, скриптът извлича remote съдържание през cURL от външен домейн и го отпечатва директно в отговора. Така за търсачката изглежда, че съдържанието е част от сайта, а реално се хоства и контролира отвън.

4) Условна логика + логване на грешки (за да се „самокоригира“)

Този тип malware често има „операторска“ логика: ако проверките минат, сервира payload и логва успех; ако payload не може да се зареди, вместо да остави търсачката да види счупена страница, прави fallback (например редирект към /home/). Ако някой се опитва да се представи за Googlebot само с User-Agent, но IP проверката се провали, се логва нещо от сорта на „Fake GoogleBot detected“ и заявката се праща към нормалната начална страница. За всички останали посетители – показва се легитимният сайт.

Защо точно index.php и как се „вписва“ в WordPress

Причината атакуващите да харесват core entrypoint като index.php е проста: това е точка, през която минава почти целият трафик. В описания случай кодът използва WordPress файлове, за да не „счупи“ сайта и да може да зарежда нормално, когато реши.

• wp-load.php – включва се, за да boot-не WordPress средата и да даде достъп до конфигурация и база (типичен pattern е require_once __DIR__ . '/wp-load.php').
• wp-blog-header.php – стандартно се изисква в края на легитимния WordPress index.php, така че при „нормален“ режим посетителите да получат чистата страница.

Какъв е ефектът: SEO удар, репутационен риск и забавено откриване

Този клас инфекции са фокусирани върху SEO и доверие. Тъй като Google индексира друго съдържание от това, което виждат хората и екипът, последствията често са неприятни и неочаквани:

• деиндексиране или понижаване на позиции поради спам/манипулативно съдържание;
• blacklisting и предупреждения в търсачки/браузъри;
• „resource hijacking“ – сайтът става канал за чуждо съдържание, контролирано отвън;
• забавено откриване, защото ръчните проверки показват нормален сайт.

Сигнали, че нещо не е наред (дори когато сайтът изглежда „чист“)

• Подозрителни резултати в Google (непознати заглавия/описания, спам страници, странни sitelinks).
• Неочаквано модифицирани файлове – особено в root (index.php) и в wp-includes/, wp-admin/.
• Съмнителни външни URL-и в код/логове, които не са част от проекта.
• Странни логове и редиректи, които се проявяват само при конкретни User-Agent-и.

Практични стъпки за реакция и превенция

При подобни инфекции целта е двойна: (1) да премахнеш инжекцията и всички точки за повторно заразяване; (2) да намалиш шанса да се случи пак. От препоръките в разследването изпъкват няколко задължителни хигиенни действия:

1. Премахни непознати файлове и директории: всичко, което не е част от темата/плъгините/ядрото и не можеш да обясниш откъде е дошло.
2. Одит на потребители: премахни „help“ акаунти и всякакви подозрителни администратори.
3. Ресет на креденшъли: WordPress админи, FTP/SFTP, хостинг панел, база данни (и по възможност ключове/соли в wp-config.php според вътрешната ви практика).
4. Сканирай локалната машина: ако dev машината е компрометирана, чистенето на сървъра няма да е достатъчно.
5. Обновявай всичко: core, плъгини, теми – особено ако има изоставени компоненти.
6. Ползвай WAF (Web Application Firewall): може да блокира комуникация към известни злонамерени крайни точки и да спре част от първоначалните опити за качване на malware.

Изводът: „тиха“ атака, която използва доверието към търсачките

Този случай е добър пример за модерния подход при WordPress компрометирането: вместо да се афишира с видими редиректи и popups, malware-ът превръща сайта в контролиран gateway за съдържание и разчита на това, че собствениците тестват основно като „обикновен посетител“. Комбинацията от User-Agent филтър, ASN/CIDR списъци и bitwise IP проверка прави инфекцията селективна и трудна за хващане без систематичен мониторинг и одит на файловете.