Non tutti gli attacchi a WordPress sono rumorosi. Alcuni aggressori non vogliono deturpare il tuo sito né tenerlo in ostaggio. Vogliono dirottare in silenzio l’autorità di ricerca del tuo dominio e usarla per posizionare i propri contenuti su Google. Questi attacchi si chiamano attacchi di cloaking SEO e sono tra le compromissioni più dannose che un sito aziendale possa subire, perché spesso il proprietario non sa nemmeno che stanno avvenendo.
Questo articolo illustra esattamente come funziona un vero attacco di cloaking SEO, usando un recente caso di studio di un’agenzia di Sydney in cui ogni file e ogni dispatcher è stato identificato durante un audit forense. Se gestisci un sito WordPress, ciò che segue è lo schema che dovresti saper riconoscere.
Cosa significa cloaking
Il cloaking è la pratica di servire ai motori di ricerca contenuti diversi da quelli mostrati ai visitatori umani. Una pagina potrebbe mostrare a Googlebot un lungo articolo pieno di parole chiave su temi commerciali non correlati, mentre a un visitatore normale mostra una landing page generica o un reindirizzamento. L’obiettivo è ingannare i motori di ricerca affinché posizionino il contenuto occultato sotto l’autorità di un dominio consolidato.
Google ha regole contro tutto questo. Il cloaking viola le linee guida per i webmaster e può costare a un dominio penalizzazioni per azioni manuali o un crollo completo del posizionamento, se rilevato. All’aggressore non importa, perché il dominio non è suo.
Lo schema delle cinque cartelle
Il caso di Sydney usava una versione particolarmente pulita dell’attacco. L’aggressore aveva creato cinque nuove cartelle nella radice del sito, ciascuna nominata per rispecchiare una vera pagina WordPress. Sul disco comparivano cartelle con nomi come about, contact, good-to-know, services e work. Ognuna conteneva esattamente tre file. Un dispatcher index.php. Un file HTML user.php. Un file HTML wp-log.php.
Il motivo di nominare le cartelle come pagine reali era semplice. Quando arrivava una richiesta a /about/ sul sito, il web server controllava prima il file system. Esisteva una cartella chiamata about, con un index.php al suo interno. Il web server risolveva quel file prima che entrasse in gioco il routing degli URL di WordPress. Ogni richiesta a quegli URL colpiva il codice dell’aggressore anziché la pagina WordPress legittima.
Il dispatcher
Il file index.php in ogni cartella era un minuscolo pezzo di PHP che faceva una sola cosa. Ispezionava l’header HTTP User-Agent della richiesta in arrivo e instradava di conseguenza. Se lo User-Agent conteneva Googlebot, Googlebot-Mobile o Googlebot-News, serviva il contenuto di wp-log.php. Altrimenti includeva user.php e usciva.
Lo stesso file era distribuito su tutte e cinque le cartelle, identico byte per byte. L’aggressore usava un solo payload e una sola regola decisionale. Tutto il resto erano dati.
Il payload per Googlebot
I file wp-log.php, nonostante l’estensione .php, contenevano puro HTML. Erano enormi, da circa 1,3 MB a oltre 4 MB. Ognuno era una pagina HTML completa in una lingua straniera, in questo caso indonesiano, con contenuti spam su gioco d’azzardo, e-commerce e tracciamento di prodotti Samsung. Le pagine erano infarcite di dati strutturati, script di tracciamento di terze parti incorporati e link progettati per superare in posizionamento i contenuti legittimi per le parole chiave prese di mira.
Perché chiamarlo wp-log.php? Mimetizzazione. Per un proprietario che dà un’occhiata all’elenco dei file, sembra un file di log di WordPress, non un payload sospetto.
Il payload per gli umani
I file user.php erano pagine HTML più piccole servite ai veri visitatori umani. Erano doorway page provenienti da siti di terze parti non correlati, anch’esse mascherate con un’estensione .php pur non contenendo alcun codice PHP. Chiunque arrivasse a uno di quegli URL da un risultato di ricerca, o navigasse verso /about/ sul sito, vedeva contenuti che non avevano nulla a che fare con l’agenzia.
Questa è la parte del cloaking. Google vede lo spam sul gioco d’azzardo nel contenuto di wp-log.php, lo posiziona sotto l’autorità di dominio dell’agenzia e invia gli utenti reali a user.php, che offre un’esperienza doorway completamente diversa. L’inganno funziona in entrambe le direzioni.
Come è entrato l’aggressore
L’audit forense non è riuscito a individuare l’esatto vettore d’ingresso dai dati disponibili, ma il sospettato più probabile era un plugin di gestione file obsoleto, ancora installato e attivo. La famiglia di plugin in questione ha una lunga storia di vulnerabilità di esecuzione di codice remoto, con numerosi avvisi pubblicati negli anni passati. Con accesso in scrittura tramite quel plugin, un aggressore può depositare file arbitrari ovunque nella radice del documento.
Fondamentale: l’audit ha confermato che il core di WordPress, wp-config.php, il database e il tema attivo erano tutti puliti. Nessuna backdoor nell’applicazione, nessun utente amministratore fraudolento, nessun eval PHP offuscato. La compromissione era interamente in quelle cinque cartelle. È questo che la rendeva così silenziosa. La maggior parte degli scanner di sicurezza esamina i file di WordPress, non la radice del documento alla ricerca di directory inattese.
Perché questo tipo di attacco è così dannoso
Gli attacchi di cloaking SEO fanno male in tre modi. Primo, il contenuto spam viene indicizzato sotto il tuo dominio, spingendo le tue pagine reali più in basso o fuori dai risultati di ricerca. Secondo, Google può applicare penalizzazioni per azioni manuali o un declassamento algoritmico quando rileva il cloaking, dal quale spesso servono settimane o mesi per riprendersi anche dopo la rimozione dei file dannosi. Terzo, gli script di terze parti e i pixel di tracciamento incorporati nelle pagine spam possono esporre i tuoi visitatori a malware o phishing.
Il proprietario di un sito soggetto a cloaking spesso non si accorge di nulla finché il traffico non crolla o un cliente non menziona di aver visto contenuti strani cliccando su un risultato di ricerca. A quel punto, settimane o mesi di danni sono già stati fatti.
Come rilevarlo sul tuo sito
Poche verifiche rapide intercetteranno la maggior parte delle varianti di questo attacco. Visita la tua home page come utente normale. Poi esegui una richiesta curl da un server con un header User-Agent di Googlebot e confronta. Se vedi contenuti diversi, qualcosa non va.
Controlla i report Copertura e Prestazioni in Google Search Console per URL indicizzati che non riconosci, soprattutto quelli con query in lingua straniera. Esamina la radice del documento via SFTP alla ricerca di cartelle o file che non sai spiegare. Esegui una scansione malware completa con un plugin di sicurezza affidabile e leggi il report anziché limitarti a cancellare gli avvisi.
Come prevenirlo
La prevenzione è lo stesso insieme di abitudini che previene la maggior parte delle compromissioni di WordPress. Mantieni aggiornati core, temi, plugin e PHP. Rimuovi i plugin che non usi attivamente, soprattutto i gestori di file e gli strumenti di accesso shell. Blocca l’esecuzione di PHP nelle directory che non dovrebbero mai contenere PHP. Fai un audit della radice del documento ogni mese. Usa un plugin di sicurezza che monitori la comparsa di nuovi file in posizioni inattese e avvisi quando ne appare uno.
Hai bisogno di una mano?
Se temi che il tuo sito WordPress possa ospitare contenuti occultati a tua insaputa, Smart Coding può eseguire un audit forense e dirti esattamente cosa c’è sul tuo server. Se vuoi un partner che si assicuri che il tuo dominio si posizioni solo per ciò che deve, contatta il team di Defyn.
