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