DNS Cache Poisoning Explained

Pescara, 22/08/2008

MOCA 2008

Ivan Giacomelli

DNS Cache Poisoning Explained


Ivan GiacomelliMOCA 2008 Pescara, 22/08/2008 2

Cover della presentazione

Domain Name System – Analisi e dettagli implementativi

DNS Cache Poisoning – Internals & Exploiting

Pescara, 22/08/2008

MOCA 2008

Ivan Giacomelli




# whoami

IT Security Researcher / Security Software Developer@ Emaze Networks S.p.A.

http://www.emaze.net

IT Security Analyst / Penetration TesterSecurity Operation Center – Finance & Top Clients@ Telecom Italia S.p.A.

http://www.telecomitalia.it



Security Operation Center

“Un Security Operation Center (SOC) è un centro che eroga servizi di sicurezza informatica, implementa processi, procedure per la

prevenzione e gestione degli incidenti. Il compito dell’infrastruttura è la gestione preventiva del rischio il che significa centralizzare e

analizzare tutte le attività di sicurezza informatica sfruttando l’insieme delle risorse umane, hardware e software dedicate alla gestione del

sistema di sicurezza.”

Fonte: http://it.wikipedia.org/wiki/Security_Operation_Center



Domain Name SystemCos’e’?

• Protocollo per la risoluzione di nomi host in indirizzi IP e viceversa

• Realizzato tramite un database distribuito costituito dai server DNS

• Nasce in seguito all’esigenza di associare un indirizzo IP ad un nome testuale di facile memorizzazione per l’uomo

• Ha un vantaggio. E’ flessibile:– Gestione centralizzata delle associazioni IP / nome testuale.– Possibilita’ di assegnare piu’ nomi ad uno stesso IP– Bilanciamento carico di lavoro su piu’ IP



Domain Name SystemTerminologia

• Zona : gruppo di associazioni IP / nome.

• Authoritative Nameserver : server master di una zona.

• Resolver : DNS client.

• Recursive Nameserver : DNS server con risoluzione ricorsiva delle zone per il quale non e’ Authoritative Server.

• Resource Record : A, CNAME, NS, MX, TXT, SOA.

• Delegation : delega ad un altro DNS Server per la risoluzione di un nome non disponibile sul DNS server da noi interrogato.



Domain Name SystemCome funziona una query DNS

Quando un sistema collegato in rete ha la necessita’ di contattarne un altro, invia una query contenente la richiesta al suo server DNS, attendendo una risposta contenente l’indirizzo IP corrispondente al nome da lui richiesto.




I casi sono 2:

• Il nostro server DNS ha gia’ in cache la corrispondenza e ce la fornisce senza dover cercarla lui stesso.

• La risposta non e’ nella cache e il server DNS parte alla ricerca della risposta che deve fornire.

Per primo viene contattato un Root Server.




Il root server non conosce la risposta alla nostra domanda, ma sa indirizzarci a qualcuno che puo’ darci informazioni maggiori.

A questo punto la richiesta viene effettuata nuovamente al DNS server indicatoci dal root server.

I server che conoscono I domini di 1 livello sono I GTLD nameserver.




Il GTLD nameserver sa indirizzarci verso in nameserver autoritativo per il dominio che mi interessa.

Questo nameserver autoritativo mi sa fornire la giusta associazione.

Oltre alla coppia IP/nome puo’ fornirmi anche informazioni aggiuntive, posto che appartengano allo stesso dominio (bailiwicked check).



Domain Name SystemAnalisi del pacchetto

Campi importanti per la nostra disquisizione:

• Source IP Address

• Destination IP Address

• Source Port

• Destination Port

• Query ID (a.k.a Transaction ID a.k.a TXID)



Domain Name SystemIl pacchetto UDP che contiene la query

Altri campi contenuti nel pacchetto:

• QR (Query/Response): 0 query / 1 response• Opcode: settato dal client a 0 per una query standard• AA (Authoritative Answer): 0 non autoritativa / 1 autoritativa• TC (Truncated): settata a 1 in una risposta se il contenuto supera i 512 byte limite di un pacchetto UDP. In caso e’ necessaria una richiesta in TCP• RD (Recursion Desired): 1 se si desidera la ricorsione / 0 altrimenti• RA (Recursion Available): 1 se la ricorsione e’ disponibile / 0 altrimenti• Z: flag riservato. Deve essere 0.• RCODE (Response Code): indica esito positivo o negativo. Settato dal server.• Question Record Count: quasi sempre 1. Sia nelle richieste che nelle risposte.• Answer/authority/additional record count: settate dal server. Contengono varie informazioni riguardanti la risposta che viene data al client. Vedremo fra un po’ il dettaglio.• DNS Question/Answer data: Area contenente la domanda effettiva e la risposta effettiva.



Domain Name SystemResource Records

Descrizione

A Associazione nome testuale / indirizzo IP

NS Server DNS responsabile per il dominio richiesto

MX Mail Exchanger responsabile per il delivery della posta nel dominio

SOA Informazioni sulle zone (contatti amministrativi, ecc.)

TXT Utilizzato da alcune applicazioni (es. SPF - Sender Policy Framework). Informazioni descrittive generiche riguardo il dominio.

CNAME Alias. Nome alternativo di una risorsa.



Domain Name SystemResource Records

Esistono molti altri tipi di Resource Records.Per ulteriori approfondimenti:

http://www.dns.net/dnsrd/rr.html



Domain Name SystemAnalisi di una query DNS

Richiesta dal mio nameserver verso il GTLD nameserver.




Risposta dal GTLD nameserver verso il nameserver del mio ISP.




Richiesta dal nameserver del mio ISP verso l’authoritative server del dominio di mio interesse.




Risposta dall’authoritative nameserver contenente le informazioni che mi servono.

Nella risposta sono contenute informazioni aggiuntive. I ‘glue-records’.



Domain Name SystemQuali risposte devo accettare?

• Le risposte valide arrivano sulla stessa porta dalle quali sono state inviate. In caso contrario lo stack di rete non e’ in grado di inviare il pacchetto al processo del demone DNS

• La sezione ‘question’ e’ duplicata anche nella risposta e deve essere uguale alla medesima sezione del pacchetto contenente la richiesta.

• Il Query ID e’ uguale a quello della richiesta.

• Le sezioni ‘Authority’ e ‘Additional’ rappresentano nomi che appartengono al dominio della richiesta. Questo meccanismo viene chiamato "baliwick checking". Questo impedisce ad un nameserver di rispondere con informazioni fraudolente oltre alla reale risposta.



DNS Cache Poisoning

Perche’?



DNS Cache PoisoningIndividuazione del query ID

Nel caso il DNS server sia configurato per utilizzare un Query ID sequenziale e’ sufficiente fare una richiesta che verra’ risolta da un nostro nameserver autoritativo per sapere il Query ID attuale del nameserver che vogliamo attaccare.



DNS Cache Poisoning

Una volta guessato il Query ID della nostra vittima sara’ sufficiente fargli risolvere un nome e floodarlo con risposte ‘fasulle’ per avere qualche possibilita’ di inserire record falsificati.



DNS Cache PoisoningRequisiti

• Il nome non puo’ essere gia’ contenuto nella cache del server DNS. Se una corrispondenza IP/nome e’ gia’ presente nella cache del DNS server che vogliamo poisonare non sara’ possibile completare l’attacco fino alla sua scadenza.

• L’attaccante deve trovare il corretto Query ID. Nel caso di DNS server vecchi o configurati male non e’ un gran problema. Abbiamo visto in precedenza che con un po’ di perseveranza la cosa e’ fattibile.

• L’attaccante deve essere piu’ veloce del vero DNS. Dipende molto dalle prestazioni della rete.



DNS Cache PoisoningPossibile soluzione

Una soluzione ovvia al problema e’ quella di randomizzare il TXID.

Con Query ID sequenziali l’attaccante ha un range limitato di valori da tentare. Se viene individuato il valore 1000 come Query ID sara’ sufficiente tentare I valori da 1001 a 1050 per avere buone possibilita’ di successo.

Se il DNS server randomizza I Query ID I valori che l’attaccante deve provare sono necessariamente 64k.

Molto piu’ difficile!



E loro che ne dicono?



DNS Cache Poisoning



DNS CachePoisoning

The Dan’s Way

Richieste verso hostname fasulli per aumentare i tentativi possibili nel minore tempo possibile.



DNS Cache Poisoning

E nel caso il Query ID sia randomizzato?

L’attaccante deve inviare moltissime ‘fake reply’.

Randomizzando l’hostname nella richiesta le probabilita’ aumentano.

50 pacchetti per ogni richiesta = ~ 10s per un attacco con successo.



DNS Cache Poisoning

Grazie alla scoperta di Dan Kaminsky ora sappiamo che e’ molto piu’ semplice riuscire ad effettuare un DNS Cache Poisoning nei confronti di un DNS server vulnerabile. E’ possibile inserire in un server DNS vulnerabile non solo corrispondenze tra IP/nome ma addirittura diventare nameserver autoritativi per qualsiasi dominio.

La cosa si fa piu’ interessante…

Cosa succederebbe se venisse rediretto l’intero dominio google.com?

Cosa succederebbe se venisse rediretto l’intero TPL .com?Sarebbe teoricamente possibile ma e’ necessaria parecchia capacita’ di calcolo per fingersi un GTLD



DNS Cache PoisoningLa soluzione – DJB Was Right

QID Randomization + Source Port Randomization



DNS Cache PoisoningRimedi

Aggiornate I vostri DNS servers! Esistono tool ed exploit pubblici disponibili che rendono molto facile l’operazione di poisoning nei confronti di un server vulnerabile.

I DNS Server configurati in modo da essere SOLO autoritativi non sono vulnerabili. Non hanno una cache. State attenti a chi offrite la vostra ricorsione.

Un server DNS correttamente patchato puo’ essere vulnerabile lo stesso. Come?Se in mezzo troviamo un firewall che effettua un ‘Port Address Translation’ che rende la randomizzazione delle porte inefficace.

DNSSEC e IPv6 ? Potrebbero risolvere il problema. Ma non sono uno standard. E prima che lo diventino passera’ parecchio tempo.

SSL? Puo’ essere utile. Sempre che si controllino i certificati dei siti che visitiamo.



DNS Cache Poisoning

DEMO



DNS Cache Poisoning

?



DNS Cache PoisoningReferences:

http://www.doxpara.com/DMK_BO2K8.ppthttp://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.htmlDNS and BIND - http://oreilly.com/catalog/9780596100575/index.htmlTCP/IP Illustrated, Volume 1 - http://www.amazon.com/TCP-Illustrated-Protocols-Addison-Wesley-Professional/dp/0201633469http://www.isc.org/sw/bind/http://cr.yp.to/djbdns.htmlUS-CERT Vulnerability Note VU#800113 - http://www.kb.cert.org/vuls/id/800113US-CERT Vulnerability Note VU#484649 - http://www.kb.cert.org/vuls/id/484649US-CERT Vulnerability Note VU#252735 - http://www.kb.cert.org/vuls/id/252735US-CERT Vulnerability Note VU#927905 - http://www.kb.cert.org/vuls/id/927905US-CERT Vulnerability Note VU#457875 - http://www.kb.cert.org/vuls/id/457875Internet Draft: Measures for making DNS more resilient against forged answers - http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilienceRFC 3833 - http://tools.ietf.org/html/rfc3833RFC 2827 - http://tools.ietf.org/html/rfc2827RFC 3704 - http://tools.ietf.org/html/rfc3704RFC 3013 - http://tools.ietf.org/html/rfc3013Microsoft Security Bulletin MS08-037 - http://www.microsoft.com/technet/security/bulletin/ms08-037.mspxInternet Systems Consortium BIND Vulnerabilities - http://www.isc.org/sw/bind/bind-security.phpUS-CERT - http://www.kb.cert.org/vuls/id/800113DNSSEC - http://en.wikipedia.org/wiki/DNSSEC



EOF

DNS Cache Poisoning Explained

Technology

Transcript of DNS Cache Poisoning Explained