Per danni possibili e ampiezza dei dispositivi e dei software coinvolti, la vulnerabilità del sistema DNS venuta alla luce ad inizio luglio è una delle più pericolose mai comparse su Internet. Ad essere coinvolto, e non è la prima volta, è il sistema DNS, ossia il servizio che, gestito da sistemi operativi, strumenti hardware, software, provvede a convertire un indirizzo Web nel corrispondente indirizzo internet numerico. Il DNS è una delle componenti fondamentali dell'infrastruttura della rete: senza di essa non potremmo navigare, né mandare e-mail, né usare nessun servizio Web.
I pericoli causati da una manomissione del servizio DNS sono diversi, tutti comunque riconducibili ad uno scenario comune: il rindirizzamento di una richiesta verso un altro server. In questo caso è possibile che, ad esempio, digitando il nome della nostra banca veniamo indirizzati ad un sito Web che non corrisponde a quello originale; è possibile che connettendoci ad un servizi di chat vengano visualizzati falsi utenti nella propria lista dei contatti; è possibile che inviando una mail questa vada a finire nella casella di posta del pirata informatico che ha manomesso il servizio e non in quella del destinatario.
Al momento di scrittura di questo articolo sono circa 90 i produttori software o hardware probabilmente vulnerabili inclusi nella lista preparata dallo US-Cert. Molti di loro, come Microsoft, varie distribuzioni Linux, FreeBSD, hanno già pubblicato delle patch correttive. Altri, tra cui Apple, non lo hanno ancora fatto. Da fine luglio è anche disponibile un exploit funzionante in grado di rendere automatica lo sfruttamento della vulnerabilità.
I Servizi DNS
Per capire la vulnerabilità è in primo luogo necessario capire come funziona il DNS. L'acronimo DNS (Domain Name System) indica il protocollo, ossia il set di istruzioni condivise, con cui comunicano i name server e i resolver. I name server sono i software, e per estensione anche i computer, che si occupano di sostituire i numeri ai nomi: sono coloro che traducono il nome www.google.it che digitiamo sul browser nell'indirizzo IP 209.85.135.104 comprensibile dalle macchine. Ogni provider, ma è facile trovarli anche in reti aziendali o grandi server farm, ha il suo name server. I name server sono strutturati ad albero: per semplificare basti dire che all'apice vi sono quelli che appartengono alle zone più "generali" e, scendendo verso i rami più bassi, quelli più specifici per dominio.
Quando digitiamo sul browser www.google.it, il client DNS che è incluso nel nostro Pc (chiamato resolver) chiede al name server del nostro provider l'indirizzo IP di quel particolare dominio. Il nostro provider, se non conosce l'indirizzo, esegue una cosiddetta ricerca ricorsiva: chiede al name server autorevole l'indirizzo di quel determinato dominio, il name server autorevole indica in quale altro name server si trova quell'informazione, il nostro provider invia la richiesta a quest'altro name server, recupera l'indirizzo IP e lo restituisce al nostro sistema operativo che a sua volta lo rende disponibile al browser. La procedura è ricorsiva perché, in base all'indirizzo digitato, può prevedere due, tre o molti altri passaggi. Nella figura qui sotto è visualizzato graficamente il processo:
Un sistema di questo genera garantisce l'accuratezza dei risultati ma non la velocità. Ecco perché ogni client o server DNS, compreso quello del computer e ad esclusione di quelli autorevoli, include un sistema di cache: memorizza le richieste già eseguite per renderle disponibili più velocemente agli altri computer che le dovessero richiedere. Se un pirata potesse includere nella cache risultati artefatti, sarebbe semplice rindirizzare le richieste legittime verso qualsiasi altro sito. Ed è quello che è accaduto con la vulnerabilità citata all'inizio dell'articolo.
DNS Cache poisoning
Poisoning significa "avvelenare". Il DNS cache poisoning è un tipo di attacco informatico, conosciuto nei principi generali da molto tempo, che "avvelena" la cache di un Name server scrivendo su di essa informazioni inesatte. La vulnerabilità scoperta da Dan Kaminsky lo scorso luglio, resa nota nei termini principali ad inizio luglio e poi pubblicata sul Web nei dettagli alla fine del mese, consente appunto di includere nella cache dei name server degli indirizzi illegittimi programmati per far circolare finti siti Web.
La vulnerabilità si introduce nel processo di richiesta ricorsiva e forza un name server ad accettare delle risposte non da un altro name server legittimo, ma da un utente illegittimo. Poniamo che Andrea stia cercando l'indirizzo IP di www.html.it e che il name server del provider (chiamiamolo DNS-01) che interroga non la abbia in cache. DNS-01 esegue una ricerca ricorsiva interrogando prima il name server autorevole per il dominio .it e via via gli altri che lo possono aiutare a trovare l'indirizzo. Se l'aggressore riuscisse a inviare a DNS-01 una risposta fingendosi un server autorevole riuscirebbe a includergli nella cache l'indirizzo errato.
Il metodo per ottenere ciò è, almeno a parole, molto semplice. Ogni richiesta (in protocollo UDP) di DNS-01 al name server autorevole viene fatta infatti precedere da una sorta di codice di identificazione causale (query ID) che il name server autorevole accetta e invia assieme alla risposta. Se a DNS-01 arrivano risposte con il codice sbagliato vorrà dire che non saranno inviate dal name server autorevole e saranno scartate. In questo scenario per il pirata ci sono due inconvenienti: indovinare il codice di identificazione è molto difficile; la richiesta, una volta ricevuta e considerata attendibile da DNS-01, viene messa in cache e non sarà più possibile modificarla per diverso tempo.
Il bug scoperto da Kaminsky consente di superare la seconda difficoltà e rendere più semplice l'intero processo. Per cercare di modificare l'IP di www.html.it si procede con l'eseguire centinaia di richieste ai domini fittizi www1.html.it, www2.html.it e così via in modo da moltiplicare le richieste e ampliare all'infinito la possibilità di individuare la query ID di una transazione.
Ma, è questo il punto, se l'attacco riuscisse ad individuare la query id per la richiesta di, poniamo, www345.html.it, solo quel dominio sarà falsificato, ma non lo sarà www.html.it, il dominio principale. Qui interviene la scoperta di Kaminsky: ogni record DNS contiene anche una sezione chiamata "ADDITIONAL SECTION" che può contenere alcune informazioni addizionali per rendere più efficace la richiesta. Nel messaggio pubblicato qui sotto (eseguito con Dig per Windows) vediamo che la sezione indica gli indirizzi IP dei name server di it.net che altrimenti rimarrebbero sconosciuti a chi esegue la richiesta.
C:dig>dig @dns.it.net www.html.it ; <<>> DiG 9.3.2 <<>> @dns.it.net www.html.it ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.html.it. IN A ;; ANSWER SECTION: www.html.it. 86400 IN A 151.1.244.200 ;; AUTHORITY SECTION: html.it. 86400 IN NS dns.it.net. html.it. 86400 IN NS dns2.it.net. ;; ADDITIONAL SECTION: dns.it.net. 300 IN A 151.1.1.1 dns2.it.net. 300 IN A 151.1.2.1 ;; Query time: 37 msec ;; SERVER: 151.1.1.1#53(151.1.1.1) ;; WHEN: Tue Jul 29 14:22:43 2008 ;; MSG SIZE rcvd: 120
La "ADDITIONAL SECTION" può essere modificata nella finta risposta inviata dal pirata. Poniamo che l'aggressore, dopo decine di prove, abbia trovato la query ID e dunque il modo di fingersi autorevole per il dominio www345.html.it. Nella risposta che invierà al name server includerà anche un'additional section modificata così
;; ADDITIONAL SECTION: dns.it.net. 300 IN A 151.1.1.1 dns2.it.net. 300 IN A 151.1.2.1 www.html.it. 86400 IN A 192.168.0.1
Il name server, poiché il dominio www.html.it si trova nella stessa "area di influenza" (bailiwick) di www345.html.it, accetterà questa informazione addizionale e la includerà all'interno della sua cache. Tutte le richieste che giungono a quel name server per il dominio www.html.it saranno rindirizzate all'IP 192.168.0.1.
Soluzioni
Al momento in cui scriviamo i maggiori produttori di software hanno divulgato le patch per i propri sistemi. Microsoft, varie distribuzioni Linux, Cisco e altri produttori vulnerabili all'attacco hanno reso disponibili attraverso i propri canali tradizionali le correzioni per il bug. Tra i grandi manca solo Apple, i cui sistemi sono da considerare vulnerabili all'attacco di Kaminsky.
Per correggere il problema, almeno fino a quando non saranno disponibili maggiori dettagli del problema, è sufficiente rendere causali le port UDP utilizzate dal resolver DNS per inviare le richieste al name server autorevole. Per verificare se il DNS utilizzato dal proprio computer è vulnerabile basta collegarsi all'indirizzo Web www.doxpara.com (il sito di Dan Kaminsky) ed utilizzare il DNS Checker visualizzato sul menu di destra.
