WordPress cloaking 2.0: kad Googlebot redz vienu, bet lietotāji – pavisam citu

Pēdējā laikā WordPress incidentos arvien biežāk redzu vienu un to pašu tendenci: uzbrucēji vairs nepaļaujas uz brutāliem, acīmredzamiem pāradresējumiem vai “visiem vienādu” spam injekciju. Tā vietā tiek būvēts selektīvs piegādes mehānisms: parastam apmeklētājam vietne izskatās normāla, bet Google robotam (Googlebot un citiem Google rīkiem) tiek pasniegts pilnīgi cits saturs — bieži vien no attālināta avota.

Šāds paņēmiens ir cloaking (satura maskēšana) SEO kontekstā, bet konkrētajā gadījumā interesantākais ir tehniskais izpildījums: ar User-Agent vien nepietiek — skripts pārbauda arī IP piederību Google infrastruktūrai, izmantojot Google ASN (Autonomous System Number) IP diapazonus CIDR formātā un bitu līmeņa (bitwise) aprēķinus, ieskaitot IPv6 atbalstu.

Kas tieši tiek kompromitēts: WordPress index.php kā “vārtsargs”

Infekcija tika atrasta WordPress vietnes galvenajā index.php failā. Tā ir ļoti neērta vieta aizsardzības ziņā: daudzos projektos index.php reti tiek mainīts, tāpēc neautorizētas izmaiņas var palikt nepamanītas, ja nav failu integritātes kontroles.

Ideja vienkārša: kompromitēts index.php pirms “parastā” WordPress ielādes noskaidro, kas ir pieprasījuma veicējs. Atkarībā no rezultāta tas vai nu ielādē attālinātu saturu no trešās puses, vai arī parāda standarta, tīru vietnes versiju.

Kāpēc šis cloaking ir “jaunās paaudzes”

Tradicionāli cloaking skripti aprobežojas ar HTTP_USER_AGENT pārbaudi (piemēram, vai virknē ir “Googlebot”). Problēma — User-Agent ir viegli viltot. Tāpēc šajā paraugā ir ieviests nākamais slānis: IP validācija pret Google IP diapazoniem.

Kas ir Google ASN un kāpēc tas uzbrucējam ir svarīgi

ASN (Autonomous System Number) var uztvert kā organizācijas “interneta identitāti” — tas apzīmē IP adrešu kopu un maršrutēšanas domēnu, kas pieder konkrētam operatoram. Ja pieprasījums nāk no Google ASN IP diapazona, tas nozīmē, ka tas, visticamāk, nāk no reālas Google infrastruktūras (Search, Gmail, Google Cloud u.c.), nevis no nejauša servera, kas tikai izliekas par botu.

Kas ir CIDR un kāpēc tas parādās ļaunprātīgajā kodā

CIDR (Classless Inter-Domain Routing) ir kompakts pieraksts IP diapazoniem. Tā vietā, lai glabātu tūkstošiem IP adrešu, var glabāt “blokus”, piemēram 192.168.1.0/24, kas apzīmē diapazonu no 192.168.1.0 līdz 192.168.1.255. Uzbrucējam tas ir ideāli: viena “bibliotēka” ar daudziem CIDR blokiem, pret kuriem pārbaudīt apmeklētāja IP.

Kā darbojas verifikācija: no User-Agent līdz bitwise tīkla pārbaudei

Šāda tipa malware parasti strādā kā vairāku slāņu filtru ķēde: vispirms ātrāks un vienkāršāks nosacījums, tad dārgāks (bet drošāks) pārbaudījums.

1) Multi-layer pārbaude (User-Agent + IP)

Sākumā skripts pārbauda HTTP_USER_AGENT un meklē ne tikai “Googlebot”. Bieži tiek iekļauti arī citi Google rīku identifikatori, kas saistīti ar vietnes pārbaudi, inspekciju un dažādiem API crawleriem. Mērķis: panākt, lai ļaunprātīgais saturs tiek gan indeksēts, gan redzams Google ekosistēmas verifikācijas procesos.

2) Bitwise IP diapazona validācija (IPv4/IPv6)

Tālāk seko IP adrešu pārbaude pret CIDR blokiem, izmantojot bitu operācijas. Tas ir daudz precīzāk nekā primitīva virknīšu salīdzināšana, jo reāli aprēķina, vai IP “iekrīt” tīkla maskā.

IPv4 gadījumā tipiska loģika izskatās šādi (svarīgs ir princips):

<?php
// Konceptuāls piemērs: pārbaude, vai IP atbilst CIDR diapazonam
// (nepieciešamas konversijas uz decimālo formu un netmask aprēķins)

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

<?php
// Konceptuāls piemērs: pārbaude, vai IP atbilst CIDR diapazonam
// (nepieciešamas konversijas uz decimālo formu un netmask aprēķins)

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Īpaši būtiski: skripts atbalsta arī IPv6, ko daudzi vecāki cloaking varianti ignorē. Tas palielina iespēju, ka tiks noķerti “īsti” Google pieprasījumi neatkarīgi no tā, pa kuru IP ģimeni tie atnāk.

3) Attālināta payload ielāde ar cURL

