Pubblicati on line per errore i dettagli sulle ultime vulnerabilità Dsn rilevate.
I buoi sono ormai scappati dalla stalla. Questa la traduzione dell’incipit di un’analisi pubblicata questa mattina sul blog di Matasano Security, poi frettolosamente eliminata, che riguardava la vulnerabilità dei DNS portata alla luce da Dan Kaminsky. La scheda tecnica era stata posta online in risposta alle argomentazioni rese, sul suo blog personale, da un ricercatore esperto in tecniche di “reverse engineering”.
Thomas Ptacek, responsabile di Matasano Security, ha voluto precisare come la pubblicazione dei dettagli sulla vulnerabilità sia avvenuta per errore. Poiché la scoperta è particolarmente seria, l’autore della stessa aveva infatti invitato a non divulgare dettagli in modo tale non semplificare la vita ai malintenzionati che volessero sfruttare la lacuna di sicurezza.
Per qualche ora, il documento di Masatano Security è rimasto online, consultabile anche ricorrendo alla cache di Google.
Il codice che nei servizi DNS traduce un indirizzo mnemonico (ad esempio, www.google.it) nel corrispondente indirizzo IP è chiamato “resolver”. Ogni volta che il resolver contatta il server DNS per tradurre nomi in indirizzi numerici, esso crea un pacchetto detto “query”. Lo scambio di questi pacchetti è denominato “transazione”. Affinché tali informazioni non si confondano con altre, durante una qualunque comunicazione in Rete, è necessario utilizzare delle “etichette” che permettano di riconoscerli e trattarli in modo adeguato.
Un semplice esempio aiuta a comprendere il meccanismo. Supponiamo che Alice si rechi ad una pizzeria da asporto per ordinare un calzone. Per prima cosa, Alice ritira un numero dall’apposito distributore ed attende il suo turno. Il numero stampato sul suo ticket sarà chiamato due volte: la prima all’atto dell’ordine, la seconda nel momento in cui il suo calzone sarà pronto”.
I “transaction ID” vengono utilizzati in modo molto simile: essi vengono impiegati, infatti, per mantenere l’ordine di diverse transazioni. I primi sedici bit di un pacchetto DNS contengono un identificatore univoco (query id; QID).
Le vulnerabilità che affliggono i servizi DNS possono essere suddivise, essenzialmente, in due classi.
Supponiamo che Bob sia un resolver mentre Alice un “content DNS server”. Bob richiede ad Alice quale sia l’indirizzo IP corrispondente all’indirizzo www.nomedelsitobersagliato.it. Ipotizziamo che Mallory, il malintenzionato (Bob, Alice e Mallory sono i nomi generalmente utilizzati in letteratura per identificare utenti benevoli ed “aggressori”; ved. questa pagina), voglia fare in modo che l’utente – digitando www.nomedelsitobersagliato.it nella barra del suo browser – venga indirizzato su un server “maligno” anziché su quello legittimo. Poiché Mallory non può leggere il QID presente nella richiesta DNS di Bob, egli non può semplicemente falsificare la risposta perché il QID inserito non corrisponderebbe a quello usato nella transazione.
Mallory potrebbe però comunque riuscire nell’intento inviando, in modo costante, un flusso di dati contenenti risposte DNS per l’indirizzo www.nomedelsitobersagliato.it. Se i dati prodotti da Mallory arrivano al computer dell’utente prima di quelli legittimi, provenienti dal server DNS del provider, il browser verrà indirizzato sul sito web maligno.
E’ ovvio che una generazione dei QID che avvenga in modo davvero casuale, consentirà di ridurre drasticamente i rischi di attacco. Sedici bit, inoltre, non forniscono un livello di sicurezza adeguato, al giorno d’oggi.
Nel caso in cui l’aggressore Mallory riesca ad “avvelenare” la cache DNS di un qualsiasi server, tutti gli utenti che invieranno successivamente richieste otterrebbero risposte falsificate (corrispondenze errate tra indirizzo mnemonico ed indirizzo IP).
Un altro meccanismo sfruttabile per sferrare attacchi consiste nella modifica dei “resource records” (RR), informazioni memorizzate nell’intestazione dai pacchetti dati usati nei servizi DNS ed, in particolare, nell’aggiunta di RR “maligni”.
Il dettaglio delle piattaforme ritenute vulnerabili, è pubblicato ed aggiornato dallo US-CERT a questo indirizzo. Tutti gli amministratori di rete sono invitati ad applicare tempestivamente le patch di sicurezza rilasciate dai vari produttori.
