È di pochi giorni fa la notizia che i dati di circa 19.000 carte di credito relative a utenti britannici che avevano effettuato acquisti online fossero disponibili su Google.
Tramite il noto motore di ricerca, chiunque avrebbe potuto accedere ai nomi e agli indirizzi di migliaia di clienti Visa, Mastercard e American Express nonché ai dati completi delle loro carte di credito.
Si ritiene che i criminali, dopo aver collezionato quell’enorme mole di dati probabilmente da diverse fonti al momento ignote, stessero cercando di rivenderle sul mercato nero; in particolare è sotto accusa un forum vietnamita usato da diversi gruppi di cybercriminali.
Benché il sito fosse stato chiuso a febbraio, le informazioni postate su di esso erano state indicizzate da Google e risultavano disponibili tramite la sua funzione di cache anche a forum chiuso.
BigG ora conferma di aver rimosso tutti i dati riservati.
In linea con questo sconcertante furto di dati riservati vi è uno studio della Symantec di pochi mesi fa in cui si stima a 5 miliardi di dollari la quantità di denaro a cui i criminali informatici hanno potuto avere accesso tramite furti di carte di credito online.
In particolare, i dati delle carte di credito rubate rappresentano circa il 30% degli scambi di beni sul mercato nero informatico. Un altro 20% è rappresentato dalle credenziali di accesso a conti bancari online.
La notizia di apertura mi permette di parlare di un tema che trovo piuttosto interessante, rilevante e affascinante: il Google Hacking.
È sotto gli occhi di tutti la potenza di uno strumento come Google, ma, per citare Peter Parker, “a un grande potere corrisponde una grande responsabilità”. Fin dove è in grado di spingersi il potere del motore di ricerca di Mountain View? Cosa implica un suo abuso?
Data la sua incredibile capacità di indicizzazione, Google è in grado anche di raccogliere dati che molti vorrebbero restassero ben segreti. Un malintenzionato non deve fare altro che fargli la domanda giusta e migliaia di informazioni confidenziali saranno a sua disposizione.
Era il 2003 quando Johnny Long pubblicò per la prima volta il Google Hacking Database (GHDB), ormai diventato parte integrante di numerosi tools per il security testing. Il progetto mirava, e mira ancora, a collezionare tutte le possibili query di ricerca che è possibile effettuare tramite Google e il cui risultato abbia rilevanza sul piano della sicurezza informatica.
Il tema ha avuto talmente successo che Long ha anche pubblicato un libro, intitolato “Google Hacking for Penetration Testers”, di cui è stata rilasciata poco più di un anno fa la seconda edizione.
Un anno fa circa è entrato anche in gioco lo storico gruppo hacker Cult of the Dead Cow che ha rilasciato uno specifico tool per il Google hacking su Windows, Goolag.
Mi piacerebbe fare qualche esempio della potenza e della semplicità di certe query, ma non amo l’idea di mettere a repentaglio dati riservati (malamente custoditi) di chi che sia.
Vediamo qualche esempio non troppo devastante, giusto per dare un’idea.
Parecchi anni fa, ormai, era stata scoperta una grave vulnerabilità per Apache su Windows (1.2.x – 1.3.24) che, se sfruttata correttamente, poteva portare alla totale compromissione del server; un attaccante potrebbe usare Google per localizzare centinaia o migliaia di server potenzialmente vulnerabili da attaccare, ecco un semplice esempio:
“Apache/1.3.19 Server at” intitle:index.of
Un bersaglio interessante per un malintenzionato sono i file di configurazione dei software che spesso contengono dati riservati. Non dovrebbero assolutamente esposti su Internet senza un’adeguata difesa. Ecco un esempio:
filetype:conf OR filetype:config OR filetype:cfg
Questa semplice query non fa altro che restituire i link a generici file di configurazione liberamente visionabili da chiunque.
Se un attaccante conosce il nome esatto di un file di configurazione di uno specifico software, può facilmente creare una query che faccia debitamente uso degli operatori filetype e inurl che ricerchi tale file.
Altri esempi di dati riservati che è possibile trovare tramite Google sono i dump testuali di un database (o l’archivio del database per intero), le password delle applicazioni e dei servizi più disparati, numeri di carta di credito (come abbiamo visto all’inizio), file di log e di backup critici, pannelli di amministrazione di router, firewall, switch, non protetti (o con password di default, che è come non averla), hardware in rete (stampanti e Web cam di mezzo mondo, per esempio) e messaggi di errore di vario genere, utili per ricavare informazioni su un’applicazione, magari vulnerabile.
Applicare queste tecniche di attacco sul proprio sito Web può essere utile per verificare che non si esponga niente di rilevante a chi non sia autorizzato.
Spero di avervi dato un’idea del lato oscuro di Google e della sua potenza. Avrei voluto impressionarvi e spaventarvi di più per far maturare una significativa presa di coscienza di questo serio problema che può comportare incidenti a dir poco spiacevoli.
Per gli amministratori di Web server proteggersi da questi attacchi è importante e l’adozione di adeguate security policy è d’obbligo. Anche l’uso di robots.txt può aiutare ad impedire che i bot dei vari motori di ricerca non indicizzino certe parti di un sito. Ma non fidatevi troppo, anche perché chiunque può poi usare quello stesso file per individuare velocemente directory critiche (spesso non adeguatamente protette).
