Ko Google vidi nekaj drugega kot ti: napreden WordPress cloaking z IP-preverjanjem Googlebota

V WordPress svetu smo že vajeni zlorab tipa SEO spam, preusmeritev in klasičnega “cloakinga” (prikaz različne vsebine botom in ljudem). Zanimiv (in precej nevaren) zasuk pa je, ko napadalec ne računa več na grobo filtriranje po User-Agent, ampak poskuša z visoko natančnostjo preveriti, ali je obiskovalec res del Googlove infrastrukture. Rezultat: lastnik spletne strani pri ročnem preverjanju ne vidi ničesar sumljivega, Google pa indeksira čisto drugo vsebino.

Kaj je bilo kompromitirano: index.php kot “vratar”

V analiziranem primeru je bila zlonamerna logika vstavljena neposredno v glavni index.php WordPress strani. To je strateška točka: index.php je vstopna datoteka, prek katere WordPress v običajnem primeru naloži okolje (bootstrap) in nato izriše stran. Če napadalec prevzame nadzor tukaj, lahko pred normalnim nalaganjem WordPressa odloči, ali bo obiskovalec videl legitimno stran ali pa bo dobil vbrizgano oddaljeno vsebino.

Zakaj je ta cloaking drugačen od večine

Klasični cloaking se pogosto zanaša na preprost User-Agent filter: če niz vsebuje “Googlebot”, bot dobi spam vsebino. Težava za napadalca je, da je User-Agent trivialno ponarediti, zato takšne kampanje relativno hitro odkrijemo z ročnim testiranjem ali z osnovnimi skenerji.

Tukaj pa je bila uporabljena bolj “inženirska” varovalka: skripta je imela hardkodiran nabor Googlovih ASN (Autonomous System Number) IP-rangeov v CIDR zapisu in je obiskovalčev IP preverjala matematično, z bitnimi (bitwise) operacijami. Poleg IPv4 je imela tudi solidno podporo za IPv6, kar je pri starejših cloaking skriptah pogosto spregledano.

Hitri pojmi: ASN in CIDR (v kontekstu napada)

ASN (Autonomous System Number)

ASN si lahko predstavljaš kot identiteto omrežja na internetu: številka, ki predstavlja večji blok IP naslovov in usmerjevalno politiko organizacije (npr. Google). Če promet prihaja iz IP prostora, ki pripada Googlovim ASN-jem, je bistveno bolj verjetno, da gre za “pravi” Googlebot (oziroma Googlov crawler iz njihove infrastrukture), ne samo za ponarejen User-Agent.

CIDR zapis

CIDR (Classless Inter-Domain Routing) je kratek zapis IP obsegov, npr. 192.168.1.0/24, ki opiše blok naslovov z omrežnim prefiksom. Namesto naštevanja vsakega IP-ja posebej lahko z enim zapisom definiraš celoten range.

192.168.1.0/24
# pomeni IP-je od 192.168.1.0 do 192.168.1.255

192.168.1.0/24
# pomeni IP-je od 192.168.1.0 do 192.168.1.255

Kako napad deluje v praksi (po fazah)

Vstavljena koda deluje kot selektivni proxy: najprej ugotovi identiteto obiskovalca, nato se odloči, ali bo WordPress normalno nadaljeval ali pa bo stran naložila vsebino iz oddaljenega vira in jo prikazala kot da je lokalna.

1) Večplastna identifikacija: User-Agent + IP preverjanje

Najprej se skripta loti “hitrega” filtra prek HTTP_USER_AGENT (User-Agent je identifikacijski niz, ki ga brskalnik ali bot pošlje ob vsaki zahtevi). Ker je to mogoče ponarediti, sledi drugi korak: preverjanje, ali IP res spada v Googlov ASN range.

2) Validacija IP-rangea z bitnimi operacijami

Namesto preprostega primerjanja nizov skripta pretvori IP in omrežje v numerično obliko in z netmasko preveri ujemanje z omrežnim blokom. Bistvo je v logiki: “ali IP po maskiranju pade v isti network kot definiran range”.

// Konceptualni izsek iz opisa tehnike: preverjanje ujemanja z omrežjem
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Konceptualni izsek iz opisa tehnike: preverjanje ujemanja z omrežjem
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

3) Oddaljen payload prek cURL (remote content injection)

Ko je obiskovalec potrjen kot legitimen Google crawler, koda prek cURL potegne vsebino z zunanje lokacije in jo izpiše v response. V opisanem primeru je bil uporabljen domena/host: hxxps://amp-samaresmanor[.]pages[.]dev (zapis z oklepaji je namenjen varnemu navajanju zlonamernih domen).

4) Širok nabor User-Agent nizov (ne samo “Googlebot”)

