Sicurezza  »  Articoli  »  Tecniche di sicurezza 

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.

Figura 4: Una richiesta "avvelenata"

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.

Altri articoli

Altre guide

Altre newsletter