[Linuxtrent] Re: Rivelati i dettagli del problema nel protocollo DNS

  • From: "Marco Cova" <marco.cova@xxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Wed, 20 Aug 2008 09:56:03 -0700

On Wed, Aug 20, 2008 at 7:14 AM, Roberto Resoli
<roberto.resoli@xxxxxxxxx> wrote:
> Non credo se ne sia parlato in lista, ma credo si tratti di un
> problema di sicurezza notevole.

L'attacco di Kaminsky e` davvero potente. Per capirci, se avete server
non patchati, andate a patcharli adesso...

In pratica, l'attacco permette in maniera estremamente efficiente di
fare cache poisoning, cioe` di inserire nella cache di un server DNS
associazioni tra nomi di dominio e indirizzi IP del tutto arbitrari,
e.g., linuxtrent.it e l'indirizzo di una macchina sotto il mio
controllo.

Per capire come funziona l'attacco, breve overview su DNS. Quando
voglio visitare il sito del linuxtrent, il browser deve risolvere il
nome www.linuxtrent.it, ovvero
1. Il browser chiede al mio DNS server qual e` l'IP corrispondente a
www.linuxtrent.it.
2. Ragionevolmente, il mio DNS server non sa qual e` la risposta.
Allora, usando la struttura gerarchica del DNS, il mio server
identifica che il DNS server responsabile per il dominio linuxtrent.it
e` dns1.dnshosting.it.
3. Il mio server ripete la query per www.linuxtrent.it a
dns1.dnshosting.it, ottiene la risposta 89.190.170.228, e la salva
nella cache, cosi` che la prossima volta che richiedo
www.linuxtrent.it, mi puo` rispondere velocemente.

L'attacco e` sostanzialmente una race durante l'ultimo passo di questo
processo. La race classica funziona cosi`.  L'attaccante manda una
richiesta per linuxtrent.it al mio server DNS (la vittima) e cerca di
battere sul tempo il DNS server legittimo (dns1.dnshosting.it). Cioe`,
finge di essere dns1.dsnhosting.it e manda una risposta che associa
www.linuxtrent.it a, per esempio, 6.6.6.6. Perche` la risposta sia
accettata dal mio server DNS, alcune condizioni devono essere
soddisfatte, in particolare:
1. Il mio server non deve conoscere la risposta, cioe`,
www.linuxtrent.it non deve essere nella cache
2. Deve sembrare che la risposta venga da dns1.dnshosting.it (facile:
IP spoofing su pacchetti UDP)
3. La risposta deve arrivare alla porta usata dal server DNS (16 bit,
di solito prevedibile)
4. la risposta deve contenere nel campo query ID (16 bit) un valore
che e` stato scelto in maniera random dal server (2^16 possibilita`:
fattibile)
Il problema e` la condizione 1. Se l'attaccante perde la prima race,
il server accetta la risposta legittima e la salva nella propria
cache. La cache rimane valida per un tempo specificato dal campo TTL
della risposta. Valori tipici sono alcuni giorni. In altre parole, se
l'attaccante perde la prima race (probabile), deve aspettare giorni
prima di poter riprovare l'attacco.

Semplificando un po', l'attacco di Kaminsky supera questo problema
usando 2 trucchi.
1. Anziche` richiedere linuxtrent.it, l'attaccante chiede di risolvere
un sottodominio random di linuxtrent.it, per esempio,
aaaa.linuxtrent.it. Se perde la race, chiede aaab.linuxtrent.it e
cosi` via. Ciascun sottodominio e` diverso e verosimilmente non e`
nella cache del server: la condizione 1 non e` piu` un problema.
Quando finalmente vince una race, sembrerebbe che l'attaccante possa
controllare solo un sottodominio random, per esempio,
aaac.linuxtrent.it, il che non e` troppo utile. E qui entra in gioco
il secondo trucco.
2. Insieme alla risposta per aaac.linuxtrent.it, l'attaccante fornisce
anche un "glue record" (nella "additional section" della risposta). Il
glue record dice che "linuxtrent.it" corrisponde all'indirizzo
6.6.6.6. Il mio server DNS accetta anche il glue record lo aggiunge
alla cache. L'attaccante vince...

Ci sono un paio di moduli di metasploit che implementano l'attacco. I
tempi riportati perche` l'attacco abbia successo usando questi moduli
sono sull'ordine di qualche secondo (7 era il numero magico, se ben
ricordo).

La patch rende piu` difficile la condizione 3: il server DNS adesso
usa source port number random. L'attaccante deve indovinare non piu`
solo i 16 bit del query ID, ma anche il port number. In tutto, poco
meno di 32 bit: meno facile...

Paul Vixie (autore di bind) era a USENIX Security qualche settimana fa
e aveva un paio di slide sul perche` la patch non gli piaccia
(problemi con firewall, NAT, soluzione statistica), ma sia la
soluzione miglio nel breve periodo. Curiosamente djbdns randomizza da
sempre (o da parecchio tempo) il source port number e quindi non e`
vulnerabile.
In generale, credo che ci sara` un po' di ricerca in questo campo nel
futuro prossimo, per cui mi aspetto novita` interessanti (sia sul lato
attacco che difesa). Per esempio, il trucco 0x20 di David Dagon.

Le slide della presentazione che Kaminsky ha fatto a BlackHat sono
disponibili qui:
http://www.doxpara.com/DMK_BO2K8.ppt
La seconda parte della talk e` particolarmente interessante, perche`
discute parecchi scenari di come l'attacco al DNS puo` essere
sfruttato per fare altri attacchi (e.g., ridirigere email, phishing).

Marco
-- 
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts: