Kai WordPress index.php pradeda „kalbėtis“ tik su Googlebot: pažangus cloaking su IP (ASN) tikrinimu

Pastaruoju metu vis dažniau matyti ne triukšmingi „peradresuok visus į spamą“ scenarijai, o gerokai subtilesnės infekcijos. Idėja paprasta: svetainės savininkas ir realūs lankytojai mato įprastą turinį, o paieškos sistemų robotams pateikiamas kitas – dažniausiai spam, doorway ar „affiliate“ turinys. Tokia taktika leidžia išnaudoti svetainės reputaciją SEO tikslams ir ilgiau išlikti nepastebėtai.

Kas buvo aptikta: selektyvi turinio injekcija WordPress index.php

Analizuojant vieną užkrėstą WordPress svetainę, kenkėjiškas kodas buvo rastas pagrindiniame index.php. Vietoje įprasto WordPress „bootstrap“ (įkėlimo) srauto šis failas elgėsi kaip vartininkas: pirmiausia nustatydavo, kas atėjo į svetainę, o tada priimdavo sprendimą – rodyti švarų puslapį ar įterpti nuotolinį turinį.

Svarbiausia detalė: tai ne vien User-Agent filtravimas. Šį kartą buvo naudojamas IP tikrinimas pagal Google priklausančius tinklus – ir dar su tikra tinklų matematika, o ne paprastu „string match“.

Kuo šis atvejis išsiskiria: Google ASN diapazonai ir CIDR + bitinės operacijos

Dauguma „cloaking“ (turinio maskavimo) skriptų apsiriboja User-Agent eilute: jei joje yra „Googlebot“ – rodome vieną, jei ne – kitą. Problema ta, kad User-Agent lengva suklastoti. Todėl ši infekcija ėjo toliau: ji turėjo „hardcodintą“ (įrašytą tiesiai į kodą) didelį Google ASN IP diapazonų sąrašą CIDR formatu ir tikrino, ar užklausa tikrai atėjo iš Google infrastruktūros.

Kas yra ASN (Autonomous System Number) šiame kontekste?

ASN (Autonomous System Number) – tai autonominės sistemos numeris, savotiškas organizacijos „interneto identitetas“. Praktikoje tai reiškia IP adresų blokus, kurie priklauso ir yra valdomi, pvz., Google (Gmail, Search, Google Cloud ir pan.). Jei užklausa ateina iš Google ASN priklausančio IP, tikimybė, kad tai „tikras“ Google crawler’is, yra nepalyginamai didesnė nei vien pasitikint User-Agent.

Kas yra CIDR formatas?

CIDR (Classless Inter-Domain Routing) – kompaktiškas būdas aprašyti IP bloką, pvz. 192.168.1.0/24. Vietoje to, kad vardintume kiekvieną adresą, nurodome tinklo pradžią ir prefikso ilgį (/24), kuris apibrėžia, kiek adresų patenka į tą bloką.

Praktinė šio sprendimo nauda užpuolikui: jis gali rodyti kenkėjišką turinį tik realiems Google servisams, o bet kokiam „rankiniam tikrinimui“ (naršyklėje, per paprastą curl, per daugumą monitoring’ų) – švarią svetainę. Dar viena detalė – skriptas turėjo solidų IPv6 palaikymą, kurio senesni cloaking pavyzdžiai dažnai neturi.

Ką tai daro tavo svetainei: ne tiek „hack“, kiek SEO reputacijos sabotažas

Tokios infekcijos tikslas dažniausiai nėra tiesiogiai užkrėsti lankytojų įrenginius. Pagrindinis smūgis – paieškos rezultatams ir domeno reputacijai, nes Google indeksuoja turinį, kurio realūs žmonės nemato.

• Deindeksavimas arba dalinis išmetimas iš paieškos (kai Google pamato spam / doorway turinį).
• Blacklisting / reputacijos signalai, kurie vėliau atsiliepia visam projektui.
• Resursų „hijacking“ – svetainės autoritetas naudojamas svetimam turiniui kelti.
• Vėluojantis aptikimas: savininkas naršo ir nemato problemos, todėl incidentas tęsiasi ilgiau.

Tipiniai požymiai, kad tai vyksta (net jei frontas atrodo „švarus“)

• Keisti arba prasti Google rezultatai (netikėti title/description, „spammy“ raktiniai žodžiai, nepažįstami URL).
• Neseniai modifikuoti core failai (ypač index.php).
• Įtartini išoriniai URL ar domenai, kurie atsiranda kode arba loguose.
• Netikėti įrašai serverio loguose, ypač susiję su crawl’eriais ir redirect’ais.

Kaip veikia „vartininkas“ index.php faile: 5 sluoksnių logika

Užkrėstas index.php įgyvendina sąlyginę logiką, kurią patogu mąstyti kaip kelis patikros sluoksnius.

1) Daugiasluoksnė identiteto patikra (User-Agent + IP)

