Nell’articolo riproposto si parla di un metodo per reperire informazioni da un qualsiasi server DNS in modo perfettamente legittimo. Gli autori dell’articolo originale avevano usato questo sistema per capire quanto fosse diffuso un rootkit inserito da una nota multinazionale nei suoi prodotti. Naturalmente non si parla soltanto di usi pacifici.

Vagando per la Rete in un sabato sera, mi sono imbattuto in un articolo che, parlando del famigerato sistema di protezione dei CD audio costato ad una nota multinazionale milioni di Euro e migliaia di cause per danni, citava un articolo di un ricercatore dal titolo DNS Cache Snooping.

Sotto un titolo abbastanza innocuo, ho trovato un elenco di tecniche di interrogazione dei server DNS che permette di accedere indirettamente ad informazioni preziose in modo assolutamente legale.

In breve, l’idea è questa: ogni server DNS ha due possibilità di rispondere ad una richiesta di risoluzione di un nome in un indirizzo IP.

Se riceve una richiesta per il suo dominio, risponde direttamente, visto che è lui stesso il gestore. Se riceve richieste per altri domini, controlla la sua cache per vedere se ha i dati necessari, altrimenti chiede a sua volta al server DNS che gestisce il dominio a cui appartiene il nome da risolvere. Nel momento in cui riceve una risposta, ne mantiene una copia in cache per un tempo massimo (il TTL). Se arriva una seconda richiesta prima che scada il TTL, il DNS risponde con il dati che ha in cache.

Ovviamente, questo comportamento è diretto a mantenere basso il traffico di richieste DNS, ed a rendere più efficienti e veloci le risposte dei server.

Ma, come sempre, tutto può essere usato per scopi perversi.

Usando normali strumenti di analisi e di debug per le richieste DNS, come ad esempio dig, si può interrogare un server DNS e imporgli di rispondere consultando solo la propria cache. Il risultato è che se il server non ha dati nella propria cache per rispondere, ritorna con l’indirizzo dei server DNS che hanno certamente la risposta o con i root servers, cioè i server di livello più altro di tutta la gerarchia della Rete.

E allora? Vuol dire che posso sapere se qualcuno ha usato quel server DNS per cercare un particolare sito, semplicemente guardando nella sua cache dall’esterno.

Se pensate che non sia un problema, devo deludervi. Riporto brevemente alcuni degli scenari esposti nell’articolo.

Il marketing dei refusi

Una particolare tecnica di marketing in Rete è quella di registrare nomi di dominio molto simili a quelli più noti. Un esempio: provate a digitare www.hotmial.com (notare la ‘i’ e la ‘a’ invertite) e vi trovate davanti uno pseudo motore di ricerca. Viene chiamato il marketing dei refusi (in inglese il termine è molto più colorito: typosquatters).

Il problema è capire quali siano i refusi più frequenti. In questo caso, la cache dei server DNS è una vera miniera di informazioni, dato che anche i nomi inesistenti vengono inseriti in cache, per poter rispondere immediatamente senza inoltrare richieste ad altri DNS server. Si selezionano alcuni nomi di dominio promettenti e si indaga interrogando un po’ di server in giro per il mondo. Il nome che viene cercato più spesso diventa il candidato per la registrazione.

Alice parla con Bob

E’ possibile sapere se due società si scambiano mail? Pare di sì, e senza compiere azioni illegali. Ricordiamo che i dati in cache hanno una scadenza, per cui in media ogni ventiquattro ore i dati vengono cancellati. Ma se due persone in due differenti società si scambiano posta elettronica, ad ogni invio di posta nella cache del DNS di Alice saranno depositati i dati del server di posta di Bob. E quando Bob risponde, sul suo server DNS vi saranno i dati del mail exchanger di Alice. Non possiamo sapere chi scrive, ma possiamo sapere che c’è scambio di corrispondenza.

Tana!

Ossia, trovare in che punto del globo si trova una persona connessa in Rete, senza conoscere il suo indirizzo IP, ovviamente. Basta indurla a visitare un sito inesistente, con un nome unico. Abbiamo da tre a ventiquattro ore per scoprire il DNS server nella cui cache esiste la traccia della query fallita. Tanto è il tempo per cui di solito viene mantenuto nella cache il record di un nome di dominio inesistente. A questo punto basta indagare (con whois ad esempio) in quale nazione si trova il DNS in questione.

Torniamo agli IP?

Questo succede perché di solito i DNS di una azienda rispondono alle query indipendentemente da dove arrivano. Ovviamente devono rispondere alle query che arrivano dall’esterno per pubblicare i nomi di dominio che devono essere visibili all’esterno (ad esempio il server web e il mail exchanger), e contemporaneamente fornire il servizio DNS agli utenti interni. Per far questo devono avere la cache delle query, e non è possibile discriminare a livello di query se deve rispondere o no, ossia permettere risposte dalla cache solo agli utenti interni.

Per avere un comportamento sicuro i server DNS andrebbero organizzati in due entità distinte, una autoritativa per rispondere alle query esterne ed interne riguardanti il dominio di appartenenza, ed una di caching per le query generiche, a disposizione solo degli utenti interni. In questo modo il server “esposto” alla Rete non avrebbe una cache da spiare.

Chi è interessato a dettagli più tecnici, può leggere direttamente l’articolo, certamente molto più ricco di informazioni di questo breve sunto.

Oggi invece

Le tecniche spiegate qui non hanno nulla a che fare con il recente annuncio di alcuni problemi riguardanti proprio i DNS. I metodi esposti non sfruttano falle o bug nei software, ma semplicemente alcune funzioni proprie del protocollo, niente di più.

Non occorre essere comportarsi da pirati per fare cose molto speciali.