Kui Google näeb üht ja külastaja teist: WordPressi pahavara, mis tuvastab Googleboti IP järgi

Viimaste kuude intsidentides on hakanud silma üks ebameeldiv trend: pahavara ei ürita enam tingimata iga külastajat kuhugi kahtlasesse kohta suunata. Selle asemel käitutakse selektiivselt – päris inimestele näidatakse tavalist saiti, aga otsingumootorite roomikutele (crawler) serveeritakse hoopis teist sisu. Omanik logib sisse, kontrollib avalehte ja kõik paistab korras. Google aga indekseerib spämmi.

Sucuri analüüsis ühte sellist juhtumit, kus WordPressi põhifaili index.php oli lisatud “väravavahi” loogika: see otsustab, kas laadida WordPress tavapäraselt või tõmmata välisest allikast täiesti teistsugune payload (sisu/skript), mida näeb sisuliselt ainult Google’i infrastruktuur.

Mis rünnakuga tegu on (ja miks see on ebameeldiv)?

See on klassikalise cloaking’u (sisu varjamine) edasiarendus. Mõte on lihtne: otsingumootorile näitad midagi, mis aitab sul indekseeruda (või mida ründaja tahab indekseerida), aga päriskasutaja näeb “puhast” saiti. Praktikas tähendab see, et Google’i tulemustes võivad ilmuda lehed, mida sinu WordPress tegelikult kunagi ei genereeri.

Eriti ohtlikuks teeb selle juhtumi see, et ründaja ei piirdu ainult User-Agenti kontrolliga (mida saab väga lihtsalt võltsida). Skript kontrollib ka IP-aadressi ning teeb seda üsna tehniliselt korralikult.

Kus pahavara peidus oli?

Leitud juhtumis oli muudatus tehtud WordPressi peamisele index.php failile. See on kriitiline koht, sest tavapäraselt toimib index.php WordPressi esiletõstetud “front controller” sarnase sissepääsuna: kui ründaja saab sinna oma kontrollloogika, saab ta otsustada, kas WordPress üldse käivitub või mitte.

Mis oli tehniliselt „uus” võrreldes tavapärase botifiltriga?

Tavapärane halb skript kontrollib HTTP_USER_AGENT väärtust ja kui näeb sealt „Googlebot”, serveerib midagi muud. Probleem: seda saab igaüks curliga järgi teha. Antud juhul lisati teine kiht: kontrollitakse, kas päring tuleb Google’i IP-vahemikest.

Siin tulevad mängu kaks mõistet, mida tasub sama laua taga hoida:

• ASN (Autonomous System Number) – autonoomsüsteemi number, sisuliselt võrguoperaatori „internetipass”. Google’il on oma ASN-id ja nende all konkreetne hulk IP-vahemikke.
• CIDR (Classless Inter-Domain Routing) – notatsioon IP-vahemike kirjeldamiseks kujul x.x.x.x/nn, kus mask määrab, kui suur see võrgublokk on. Näiteks 192.168.1.0/24 katab 192.168.1.0 kuni 192.168.1.255.

Pahavara sisaldas suurt, hardcode’itud nimekirja Google’i ASN-iga seotud IP-vahemikest CIDR formaadis ning tegi kontrolli mitte stringivõrdlusega, vaid bititasemel arvutusega (sh IPv6 tugi). See teeb käsitsi avastamise ebamugavaks: isegi kui sa esined Googlebotina, saad „tavalise” lehe – sest IP ei klapi.

Kuidas see „väravavaht” loogika töötab (kõrgel tasemel)

Leitud skript tegi otsuse mitmes astmes. Kui mõelda sellest kui request pipeline’ist, siis ründaja on pannud index.php algusesse preflight-kontrollid ning alles siis otsustab, kas WordPressi bootstrap üldse käivitada.

1) Mitmekihiline identiteedikontroll: User-Agent + IP

Esmalt vaadatakse HTTP_USER_AGENT stringi ja otsitakse sealt erinevaid Google’i roomikute ja tööriistade mustreid (mitte ainult „Googlebot”, vaid ka mitmed verifitseerimise/inspekteerimisega seotud agendid). Kuna User-Agent on triviaalne spoofida, järgneb sellele IP-aadressi valideerimine.

2) IP vahemiku kontroll bitioperatsioonidega

IPv4 puhul kasutatakse klassikalist võrgumaski kontrolli loogikat: võetakse IP ja võrguadress, tehakse mõlemale AND netmask’iga ning võrreldakse tulemusi. See on standardne viis kontrollida, kas IP kuulub CIDR-võrgublokki.

// Loogika idee (näidiskuju)
// Kui IP ja võrgubloki aadress annavad maski all sama tulemuse,
// siis IP kuulub antud CIDR vahemikku.
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Loogika idee (näidiskuju)
// Kui IP ja võrgubloki aadress annavad maski all sama tulemuse,
// siis IP kuulub antud CIDR vahemikku.
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

3) Kui bot on „päris”, tõmmatakse remote payload cURLiga

Kui User-Agent ja IP mõlemad klapivad, tehakse serveri poolt (PHP kaudu) HTTP päring välisele domeenile ja saadud sisu prinditakse otse vastusesse. Nii näeb otsingumootor seda justkui saidi enda sisuna.

# Rünnakus kasutatud URL (ohtlik):
# hxxps://amp-samaresmanor[.]pages[.]dev

# Rünnakus kasutatud URL (ohtlik):
# hxxps://amp-samaresmanor[.]pages[.]dev

4) Detailne User-Agenti filtreerimine

Lisaks klassikalisele „Googlebot” stringile oli filtris terve hulk Google’iga seotud roomikuid ja utiliite. Eesmärk on, et pahatahtlik sisu läbiks mitte ainult indekseerija, vaid ka muud Google’i kontrollid (nt erinevad inspekteerimis- ja API-põhised päringud).

5) Tingimusloogika, suunamised ja logimine

Loogika ei ole “serveeri ja unusta”. Skriptis oli ka error handling ja logimine: kui remote-sisu ei lae, suunatakse bot näiteks /home/ teele, et vältida Google’ile katkist lehte. Kui User-Agent tundub Google, aga IP ei klapi, logitakse „Fake GoogleBot detected” ning näidatakse tavalist lehte. Tavakülastaja suunatakse samuti “normaalsele” avalehele.

Mida see su saidiga teeb?

Selle nakkuse põhimõju on SEO ja otsingumaine. Kuna Google saab teistsuguse sisu kui kasutaja, võivad tagajärjed olla ebameeldivad ka siis, kui saidi funktsionaalsus kasutajale justkui töötab:

• indeksisse tekivad ootamatud/spämmilehed või -katked
• otsingutulemustes halveneb snippet ja CTR
• võimalik musta nimekirja (blacklist) sattumine või deindekseerimine
• ressursside kuritarvitus: sinu domeeni autoriteeti kasutatakse kellegi teise sisu levitamiseks
• avastamine hilineb, sest käsitsi brausides ei näe midagi valesti

Ohumärgid, mille peale tasub kohe reageerida

• Google’i otsingutulemustes ilmuvad sinu domeeni all kummalised pealkirjad/URL-id
• serveris või Gitis (kui kasutad) on ootamatult muudetud core-failid, eriti index.php
• logides on ebatavalised päringud või suunamised (nt botidega seotud UA mustrid)
• kahtlased välised URL-id koodis või võrguliikluses (eriti kui neid ei leia frontendist)

Miks WordPressi core-failid on ründaja jaoks nii väärtuslikud?

Leitud näites kasutati ära WordPressi standardseid käivitusfaile, et pahavara ja „päris” sait saaksid samas protsessis koos eksisteerida.

• wp-load.php – selle include’iga bootstrappitakse WordPressi keskkond (konfig, DB ühendus, globaalsed funktsioonid). Pahavara saab vajadusel ligi saidi seadistusele ja andmebaasile.
• wp-blog-header.php – tavapärase index.php lõpuosa, mis käivitab teema renderdamise. Pahavara võib otsustada, kas sinna üldse jõutakse või mitte.

Puhastamine ja ennetus: mida teha, kui kahtlustad sarnast nakatumist?

Kui näed SEO-s anomaaliaid või leiad ootamatuid muudatusi core-failides, tasub tegutseda eeldusel, et kompromiteerimine on toimunud (mitte oodata “kuni läheb üle”). Sucuri soovitused on üsna klassikalised, aga selle ründe kontekstis eriti olulised:

1. Eemalda tundmatud failid ja kaustad. Kui sa ei tea, milleks see on, ja repo/varukoopia seda ei tunne, käsitle seda kahtlasena.
2. Auditeeri kasutajad. Eemalda kahtlased admin-kontod ja eriti „abikontod”, mis ei peaks seal olema.
3. Vaheta kõik paroolid. WordPressi adminid, FTP/SFTP, hostingupaneel, andmebaas – kõik.
4. Skänni oma arvuti. Kui ründaja sai ligipääsu sinu töömasina kaudu, taastub nakkus kiiresti.
5. Uuenda kõik. Core, pluginad, teemad – ning eemalda kasutamata komponendid.
6. Kasuta WAF-i. Web Application Firewall aitab blokeerida tuntud pahatahtlikku liiklust ning piirata pahavara suhtlust C2/remote-payload allikatega.