Pirmiausia tikrinamas HTTP_USER_AGENT (naršyklės/kliento identifikatorius, siunčiamas su kiekviena HTTP užklausa). Kadangi jį suklastoti paprasta, po to vyksta IP validacija pagal Google tinklų diapazonus.

2) IP tikrinimas bitinėmis operacijomis (bitwise)

Čia ir prasideda „rimtesnė“ dalis: vietoje paprasto palyginimo, ar IP patenka į diapazoną, naudojamos bitinės operacijos su netmask’u. IPv4 logika iš esmės remiasi tokia lygybe (pateikiama kaip principas):

// Principas: IP priklausomybė tinklui tikrinama per bitwise AND su netmask
// (konkretus kenkėjiško kodo įgyvendinimas gali skirtis)
if ( ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal) ) {
    // IP patenka į CIDR bloką
}

// Principas: IP priklausomybė tinklui tikrinama per bitwise AND su netmask
// (konkretus kenkėjiško kodo įgyvendinimas gali skirtis)
if ( ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal) ) {
    // IP patenka į CIDR bloką
}

3) Nuotolinio payload’o atsiuntimas per cURL

Kai lankytojas patvirtinamas kaip „legit“ botas, skriptas per cURL atsisiunčia turinį iš išorinio URL ir jį tiesiogiai atspausdina atsakyme. Paieškos robotui atrodo, kad turinys yra svetainės dalis.

// Idėja: patvirtintam botui fetch’inamas nuotolinis turinys
// Šaltinis tyrime: hxxps://amp-samaresmanor[.]pages[.]dev
// ir turinys grąžinamas tiesiai kaip puslapio HTML.

// Idėja: patvirtintam botui fetch’inamas nuotolinis turinys
// Šaltinis tyrime: hxxps://amp-samaresmanor[.]pages[.]dev
// ir turinys grąžinamas tiesiai kaip puslapio HTML.

4) Platus User-Agent sąrašas (ne tik „Googlebot“)

Filtravimas apėmė ne vien „Googlebot“. Įtraukiami ir kiti Google įrankiai: svetainės verifikavimo, inspekcijos, API crawler’iai – kad paslėptas turinys būtų matomas kuo daugiau Google ekosistemos komponentų.

5) Sprendimų logika + klaidų logavimas

Galutinis modulis sujungia dvi patikras (User-Agent ir IP) ir elgiasi skirtingai priklausomai nuo rezultato. Buvo matyti ir klaidų apdorojimas bei logavimas – tai leidžia užpuolikui stebėti, ar schema veikia.

• Jei botas „tikras“: pateikiamas nuotolinis turinys; jei nepavyksta jo užkrauti, botas nukreipiamas į /home/, kad Google nematytų „broken“ puslapio.
• Jei botas „netikras“ (User-Agent suklastotas, bet IP nepraeina): fiksuojama klaida („Fake GoogleBot detected“) ir nukreipiama į normalų puslapį.
• Jei paprastas lankytojas: iškart rodomas įprastas turinys (arba redirect į įprastą home).

Kodėl būtent WordPress core failai yra patogus taikinys

Tokio tipo injekcija index.php faile ypač efektyvi, nes tai vienas pirmųjų vykdomų taškų. Be to, kenkėjiškas kodas gali „užsikabinti“ už WordPress įkėlimo mechanizmo, pasikviesdamas core failus.

• wp-load.php: kvietimas per require_once __DIR__ . '/wp-load.php' užkrauna WordPress aplinką (konfigūraciją, DB prisijungimą ir pan.), todėl skriptas gali veikti „su visais patogumais“.
• wp-blog-header.php: tipinis index.php pabaigoje naudojamas failas, kuris užbaigia įprastą WordPress puslapio generavimą. Tai leidžia kenkėjui išlaikyti normalų svetainės veikimą žmonėms.

Ką daryti incidento metu: praktiniai žingsniai (be magijos)

1. Izoliuok pakeitimus: patikrink, ar core failai (ypač index.php) nebuvo modifikuoti. Jei turi deployment’ą per Git – palyginimas labai greitas.
2. Pašalink nepažįstamus failus ir katalogus: viskas, ko neįdiegėte jūs ar komanda, yra įtartina, ypač jei atsirado neseniai.
3. Peržiūrėk vartotojus WordPress’e: pašalink „pagalbos“ paskyras ir įtartinus administratorius.
4. Atnaujink kredencialus: WP admin, FTP/SFTP, hosting, DB slaptažodžius (ir, jei aktualu, raktus).
5. Patikrink savo kompiuterį: pilnas antivirus/malware scan – dažna priežastis yra nutekėję prisijungimai.
6. Atnaujink viską: WordPress core, temas, plugin’us; ypač svarbu atsikratyti senų ar apleistų komponentų.
7. Apsvarstyk WAF (Web Application Firewall): WAF gali padėti blokuoti komunikaciją su žinomais C2/payload šaltiniais ir sumažinti pakartotinio įkėlimo riziką.