Googlebotra céloz, neked láthatatlan: IP-tartományokra építő WordPress cloaking malware

Az egyik legkellemetlenebb WordPress-es fertőzés az, amit nem is nagyon tudsz „észrevenni”. A site neked és a normál látogatóknak rendben betölt, nincs látványos átirányítás, nem ugrik fel gyanús popup – közben viszont a keresőmotorok (különösen a Google) teljesen más tartalmat kapnak. Ennek eredménye tipikusan SEO-spam, indexelési káosz, reputációromlás, rosszabb esetben feketelistázás.

A Sucuri egy olyan esetről írt, ahol a támadók nem elégedtek meg a szokásos, könnyen hamisítható User-Agent szűréssel. A malware a Google infrastruktúrájához tartozó IP-tartományokat is ellenőrizte (ráadásul IPv4 és IPv6 esetén is), és csak akkor szolgálta ki a rejtett payloadot, ha a kérést tényleg „igazi” Googlebotnak gondolta.

Mi történt a gyakorlatban? Index.php mint kapuőr

A vizsgált fertőzés a WordPress oldal fő belépési pontjába, az index.php fájlba került. Ez különösen veszélyes hely: ha a támadó itt dönt arról, hogy mi fusson le, akkor gyakorlatilag a teljes alkalmazás indítása előtt tud szelektálni.

A logika lényege: a módosított index.php először azonosítani próbálja a látogatót. Ha „átlagos” felhasználó vagy, a WordPress a megszokott módon szolgál ki. Ha viszont a látogató egy keresőrobotnak tűnik, akkor a támadó által megadott külső forrásból tölt be tartalmat, és azt adja vissza a robotnak – mintha az az oldal saját tartalma lenne.

Miért újdonság ez? Nem csak User-Agent alapján szűr

A cloaking (amikor a keresőrobot mást lát, mint a felhasználó) nem új trükk. Az viszont ritkább, hogy a támadó ennyire „precízen” azonosít: a script egy nagy, hardcode-olt listát tartalmazott Google ASN-hez (Autonomous System Number) köthető IP-tartományokról CIDR formátumban.

ASN röviden: mit jelent, és miért fontos?

Az ASN (Autonomous System Number) lényegében egy hálózati „azonosító” az interneten: IP-címblokkok és útvonalak szerveződnek alá, tipikusan nagy szolgáltatókhoz (például Google) kapcsolódva. Ha egy kérés a Google ASN-hez tartozó hálózatból érkezik, az jó eséllyel valódi Google infrastruktúra – nem csak valaki, aki beírta a User-Agentbe, hogy Googlebot.

CIDR: hogyan írunk le IP-tartományt tömören?

A CIDR (Classless Inter-Domain Routing) egy tömör jelölés IP-tartományokra. Például a 192.168.1.0/24 azt jelenti, hogy a 192.168.1.0–192.168.1.255 tartomány egy blokk. A perjel utáni szám (itt 24) a hálózati maszk méretét adja meg, vagyis hogy mekkora a tartomány.

Hogyan működik a malware? Többrétegű ellenőrzés és távoli tartalom betöltése

A minta alapján ez a fertőzés egy klasszikus „kapuőr” (gatekeeper) megoldás: több lépésben próbálja biztosítani, hogy csak a megfelelő célpont (Google robot és kapcsolódó eszközök) kapja meg a rejtett tartalmat.

1) Többlépcsős azonosítás: User-Agent + IP validálás

Első körben a script megnézi a HTTP_USER_AGENT fejlécet. A User-Agent egy szöveg, amit a böngésző (vagy crawler) minden kérésnél elküld, és tipikusan tartalmazza, hogy milyen kliensről, eszközről, operációs rendszerről van szó. Ezt nagyon könnyű hamisítani, ezért jön a második lépés: az IP-tartomány ellenőrzése.

2) Bitműveletes IP-tartomány ellenőrzés (IPv4/IPv6)

A technikailag érdekes rész az, hogy a script nem „string keresést” végez IP-címekre, hanem számol: bitműveletekkel ellenőrzi, hogy a látogató IP-je beleesik-e egy adott CIDR tartományba. A Sucuri példája IPv4-re ezt a logikát mutatja:

// IPv4 hálózati egyezés ellenőrzésének alapelve (a Sucuri elemzése alapján)
// (ip & netmask) == (range & netmask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// IPv4 hálózati egyezés ellenőrzésének alapelve (a Sucuri elemzése alapján)
// (ip & netmask) == (range & netmask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

A gyakorlati következmény: ha te manuálisan tesztelsz, hiába állítod át a User-Agentet Googlebotra, a payload akkor sem fog megjelenni, mert az IP-d nem a Google hálózatából jön. Ráadásul a kód IPv6-tal is foglalkozott, amit sok régebbi cloaking script egyszerűen ignorál.

3) Távoli payload betöltése cURL-lel

Ha a látogató átment az ellenőrzésen, a script cURL-lel (PHP-s HTTP kliens) letölt egy külső oldalról tartalmat, majd azt közvetlenül a válaszba írja. A vizsgált esetben a távoli domain a forrás szerint ez volt: hxxps://amp-samaresmanor[.]pages[.]dev.