Ja apmeklētājs ir “īstais” Google bots (pēc User-Agent) un IP pieder Google diapazonam, malware ielādē saturu no attālināta resursa un izdrukā to lapā tā, it kā tas būtu vietnes saturs.

Konkrētajā gadījumā attālinātais domēns tika minēts kā amp-samaresmanor[.]pages[.]dev (rakstu formā ar iekavām, lai nejauši neaktivizētu saites). Pēc apraksta tas jau ir iekļauts blocklistos atsevišķos drošības rīkos.

4) Nosacījumu loģika + kļūdu žurnālošana

Interesants elements ir tas, ka uzbrucējs ir ielicis ne tikai “if/else”, bet arī kļūdu apstrādi un žurnālošanu, lai saprastu, vai shēma strādā:

• Ja verifikācija izdodas, bots saņem attālināto saturu; ja saturs neielādējas, botu var aizsūtīt uz /home/, lai Google neredz “salūzušu” lapu.
• Ja kāds izliekas par Googlebot (User-Agent sakrīt), bet IP neatbilst diapazonam, tiek fiksēts notikums (piem., “Fake GoogleBot detected”) un apmeklētājs tiek novirzīts uz normālo sākumlapu.
• Visi pārējie lietotāji tiek turēti “tīrajā” pieredzē — tipiski ar tūlītēju novirzīšanu uz standarta lapu.

Kā tas “sadzīvo” ar WordPress core failiem

Lai kompromitētais index.php varētu gan izpildīt savu ļaunprātīgo loģiku, gan vajadzības gadījumā darbināt WordPress kā parasti, tiek izmantoti core iekraušanas punkti:

• wp-load.php: tiek iekļauts ar require_once, lai “ieslēgtu” WordPress vidi (konfigurācija, DB pieslēgums u.c.).
• wp-blog-header.php: tipiski tiek ielādēts pašās beigās standarta index.php plūsmā, lai renderētu lapu.

Ietekme: nevis tikai “malware”, bet SEO reputācijas sabotāža

Šīs infekcijas mērķis galvenokārt ir meklētājprogrammu uzticības izmantošana. Ja Google redz spam vai citus nevēlamus materiālus, bet lietotāji redz normālu vietni, sekas var būt smagas arī tad, ja konversijas šobrīd nekrīt:

• meklētājprogrammu sankcijas un/vai deindeksācija
• melnaksta (blacklisting) riski un reputācijas bojājumi
• resursu “nolaupīšana” (jūsu domēns reāli kalpo svešam saturam)
• novēlota atklāšana, jo manuāli pārlūkojot viss izskatās kārtībā

Pazīmes, kas var norādīt uz šādu kompromitāciju

Selektīvais cloaking ir tieši tāpēc bīstams, ka admin panelī un pārlūkā “no mājām” viss šķiet normāli. Praktiski signāli, kas biežāk nostrādā:

• Google rezultātos parādās dīvaini virsraksti/snippet vai lapas, ko neesi veidojis
• core failiem (īpaši index.php) ir nesena modifikācijas vēsture bez pamatota iemesla
• žurnālos parādās aizdomīgi pieprasījumi/novirzīšanas uzvedība (īpaši botiem)
• servera failos ir sveši URL vai cURL izsaukumi, kas nav saistīti ar tavām funkcijām

Ko darīt incidenta laikā: praktiska secība WordPress projektam

Ja ir aizdomas par šādu infekciju, racionāli ir fokusēties uz diviem virzieniem: (1) ātri apturēt kaitējumu un (2) iztīrīt sākotnējo piekļuves ceļu, lai infekcija neatgrieztos.

1. Pārbaudi un salīdzini core failus ar oficiālajiem WordPress failiem (īpaši index.php, bet arī citus ieejas punktus).
2. Dzēs jebkuru failu/direktoriju, ko nevari izskaidrot (īpaši, ja tur ir cURL izsaukumi vai obfuskācija).
3. Pārskati lietotājus: noņem aizdomīgus administratorus un “palīgkontus”, kas nav pamatoti.
4. Nomaini paroles: WordPress admin, hostings, FTP/SFTP, DB, arī API atslēgas, ja tādas ir.
5. Palaid pilnu antivīrusa/anti-malware skenēšanu savā datorā (reālos incidentos bieži kompromitēts ir arī darba dators).
6. Atjaunini visu: WordPress core, spraudņus, tēmas; noņem pamestos/nevajadzīgos komponentus.
7. Ievies WAF (Web Application Firewall): tas palīdz gan bloķēt zināmus C2 (command-and-control) galapunktus, gan samazināt iespēju augšupielādēt ļaunprātīgus spraudņus vai failus.

Preventīvi: failu integritāte un Search Console disciplīna

Šis gadījums labi parāda, ka “pamanīšu, ja kaut kas būs” vairs nestrādā. Selektīvs cloaking var mēnešiem dzīvot mierīgi. Divi praktiski pasākumi, kas dod vislielāko atdevi:

• File Integrity Monitoring (failu integritātes uzraudzība): automātiski paziņo, ja core failos (piem., index.php) ir neautorizētas izmaiņas.
• Regulāra Google Search Console pārbaude: meklē negaidītas indeksētas lapas vai pārklājuma (Coverage) anomālijas, kas var norādīt uz maskētu saturu.