Napadalec ni ciljal le na osnovni “Googlebot” podpis. Skripta je filtrirala tudi nize, povezane z Google orodji za verifikacijo, inspeksijo in različnimi crawlerji/API klienti. S tem poveča verjetnost, da bo spam vsebina ne samo indeksirana, ampak tudi uspešno prestala različne Google procese preverjanja.

5) Pogojna logika + logging: skrito, a nadzorovano

Najbolj zlovešče je, da napadalec očitno skrbi za “kakovost” napada: v primeru napake pri nalaganju oddaljene vsebine bot preusmeri (npr. na /home/), da Google ne vidi pokvarjene strani. Če nekdo ponareja Googlebot User-Agent, a IP ne ustreza, skripta zabeleži dogodek (“Fake GoogleBot”) in uporabnika preusmeri na legitimno domačo stran. Običajni obiskovalci so praviloma takoj preusmerjeni na normalno vsebino, zato lastnik pogosto ničesar ne opazi.

Vloga WordPress core datotek: wp-load.php in wp-blog-header.php

Da stran za ljudi deluje normalno, napadalec pogosto pusti, da se WordPress vseeno “bootstrapa”. V opisanem primeru je zlonamerna koda klicala wp-load.php (ta naloži konfiguracijo in pripravi WordPress okolje, vključno z dostopom do baze). V običajnem toku index.php na koncu naloži še wp-blog-header.php, ki izvede glavni WordPress request lifecycle. Vse to napadalcu omogoča, da zlonamerno logiko elegantno vključi, brez da bi takoj podrl spletno mesto.

// Tipičen bootstrap v WordPress kontekstu
require_once __DIR__ . '/wp-load.php';
// ... in v standardnem index.php še wp-blog-header.php (odvisno od implementacije)

// Tipičen bootstrap v WordPress kontekstu
require_once __DIR__ . '/wp-load.php';
// ... in v standardnem index.php še wp-blog-header.php (odvisno od implementacije)

Posledice: predvsem SEO in reputacija domene

Ta tip okužbe je bolj “tiha” kot klasični deface ali masovni redirect. Glavni udarec je na SEO in zaupanje v domeno: Google indeksira vsebino, ki je ti ne vidiš, kar lahko vodi v odstranjevanje iz indeksa (deindexing), blacklisting, degradacijo rezultatov in dolgotrajne težave z reputacijo. Ker je payload oddaljen, lahko napadalec vsebino menja brez dodatnih sprememb na tvojem strežniku.

Znaki, da imaš podoben problem

• V Google rezultatih (SERP) se pojavljajo čudni naslovi/odlomki, ki nimajo veze s tvojo vsebino.
• Nepričakovane ali nedavne spremembe v core datotekah (še posebej index.php).
• Sumljivi URL-ji ali strani, ki obstajajo v indeksu, na strani pa jih ne najdeš.
• Nenavadni log zapisi (preusmeritve, cURL klici, dostopi do index.php) ali spremembe časov zadnje modifikacije datotek.

Kaj narediti ob sanaciji (remediation)

Pri takem incidentu imaš praviloma dve nalogi: odstraniti zlonamerno logiko in zapreti vstopno točko, da se kompromis ne ponovi. Sucuri v priporočilih izpostavlja klasične korake, ki v praksi še vedno največkrat rešijo situacijo.

1. Odstrani neznane datoteke in direktorije: vse, česar nisi namestil ti ali tvoj razvijalec (posebej v rootu in v wp-includes/wp-admin/mu-plugins).
2. Preveri uporabnike: odstrani sumljive administratorje in “pomožne” račune, ki niso dokumentirani.
3. Resetiraj poverilnice: WordPress admin, FTP/SFTP, hosting panel, baze (DB) in po potrebi SSH ključe.
4. Skeniraj lokalni računalnik: če je kompromitiran tvoj dev stroj, se bodo poverilnice hitro spet zlorabile.
5. Posodobi vse: WordPress core, teme in vtičnike; odstrani neuporabljene komponente.
6. Uporabi WAF (Web Application Firewall): WAF lahko blokira znane zlonamerne zahteve in komunikacijo s C2/payload strežniki ter oteži začetni upload zlonamernega koda.

Preventiva, ki se pri core-file napadih najbolj obnese

Ker je bil napad v core vstopni točki (index.php), je zelo smiselno imeti mehanizem, ki takšne spremembe hitro zazna. V praksi so najbolj uporabne naslednje navade:

• File Integrity Monitoring (FIM): spremljanje sprememb kritičnih datotek (npr. index.php, wp-config.php).
• Reden pregled Google Search Console: nenadni “Coverage” problemi, čudni URL-ji ali ročni ukrepi so pogosto prvi signal.
• Minimalen napadalni površinski sloj: manj vtičnikov, odstranitev opuščenih/neudrževanih komponent, strožji access control.
• Logiranje in alerting na nivoju hostinga/WAF: posebno za nenavadne requeste na root index.php in outbound HTTP klice iz PHP-ja.