4) Széles User-Agent szűrés: nem csak „Googlebot”

A szűrés nem áll meg a Googlebot névnél. A script több, Google-höz köthető azonosítót is figyelembe vett (például site verification és különböző ellenőrző/inspekciós eszközök). Ez arra utal, hogy a támadó célja nem pusztán az indexelés, hanem az is, hogy a rejtett tartalom a Google különböző ellenőrzési folyamataiban is konzisztensen megjelenjen.

5) Feltételes logika, hibakezelés és naplózás

A döntési fa kifejezetten „üzembiztosra” van összerakva: ha legit Google User-Agent + legit Google IP, akkor jön a payload, és a script naplózza a sikert. Ha a távoli tartalom nem tölthető be, a botot /home/ felé tereli, hogy ne egy hibás oldal kerüljön indexbe. Ha valaki hamis Googlebot (csak User-Agent, de nem Google IP), a kód „Fake GoogleBot detected” jellegű bejegyzést készít és visszairányít a normál kezdőoldalra. Minden más látogató szintén a normál oldalra kerül.

Miért fáj ez ennyire? SEO, reputáció és késleltetett észlelés

Ennek a fertőzésnek a fő „haszna” a támadónak SEO-manipuláció: a Google spam tartalmat lát, te meg a saját oldaladat. A tipikus következmények a forrás alapján:

• Indexelési problémák és deindexelés (eltűnő oldalak, „furcsa” találatok).
• Keresőmotoros feketelistázás és reputációromlás.
• Erőforrások eltérítése (a domained tekintélyét más tartalomra használják).
• Késleltetett detektálás, mert manuális böngészésnél nem jön elő a payload.

Gyanús jelek: mikor kezdj el azonnal vizsgálódni?

Cloaking esetén a klasszikus „a site feltört” jelek sokszor hiányoznak. Érdemes célzottan ezeket figyelni:

• Rossz minőségű vagy irreleváns Google találatok a domainre (spam jellegű snippetek, furcsa title-ek).
• Frissen módosított core fájlok (különösen: index.php).
• Ismeretlen, gyanús URL-ek felbukkanása (Search Console-ban vagy logokban).
• Szokatlan szerverlog minták: botoknál más válaszméret, eltérő útvonalak, váratlan átirányítások.

Mit csinál a WordPress core fájlokkal? (wp-load.php és wp-blog-header.php)

A támadók nem véletlenül nyúlnak core fájlokhoz: így a saját kódjuk úgy tud futni, hogy közben a WordPress normál működését is „megtartják” – vagy épp szelektíven elindítják.

• wp-load.php: a malware a forrás szerint behúzza (require_once __DIR__ . '/wp-load.php'), ezzel „bootstrappel” WordPress környezetet, hozzáfér a konfigurációhoz és az adatbázishoz.
• wp-blog-header.php: a normál WordPress index.php végén szereplő behúzás; a támadó ezt úgy alakíthatja, hogy csak bizonyos esetekben jusson el idáig a futás.

Takarítás és megelőzés: mire érdemes fókuszálni?

A Sucuri javaslatai alapján ennél a típusú fertőzésnél nem elég „ránézni” a frontend-re. A célzott védekezéshez a következő lépések kellenek:

1. Ismeretlen fájlok és könyvtárak törlése: ami nem a tiéd vagy a fejlesztődé, menjen karanténba és vizsgáld meg.
2. Felhasználók auditja: gyanús adminok, „segéd” fiókok törlése.
3. Minden jelszó cseréje: WordPress admin, FTP/SFTP, hosting, adatbázis, és ahol még hozzáférés van.
4. Saját géped átvizsgálása: teljes vírusirtó/malware scan, mert a belépési adatok ellopása gyakori belépési pont.
5. Minden frissítése: WordPress core, bővítmények, sablonok – különösen az elhagyott (abandoned) komponensek veszélyesek.
6. WAF használata: Web Application Firewall (alkalmazásrétegű tűzfal), ami tudja blokkolni a gyanús forgalmat és csökkentheti az elsődleges feltöltés/kompromittálás esélyét.
7. File Integrity Monitoring bevezetése: fájlintegritás-ellenőrzés, ami azonnal jelez, ha core fájlok (pl. index.php) változnak.
8. Google Search Console rendszeres átnézése: váratlan URL-ek, hirtelen megugró indexelt oldalszám, ismeretlen tartalmak gyors kiszúrása.

Összefoglaló: a „csendes” malware korszakában a botok a célpontok

Ez a támadás jó példa arra, merre tart a WordPress elleni malware: nem feltétlenül látványos átirányításokkal dolgozik, hanem célzottan a keresőrobotoknak épít alternatív valóságot. A User-Agent szűrést IP-tartomány validálással (ASN + CIDR, bitműveletek, IPv6 támogatás) erősíti meg, így a fertőzés sokáig rejtve maradhat. Ha a Google-ben furcsa találatok jelennek meg, az index.php és a core fájlok integritása legyen az első ellenőrzési pontod.