No results found
Google è il motore di ricerca oggi più utilizzato e offre una quantità notevole di funzionalità, tuttavia il grosso del pubblico lo utilizza solamente per effettuare la ricerca di base e quasi mai si spinge oltre. In particolare, Google dimostra di essere un ottimo alleato di esperti in sicurezza informatica, hacker e anche semplici “smanettoni” in generale.
Il motivo che rende possibile effettuare una qualsiasi ricerca con Google è la capacità di Web Crawling, ossia la capacità di indicizzare ogni elemento (file, cartelle e quant’altro) che si trovi all’interno di ogni sito web; in verità non tutti gli elementi e non tutti i siti web possono essere indicizzati da Google, ma questo comunque è un discorso che esula dagli scopi di questo webinar.
Consideriamo che comunque, a meno di particolari impedimenti all’interno di un certo sito web, Google effettua il processo di crawling, cioè va praticamente a indagare tutto ciò che è contenuto all'interno (che viene ospitato) di un certo sito web, così che possa avere una visione chiara di quello che poi dovrà restituire all’utente quando andrà ad effettuare una ricerca.
Quindi per processo di crowling si intende esattamente una sorta di enumerazione di file, cartelle ed altro, perché non è detto che ci stiamo riferendo solo al protocollo http, ma ci potremmo riferire anche al protocollo FTP..
Questa capacità di indicizzare gli elementi, che in linea generale è un pregio, in realtà può rivelarsi pericolosa, almeno in determinate circostanze. In questo tutorial verrà spiegato perché, con particolare riferimento a quello che è conosciuto come Google Dorking.
Per comprendere cosa può accadere se il crawling avviene in maniera indiscriminata pensiamo a tutte quelle informazioni sensibili che vengono sottoposte al processo di “crawling” e successivamente divulgate come esito della ricerca su Google; informazioni quali tecnologie web utilizzate, username, password, indirizzi mail, ecc…
Quello che accade nel processo di crawling non è volontario, cioè la rivelazione di informazioni che non dovrebbero essere rilevate non è dolosa, ma frutto di un’errata configurazione, ovvero di una costruzione dei siti web fatta senza considerare cosa accade nwel processo di crawling.
Ciò perché Google trova una certa difficoltà nel capire con esattezza l’intenzione del webmaster che ha divulgato certe informazioni, cioè se Google non riceve delle indicazioni particolari sotto forma di linee di codice in cui gli viene detto di non indicizzare una certa pagina o un determinato contenuto, Google lo fa e lo fa in maniera neutrale, ossia senza secondi fini.
Questa indicizzazione indiscriminata può creare dei problemi, soprattutto se sfruttata da malintenzionati. Esiste una pratica che consiste nello sfruttare impropriamente il processo di crawling e che prende il nome di Google Dorking; è chiaramente una pratica scorretta, specie quando viene esercitata in maniera fraudolenta.
La pratica di sfruttare il processo di “crawling” a fini malevoli, ossia il Google Dorking, si concretizza nelle Google Dorks, le quali non sono altro che le query (interrogazioni al motore di ricerca) create con l’obiettivo di estrapolare/rilevare dati sensibili e/o debolezze all’interno di uno o più siti web. In realtà tali query non si chiamano Google Dorks, ma tale nome è stato coniato quando si è capito che si poteva sfruttare Google per questo uso alternativo e qualcuno sul web ha iniziato a sfruttare tali interrogazioni, a catalogarle, a diffondere i dati ottenuti: da quel momento tali interrogazioni hanno preso il nome Google Dorks.
Va detto che Google “non vede troppo di buon occhio” tali tecniche di interrogazione del suo motore di ricerca e pertanto applica delle contromisure; infatti ci può capitare, dopo aver effettuato un certo numero di queste query particolari, che sono interrogazioni un po’ differenti da quelle che Google si aspetta, di trovarsi di fronte a strumenti che lo stesso Google presenterà per assicurarsi che non stiamo utilizzando strumenti automatici di interrogazione:i cosiddetti “robot”. Questo proseguimento condizionale della navigazione è una strategia di difesa attuata dal motore di ricerca quando rileva del “traffico inusuale”.
Dopo aver effettuato un certo numero di “Dorks”, Google ci presenterà un “captcha” così da assicurarsi che non stiamo utilizzando strumenti automatici di interrogazione (immagine seguente).
Questo perché esistono strumenti automatici che cercano di sfruttare tali interrogazioni, ovvero di eseguirle automaticamente e in maniera automatica, gestire i dati ottenuti in risposta.
Nell’immagine possiamo leggere l’avviso che ci dice che i sistemi hanno rilevato traffico inusuale proveniente dal computer che lo visualizza e questa è l’indicazione che Google può vedere le ricerche, ossia può conoscere l’indirizzo IP di provenienza (l’indirizzo IP pubblico su cui ci esponiamo all'esterno) e quindi ha la possibilità anche di farci apparire questo messaggio che ci mette in preallerta se sta succedendo qualcosa di poco chiaro.
Ovvio che queste interrogazioni Google Dork sono delle query che normalmente non andiamo a fare: Google sa benissimo quali sono le ricerche che normalmente vengono fatte dagli utenti e queste si può capire benissimo che non sono quelle comuni.
Le “Google Dorks” possono essere piuttosto complesse e sfruttano il linguaggio “built-in” di Google, quindi si usa il linguaggio interno di Google per effettuare le interrogazioni.
Quindi la loro creazione non è semplice, tuttavia utilizzando particolari operatori di ricerca (ossia i Google Advanced Search Operators) si possono ottenere già degli ottimi risultati senza dover scrivere codice apposta.
Infatti le Google Dorks in un certo senso vanno nello specifico, ovvero per eseguire le relative query è necessario innanzitutto conoscere l’obiettivo delle interrogazioni e poi le tecnologie e i linguaggi di programmazione utilizzati da Google. Questo complica le cose.
Invece i Google Advanced Search Operators (ossia operatori avanzati di ricerca Google) semplificano il lavoro perché sostanzialmente sono delle keyword che si vanno a inserire in una certa ricerca e che riescono ad aumentare il raggio d’azione delle interrogazioni effettuabili; il tutto è preconfezionato.
Vediamo dunque alcuni di questi Google Advanced Search Operators.
Un’ottima risorsa che riepiloga 42 operatori di ricerca avanzati in uso da Google è reperibile all’indirizzo Internet https://ahrefs.com/blog/google-advanced-search-operators/.
Qui potete trovare molti operatori utili, alcuni dei quali magari poco utilizzati ma utili anche nella SEO (Search Engine Optimization) ad esempio per ottenere informazioni su quali e quanti siti web utilizzano determinate keyword. Ricordiamo che la SEO nasce con lo scopo di strutturare un certo sito in modo da farlo collocare ai primi posti dei risultati della ricerca di Google; nel marketing questo elemento è essenziale per la visibilità di un prodotto o servizio offerto.
Ma gli operatori possono essere utilizzati anche nell’ambito della sicurezza informatica, allo scopo di eseguire delle ricerche particolari.
Vediamo dunque alcuni di questi operatori, uno dei quali è:
“search term”
In pratica se mettiamo un certo termine tra virgolette nella casella di ricerca, forziamo Google ad eseguire solo ricerche che combaciano perfettamente con il termine o i termini introdotti; tale operatore è utile per dirimere dubbi derivanti da risultati di ricerca ambigui o sinonimi. Serve quindi per escludere termini non strettamente correlati alla ricerca fatta, che spesso vengono suggeriti da Google e che possono risultare fuorvianti, dilungando infruttuosamente la ricerca.
Esistono poi operatori logici come l’OR e l’AND, che consentono di fare una ricerca in alternativa tra due termini (nel secondo caso) o di uno solo o di entrambi i termini (nel primo).
Molto interessante è l’operatore Exclude, che consente di effettuare una ricerca specificando quale termine o frase escludere da essa; per esempio:
jobs -apple
permette di ricercare tutte le pagine che parlano di jobs ma non quelle di Apple (inteso come azienda).
Vediamo ora alcuni operatori particolarmente utili a partire da cache, che restituisce la più recente versione di cache di Google di una pagina web, ovvero la pagina web visitata da Google l’ultima volta.
esempio: cache:apple.com
Altro operatore interessante è filetype, che permette di restringere i risultati di una ricerca a certi tipi di file, quindi PDF, DOCX, TXT, PPT, e via di seguito. Analogo risultato si ottiene con l’operatore ext.
La relativa sintassi è del tipo:
nomesito filetype estensione, quindi, ad esempio, coretech.it filetype pdf
Un altro operatore di ricerca è site, che restituisce come risultato della ricerca solo un certo sito web e non semplicemente le pagine che ne contengono il nome; la relativa sintassi è:
site:nomesito.xxx e quindi, ad esempio, site.coretech.it
escludendo prefissi come www, http ecc.
Altro operatore interessante è related, che restituisce come risultato della ricerca tutte le pagine appoggiate al dominio specificato, secondo la sintassi
related:coretech.it
Vediamo ora l’utilizzo dell’operatore intitle cui abbiamo accennato in prededenza, il quale trova le pagine contenenti una determinata parola (o parole) all’interno del titolo; per esempio se utilizziamo:
intitle:security
otteniamo come risultato tutte le pagine che hanno security come tag del titolo, a prescindere dal nome del sito stesso
Molto simile a questo operatore è allintitle, che ha la stessa sintassi ma restituisce come risultati della ricerca solo le pagine contenenti tutte le parole specificate nel title tag, quindi consente di specificare più parole e di visualizzare tra i risultati solo ile pagine web che le contengono tutte.
Utilissimo è anche inurl, che funziona similmente a intitle, ma la ricerca correlata la fa negli URL delle pagine e non nel titolo; per esempio:
allinurl:coretech
cerca tutte le pagine che hanno coretech nell’URL.
Simile è allurl, che va a estrarre come risultati solo quelli che contengono tutte le parole scritte dopo il comando, vale a dire dopo allurl.
Adesso entriamo nel concetto di Google Hacking Database e lo facciamo riferendoci e utilizzando quella che può essere considerata la più autorevole fonte di informazioni per quanto riguarda il Google Dorking: il Google Hacking Database, accessibile alla pagina web https://www.exploit-db.com/google-hacking-database.
Si tratta di una raccolta costantemente aggiornata di tutte le Google Dorks più efficaci e utilizzate dagli utenti del web e viene mantenuto dal team di Offensive Security. L’immagine seguente propone la pagina corrispondente.
Questa raccolta viene aggiornata facendo un’analisi di quelle che sono le richieste “particolari” inviate a Google, anche in considerazione delle nuove tecnologie e dei tool che quasi giornalmente motivano la creazione di nuove query. Non a caso è molto nutrita e conta alcune centinaia di pagine, con qualche migliaio di quey; il numero esatto, continuamente aggiornato, può essere consultato in fondo a ciascuna pagina, dove viene indicato qualcosa del genere:
Showing 1 to 15 of 5,168 entries
i cui il primo intervallo è il numero delle queri mostrate nella pagina attuale e la cifra finale è il totale delle Google Dorks disponibili.
Per ciascuna query è possibile il download (con il pulsante a freccia in basso) ed anche l’integrazione in Metasploit, dal momento che alla fine le Google Dorks sono sostanzialmente degli exploit e si può anche automatizzarne l’esecuzione.
Il Google Hacking Database è suddiviso per categoria e ciascuna categoria è relativa all’obiettivo di ricerca che si intende raggiungere. Di seguito riportiamo l’elenco di queste categorie
Come vedete, riguardano la richiesta di dati che in certi casi sono sensibili ed anche delicati, che chiaramente il webmaster può fare in modo di mostrare o meno.
Andiamo a descrivere ed esemplificare queste categorie di Google Dorks, partendo da Footholds., che tradotto significa “appiglio o scorciatoia; questa interrogazione non mira a una specifica vulnerabilià ma restituisce dati utili.
Un esempio è https://www.exploit-db.com/ghdb/5279 che corrisponde al Dork:
inurl:/phpmyadmin/index.php?db=
phpmyadmin authenticated panel
ManhNho
e che restituisce il pannello “phpmyadmin” autenticato. In pratica con questo tipo di interrogazione si vanno a cercare tutti i pannelli phpmyadmin che sono autenticati, ovvero a identificare questi portali. Chiaramente questa interrogazione espone a dei rischi le pagine web corrispondenti, perché di fatto permette a chi la esegue di sapere dove può accedere senza dover conoscere le credenziali.
Notare che in questo caso si utilizza l’operatore inurl già descritto, passando come parametri di ricerca dei termini avanzati, specifici di una certa tecnologia, che insieme costituiscono la Google Dork.
Andiamo ad esaminare questa categoria di Google Dorks, la quale permette di avere come risultato della ricerca i file contenenti degli username: anche in questo caso si va alla ricerca di dati sensibili perché si può avere una lista di contenuti di un certo sito che mostrano dei nomi utente e con essi si possono anche eseguire operazioni non autorizzate.
Un esempio di questa Google Dork è:
https://www.exploit-db.com/ghdb/4858.
Username.xlsx ext:xslx
la quale restituisce i file Excel che contengono degli username trovati nel web.
Notare che qui si utilizza l’operatore filetype, che permette di specificare l’estensione dei file che si desidera ottenere come esito della ricerca.
Restando nella categoria Files Containing Usernames, possiamo fare un altro esempio:
filetype:log username putty
che restituisce i file di log di PuTTY (un emulatore di terminale utilizzabile per accedere tramite protollo SSH o altro) che contengono quindi username, parametri di connessione, numero porta, ecc. e quindi dati abbastanza sensibili. Infatti i file di log di PuTTY contengono gli username e i parametri di connessione come il numero di porta.
Anche qui, un utilizzo non proprio ortodosso potrebbe essere piuttosto dannoso. Notare che qui si utilizza l’operatore filetype, che permette di specificare l’estensione dei file che si desidera ottenere come esito della ricerca.
La ricerca può essere più mirata, abbinando ad esempio l’operatore site per cercare di vedere se i dati di interesse sono esposti in un determinato sito o dominio, fermo restando quanto accennato poco fa riguardo alla delicatezza di certe ricerche. Un utilizzo “lecito” e utile potrebbe essere quello mirato a eseguire un Penetration Test finalizzato alla verifica e ottimizzazione della sicurezza di un certo sito o dominio.
Questa Dork permette di cercare cartelle indicizzate che possono contenere dati e informazioni ritenute sensibili; per esempio:
intitle:"Index of" secret
restituisce come risultato della ricerca le cartelle che hanno come nome “secret”; tale keyword è stata presa cvome parametro perché teoricamente richiama qualcosa il cui contenuto non dovrebbe essere divulgato perché riservato. Si può chiaramente eseguire una serie di ricerche passando come parametro dei termini differenti, che normalmente possono contraddistinguere documenti riservati: nel Google Hacking Database ne vengono proposti parecchi, come ad esempio “confidential” e via di seguito (ci sono circa 300 termini utilizzabili che utilizzano svariati operatori).
Altro esempio di Sensitive Directories è questo.
site:* index of: *.exe
che restituisce le cartelle di siti o domini contenenti dei file eseguibili (.exe) e che spesso fornisce pagine FTP.
Passiamo adesso a una Google Dork che permette di andare alla ricerca di un tipo specifico di Web Server che è quello basato su Apache; un esempio e il seguente:
site:*/server-status intext:"Apache server status for"
che restituisce pagine web che contengono informazioni utili relative al web server Apache.
Nello specifico è possibile ottenere informazioni su Apache anche abbastanza dettagliate; naturalmente per eseguire anche questa interrogazione bisogna conoscere gli operatori site e intext, che vedete utilizzati, che permettono di indicare le pagine server-status (tutte, perché utilizziamo il wildcard *) nella ricerca e includere il contenuto Apache server status for.
Se proviamo a eseguire questa ricerca avanzata otteniamo una lista, aprendo un risultato della quale ci si trova di fronte a qualcosa tipo quanto mostrato nell’immagine seguente:
Qui abbiamo tutte le informazioni che possono essere utili per capire la versione di Apache in esecuzione, quali sono le diciamo eventuali librerie installate e tante altre informazioni utili.
Ovviamente la ricerca può essere fatta per altri tipi di Web Server: basta cambiare il parametro Apache server status for nella stringa e mettere quello corrispondente al tipo di Web Server da cercare.
Andiamo avanti e affrontiamo la categoria vulnerable files, la quale riguarda ricerche mirate a trovare file vulnerabili. Per esempio la Google Dork:
filetype:cgi inurl:cachemgr.cgi
permette di andare alla ricerca di siti che espongono un’interfaccia di gestione cui possiamo accedere e che in certe condizioni può essere utilizzata per attacchi Denial Of Service (DOS). Tale interfaccia è quella passata come parametro dell’operatore inurl ossia cachemgr.cgi, la quale è un’interfaccia di gestione per il proxy “Squid”.
Questo server proxy, in certe condizioni può essere utilizzato per attacchi di tipo DOS; ovviamente non tutte le interfacce di gestione del proxy Squid, ma devono verificarsi certe condizioni che adesso non andremo indagare.
Nella categoria vulnerable server si colloca la Google Dork che consente ri estrarre come risultato della ricerca un elenco dei web server con multiple remote Command execution vulnerability in Apache Strut.
Quindi quando lanciamo l’interrogazione del tipo:
inurl:"struts" filetype:action
otteniamo un elenco di web server con “Multiple Remote Command Execution Vulnerabilities in Apache Struts" e quindi andiamo a cercare questo tipo di vulnerabilità. Anche qui ce ne sono veramente decine disponibili, in base a quello che vogliamo ottenere.
Andiamo avanti e arriviamo alla Google Dork Error Message, che ci fornisce un elenco di tutti i messaggi di errore, i quali possono fornire delle informazioni molto utili a un attaccante perché ci fanno comprendere qualcosa del contesto su cui stiamo facendo delle indagini
Per esempio questa interrogazione:
site:*/404/404.html intitle:"404"
restituisce come risultato della ricerca un elenco pagine web dove è stato riscontrato il noto errore di tipo “404”, ossia “pagina non trovata” e tutta la relativa categoria.
Letteralmente “file contenenti informazioni sostanziose” e utili per un eventuale attaccante. Una Google Dorks che contente di ottenere informazioni del genere è ad esempio:
site:*/logs/error.log
che restituisce come risultato della ricerca l’elenco dei file di log che contengono errori di varia natura; */ logs/error.log è la destinazione in cui solitamente si possono trovare i file di log che contengono gli errori rilevati. Il fatto di esaminare gli errori fornisce notevoli informazioni.
Procediamo ancora e analizziamo la categoria file containing password: qui si fa uso dell’operatore intext e si costruisce la relativa Google Dork passando come parametro password e l’operatore inurl usando come parametro file/ext.txt per indicare che la ricerca riguarderà file di testo. Per esempio:
intext:"@gmail.com" intext:"password" inurl:/files/ ext:txt
restituisce un elenco dei file che contengono password relative ad account di posta GMAIL, infatti viene utilizzato il suffisso@gmail.com e siamo interessati nello specifico a rilevare a trovare le password di questi account di posta.
In questa categoria rientrano dati sensibili relative a un certo a un sistema che gestisce un e-commerce e che sortisce l’effetto di avere una lista di dati relativi agli utenti; può essere utile nella fase di debug di un sito di e-commerce per verificare che non sia soggetto a fughe di dati sensibili ed anche essere utilizzato a fini poco leciti da attaccanti esterni che intendono carpire I dati dei clienti, ad esempio per farsi un data-base finalizzato alla concorrenza sleale e ad altro ancora.
Un esempio di Google Dork è:
"More Info about MetaCart Free"
che nello specifico riguarda la versione demo di MetaCart (un software per creare siti di e-commerce) la quale contiene una nota vulnerabilità che permette di accedere al database degli utenti, rivelando dati sensibili. In questo caso la Dork è sostanzialmente una stringa di keyword.
Se lanciamo tale query andiamo a cercare tutti quei siti che utilizzano questo plugin, così da poter indagare sulla relativa vulnerabilità e scoprire come come funziona, così da agire di conseguenza.
Per quanto riguarda la ricerca delle vulnerabilità di rete, è prevista una Google Dork lanciando la quale accediamo alla dashboard di un sistema di monitoraggio di architetture di rete
Scrivendo questa stringa nella casella di ricerca di Google
intitle:Host Report inurl:ganglia
nei risultati troviamo il link che permette l’accesso alla dashboard di Ganglia, un tool di monitoraggio di architetture di rete.
Passiamo alla categoria Page Containing Login Portal, che riguarda le query dirette ad ottenere un elenco delle pagine che contengono una pagina di Login ad un portale.
Per esempio la Google Dork seguente:
site:moodle.*.*/login/
andiamo alla pagina di “Login” della piattaforma di e-learning Moodle.
Se andiamo a eseguire la query, si ottengono vari risultati, però pur essendoci vari domini (la query infatti riporta i caratteri *), tutti riportano praticamente alla pagina di login di questo portale, dove inserire username e password.
Potremmo comunque mettere un altro portale a scelta e il risultato sarebbe analogo.
In questa categoria rientrano tutte quelle interrogazioni che ci fanno atterrare sulla Dashboard e in generale sull’interfaccia di gestione di qualche dispositivo; in questo caso facciamo riferimento a un router e la query, ovvero la Google Dork è la seguente
intext:" Welcome to DSL-2730B Web Management"
Questo ci fa atterrare sull’interfaccia di gestione del router modello DSL-2730B, ovvero otteniamo, come primo risultato della ricerca, una pagina web che si riferisce al router D-Link indicato.
Con un comando del genere, un potenziale attaccante potrebbe tentare un attacco di tipo Brute Force su questa interfaccia di management.
Volendo possiamo ripetere la query andando a cambiare modello.
Esistono, sul web, sistemi automatici che permettono di automatizzare l’operazione di query relativa alle Google Dorks; uno di questi è Google Diggity ed è praticamente un sito che contiene un pacchetto di tool dedicati ciascuno a una funzionalità: vi sono strumenti per portare attacchi (ATTACK TOOLS) o per difendersi dagli attacchi (DEFENSE TOOLS) e via di seguito, come mostrato nell’immagine seguente.
Una volta scelto strumento lo dobbiamo scaricare e poi installarlo, seguendo il processo d’installazione per la piattaforma target (per esempio Windows) e poi possiamo utilizzarlo.
Quando lo avviamo, appare la finestra di lavoro del tool: quella proposta nell’immagine seguente riguarda l’ATTACK TOOL
Come potete notare, l’interfaccia è divisa in tab che ci permettono di specificare anche il motore di ricerca sul quale operare: vediamo, ad esempio, Google, CodeSearch, Bing e Shodan (motore di ricerca per dispositivi connessi). Sempre dalle tab possiamo scegliere altre funzionalità.
Nella sezione di sinistra abbiamo le tab Simple e Advanced: nella prima possiamo scegliere una delle query proposte e nella seconda andare a comporre query specifiche.
Nell’area centrale troviamo il pulsante SCAN, quindi la sezione dove definire le opzioni di scansione (immagine seguente); possiamo anche andare a cercare particolari chiavi oppure particolari file. Insomma, questo strumento permette di fare in maniera più rapida e comoda tutto ciò che dovremmo effettuare manualmente.
Nell’area in basso, che riporta le tab Output e Selected Result, si possono risualizzare i risultati delle query e i dettagli dei risultati selezionati nel riquadro centrale.
L’immagine seguente propone o dello strumento Search in Flash, relativamente a query che richiedono account utente e relative credenziali.
Infine, lo screenshot proposto nell’immagine seguente riporta l’utilizzo relativamente al portale Bing, in una scansione che utilizza query finalizzate alla funzionalità di IP Address Reverse Lockup.
Va notato che Google con molta probabilità tenderà a bloccare questo strumento, quindi magari lo lascia lavorare se si vanno a eseguire poche query molto mirate, ma se proviamo a lanciare 1.000 interrogazioni in dieci secondi Google bloccherà immediatamente con un captcha e quindi lo strumento automatico non riuscirà a procedere, in quanto il captcha è un sistema per bloccare i robot e studiato per attendere una risposta “organica”.
