Come fare un attacco hacker e posizionare keyword competitive? In questo articolo non vogliamo incitare ad utilizzare tecniche scorrette, ma analizzeremo come l’attacco di un sito, sfruttando la vulnerabilità del server attraverso una backdoor, ha posizionato su Google pagine ottimizzate con chiavi competitive.

All’inizio del maggio scorso il team che si occupa di PHP ha rilasciato prima una patch, risultata poi non funzionante, ed in seguito un aggiornamento del linguaggio di scripting (versioni 5.4.3 e 5.3.13) per una pericolosa vulnerabilità che permette ai malintenzionati l’esecuzione di codice remoto o l’installazione di una backdoor.

La vulnerabilità riguarda solo i server configurati in modalità CGI, ne sono immuni quelli che usano FastCGI e mod_php5 ed è stata scoperta durante una sfida tra esperti alla conferenza internazionale di sicurezza Nullcon del 2011. Pubblicata per errore sul web, mentre si cercava una soluzione ne ha fatto le spese soprattutto Dreamhost, importante hosting provider americano
che ha subito oltre 234 mila tentativi di intrusione di cui 151 mila sono andati a segno.

Aspetto interessante del codice utilizzato per l’attacco è la creazione, una volta installata la backdoor, di un file .htaccess con cui l’aggressore cerca di impedire ad altri di sfruttare la stessa vulnerabilità, abbastanza inutilmente a mio avviso perchè gli host già compromessi sono facilmente individuabili anche con Google utilizzando delle stringhe univoche presenti nel codice.

Quello che ci ha resi particolarmente curiosi in merito a questa vicenda è la notifica ricevuta dal Webmaster Tools di Google con cui ci avvisava di un presunto attacco hacker ricevuto dal sito di un B&B, dove alcune pagine potrebbero essere modificate o compromesse da una terza parte, pertanto ha aggiunto la dicitura “Questo sito potrebbe essere compromesso” alle SERP in cui viene visualizzato.

Dal grafico del traffico con le impressioni ed i clic per le query più frequenti si nota subito l’impressionante picco arrivato a 75 mila, prima di tornare ai soliti valori che si aggirano intorno alle 900 impressioni al giorno, quando presumibilmente il contenuto ritenuto pericoloso ed estraneo al sito è stato rimosso dagli indici del motore di ricerca.

La maggior parte di queste impressioni arrivava dalla ricerca per immagini, con parole chiavi relative a clipart ed
immagini gif di diverso genere, utilizzate anche nella ricerca web.

Effettuando accertamenti per identificare il problema e rimuovere eventuali contenuti dannosi, abbiamo trovato all’interno dello spazio web, in diverse sottodirectory, proprio i file generati dalla backdoor di cui parlavo, che probabilmente ha sfruttato la vulnerabilità presente anche nella versione di php sul server del sito, che non è ancora stato aggiornato dall’hosting provider.

All’interno di una directory chiamata images/ 99 file php richiamavano fedelmente in ogni sua parte il template di un blog personale su wordpress.com, certamente scelto a caso tra i tanti, mentre il contenuto di ogni pagina era costituito da un title ottimizzato per le chiavi scelte, le stesse ripetute più volte ed immagini richiamate dai siti originari, in genere tra i primi risultati su Google Images proprio in quelle SERP, molte delle quali da domini popolari come flickr.com, blogspot.com, photobucket.com, etc.
Le pagine non erano linkate tra loro ed apparentemente non presentavano alcun vantaggio, nè per quanto riguarda
link esterni inseriti all’interno del contenuto nè per banner pubblicitari presenti, entrambi completamente assenti. Tutte comunque salvavano in due diversi file di testo, che fosse presente un referer o meno, le visite generate con i dati relativi all’ip del visitatore, data ed orario della visita, il browser utilizzato ed altre informazioni ottenibili tramite la variabile predefinita di php $_SERVER. Eppure si erano posizionate abbastanza bene generando un discreto volume di traffico e di clic.
Una ricerca più attenta ai nomi dei file ha permesso di scoprire migliaia di domini e relativi siti web, tutti ospitati su diversi server dello stesso hosting del nostro B&B, che presentavano lo stesso problema, differendo però per la scelta del template e per i link presenti nel footer alle pagine degli altri siti compromessi dalla vulnerabilità. Anche in questo caso niente link per favorire nelle SERP un eventuale sito esterno a quelli violati nè altro apparente vantaggio dall’operazione.

Nel nostro caso il contenuto aggiunto a quello originario era completamente fuori tema, in una lingua diversa, e forse proprio per questo non ha presentato un grave problema, ma è abbastanza verosimile che un aggressore avrebbe potuto sfruttare questa vulnerabilità per inserire contenuto tematizzato con il nostro sito web ma duplicato, di pessima qualità e con link esterni a risorse negative, al fine di penalizzarci pesantemente proprio per le keyword di nostro interesse. Senza considerare inoltre l’eventualità di contenuti illeciti e vietati dalla legge.

Nonostante non disponessimo dei log di accesso del server web ed ftp, l’incursione dell’intruso non è rimasta completamente anonima, perchè ha lasciato, abbastanza maldestramente, traccia del suo ip russo già conosciuto ai log di mezzo mondo informatico nel tema frettolosamente copiato da wordpress.com e nel file che registrava le visite alle pagine, proprio come primo visitatore per assicurarsi che il suo “lavoro” funzionasse.

Questo attacco non ha causato perdite di posizioni per le chiavi legate all’attività del B&B, ma ha comunque diminuito la % di CTR in SERP a causa dell’avviso di Google nello snippet.

Dopo aver ripulito il sito dalle pagine estranee al sito, aver modificato le password FTP e del DataBase, abbiamo chiesto la riconsiderazione del sito attraverso il form di Google Webmaster Tools.