Le 28 novembre 2008

Faille(s) DNS
Les petits tracas d'un grand protocole

Clment Collin Elias Yegdjong RICM3, Polytech'Grenoble

Plan
1. Introduction 2. Failles du protocole DNS 3. La faille de Kaminsky (+ dmo) 4. Des mesures de protection 5. Conclusion

1. Introduction
1. Introduction 2. Failles du protocole DNS 3. La faille de Kaminsky (+ dmo) 4. Des mesures de protection 5. Conclusion

1. Introduction

DNS : LE service de nommage d'Internet

Principes : rcursif, itratif... Vous connaissez ! Sans DNS, le Web s'croule Un bug dans 90% des serveurs DNS Panique bord ! Ludique (titiller un protocole vu en cours) Didactique (dangers et mesures de scurit)
4

Juillet 2008 : le buzz de Kaminsky

Objectifs de la prsentation

1. Introduction

Ce dont on ne parlera pas :

Attaques par DoS et DDoS

Objectif : faire tomber le systme Dernire grosse attaque en date : 11-2007 (les 13 serveurs racines pendant 12h, Core du Sud suspecte)

Tunnels DNS

Objectif : camoufler du trafic malfaisant La piraterie gnre beaucoup de trafic qui peut tre dtect Les paquets DNS n'attirent pas l'attention
5

1. Introduction

Ce dont on parlera :

Spoofing + Cache Poisoning

To spoof = parodier, faire une blague Cache Poisoning = empoisonnement de cache But : rediriger du trafic l'insu de l'utilisateur (pharming) Objectifs indirects : phishing sniffing propagation de virus installation de backdoors surveillance de mails ...
CheckPoint http://www.checkpoint.com/defense/advisories/public/dnsvideo/index.html

2. Failles du protocole DNS

1. Introduction 2. Failles du protocole DNS
1. Fonctionnement du protocole DNS 2. Les failles intrinsques du DNS 3. Exploitations malicieuses des failles

3. La faille de Kaminsky (+ dmo) 4. Des mesures de protection 5. Conclusion

7

2.1 Fonctionnement du protocole DNS

Source : http://www.packetfactory.net/projects/dnsa/ArticleDNS.pdf

2.1 Fonctionnement du protocole DNS

Source : http://www.packetfactory.net/projects/dnsa/ArticleDNS.pdf

2.2 Failles intrinsques du DNS

Le DNS est bas sur le protocole UDP.

La plupart des changes sont en UDP. Mais si requte longue ou transfert de zones,

Utilisation de TCP (port 53).

Avantages de l'UDP :

Rapidit des requtes, par rapport TCP. Une perte de paquets DNS n'est pas nuisible.

Le client ritre sa requte (dans la limite du "timeout").

10

2.2 Failles intrinsques du DNS

Problme de l'UDP :

Protocole non fiable, car "non connect".

Peut tre facilement spoof. Usurpation facile de l'adresse IP source.

Intgrit des rponses non garantie.

Unique solution propose par le protocole DNS :

Le DNS ID, ou Transaction ID (TXID).

11

2.2 Failles intrinsques du DNS

Le DNS ID (TXID) :

C'est l'identifiant d'une requte DNS.

Valeur identique dans la rponse. La client choisit alatoirement sa valeur chaque requte.

But : garantir l'intgrit d'une rponse DNS.

Est-ce la panace?

TXID = champ de 2 octets : soit 65536 valeurs possibles seulement !

Trop peu, compar la vitesse des processeurs actuels, la vitesse des liaisons...
12

2.3 Exploitations malicieuses des failles

Synthse :

Le DNS est bti sur le modle client/serveur. Des faiblesses du client : UDP, TXID court (2 bytes). Les serveurs DNS peuvent devenir des clients.

Faiblesses ct client rpercutes sur le ct serveur...

Deux types d'attaques envisageables.

Les attaques du client DNS, type DNS ID Spoofing. Les attaques du serveur DNS, comme le DNS Cache Poisoning.
13

2.3 Exploitations malicieuses des failles

Le DNS ID Spoofing.

But : trouver le DNS ID des requtes client, pour y rpondre avant le serveur lgitime. Principe :

Capter (ou sniffer) le trafic rseau. Forger un (ou plus) paquet(s) de rponse UDP complet(s). Rpondre au client avant le serveur DNS lgitime. Par force brute, par implmentation, par prdiction.
14

Autres mthodes d'attaque :

2.3 Exploitations malicieuses des failles

Illustration du DNS ID Spoofing

15 Source : http://www.packetfactory.net/projects/dnsa/ArticleDNS.pdf

2.3 Exploitations malicieuses des failles

Le DNS Cache Poisoning.

But : corrompre le cache d'un serveur DNS. Principe :

Faire tourner un faux serveur DNS qui permettra de rajouter un champ "additional record". Faire une requte sur le serveur DNS victime.

Cette requte devra tre redirige vers le faux serveur DNS.

Grace au champ "additional record", le faux serveur interrog rpondra avec plus d'enregistrements que demand.

16

2.3 Exploitations malicieuses des failles

Illustration du DNS Cache Poisoning

17 Source : http://www.packetfactory.net/projects/dnsa/ArticleDNS.pdf

3. La faille de Kaminsky
1. Introduction 2. Failles du protocole DNS 3. La faille de Kaminsky (+ dmo)
1. Le buzz 2. La thorie 3. La pratique

4. Des mesures de protection 5. Conclusion

18

3.1. Le buzz

Fin 2007 : Dbut d'un travail de rflexion

Constat : il y a des problmes de scurit avec DNS IETF + Bert Herbet :

Internet-Draft Measures for making DNS more resilient against forged answers Complment la RFC 1034 (http://tools.ietf.org/id/draft-ietf-dnsext-forgeryresilience-07.txt)

19

3.1. Le buzz

Pendant ce temps l, chez IOActive

Dan Kaminsky dcouvre un moyen d'empoisonner 90% des serveurs rcursifs du march. Il se tait et met au point des patchs. Kaminsky : 'J'ai dtect un bug norme, mais n'essayez surtout pas
de le trouver, attendez sagement la BlackHat de Vegas en aot ! Patchez-vous, a va tre la zone !'

Fvrier 2008 : la fuite

51h + tard : 1er exploit La Websphre s'enflamme

20

3.1. Le buzz

Enorme campagne de patching

Efficacit norme Cf.

/home/clement/Bureau/DNS/Clarified_Networks_Kaminsky_DNS_repair_visualisation.flv

21

3.1. Le buzz

Aot 2008, Las Vegas (BlackHat)

65% des serveurs patchs

La bataille est termine... ?

22

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

But : empoisonner le cache d'un DNS rcursif C'est une course

Entre le gentil DNS et le mchant DNS pour rpondre au DNS cible Si le mchant est ct de la cible (mme LAN), il gagne facilement (peut lire le TXID) Sinon doit essayer de deviner...

23

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

Le gentil a un sacr avantage dans cette course

Le gentil a un avantage de 65536 contre 1 sur le mchant (TXID sur 16 bits) Une fois que le gentil a gagn, le mchant doit attendre que le TTL expire avant de participer une nouvelle course 124 ans pour 50% russite (cf. annexe) Ca reste faiblard...
24

Petit calcul avec TTL = 1 jour

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

Mettons-nous la place du mchant, comment faire pour changer la donne ? ... ... ... ... 4 ides, dont 2 vraiment nouvelles

25

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

1) Si c'est une course, donnons le dpart !

On verra comment par la suite On balance notre fausse rponse immdiatement la suite du dclencheur :-) On est sr d'arriver le premier :-( On n'est toujours pas sr d'avoir le bon TXID

Qu'est-ce que a donne ?

26

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

2) On ajoute des cartouches

Qui a dit qu'on n'avait le droit qu' un essai ? Si on arrive balancer 100 rponses avant l'arrive de celle du gentil, nos chances changent : On passe de 65536 contre 1 655 contre 1 :-) Meilleure probabilit de succs (cf. birthday attack) :-( Si TTL = 1 jour, 454 jours = 1 an et 3 mois

Qu'est-ce que a donne ?

27

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

3) N'attendons plus la fin du TTL !

On ne peut essayer qu'une fois par TTL d'empoisonner www.toto.com Par contre on peut essayer 1.toto.com, 2.toto.com, 3.toto.com, etc. :-) On a russi empoisonner 3842.toto.com ! :-( Ca nous fait une belle jambe, on voulait empoisonner www.toto.com
28

Qu'est-ce que a donne ?

(d'aprs la prsentation de Kaminsky ralise Las Vegas en 08/2008)

3.2. La thorie

4) L'astuce

Un DNS peut rpondre 3 choses :

Je connais 3842.toto.com, c'est 1.1.1.1 Connais pas 3842.toto.com, dommage ! T'as qu' demander www.toto.com qui est en 2.2.2.2

Et l, la cible est force d'craser son cache ! En effet :

les rsolveurs rejettent les noms dits hors-bailliage, les noms qui sont dans une autre zone que la zone du nom cherch, justement pour limiter les risques d'empoisonnement.

GAME OVER
29

3.3. La pratique

Protocole exprimental

Choix d'un exploit

Faciles trouver sur le Net Mais lequel choisir ? (C, Python, Ruby...) Celui de Computer Academic Underground excut sous Metasploit Framework SNAPSHOT

Le plus comment Le plus paramtrable Le plus complet

Adresse de l'exploit : http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Repository SVN Metasploit : svn co http://metasploit.com/svn/framework3/trunk/

30

3.3. La pratique

Protocole exprimental (suite...)

Choix d'une cible

Ubuntu 8.04

Mais attention : mises jour automatiques La 9.4.1 aurait suffit mais on se mfie des patchs Serveur configur en rcursif Simple forwarder vers DNS de l'IMAG (le gentil)

Bind 8.4.7

Choix d'une architecture

cible et mchant sur mme machine (<= temps)

31

3.3. La pratique

Procd

Lecture et comprhension du code de l'exploit Configuration et lancement de BIND Configuration de l'exploit Essai d'empoisonnement de www.google.fr Observation des traces via Wireshark

32

Captures d'cran
Les paramtres de l'exploit

33

Captures d'cran
La vrification de la vulnrabilit

Etonnant, non?

34

Captures d'cran
Calculs pralable pour la course

35

Captures d'cran
Initialisation de l'attaque : serveurs d'autorit

36

Captures d'cran
Aspect d'une tentative avec 5 rponses spoofes

37

Captures d'cran
Aprs 25 minutes d'excution...

38

Captures d'cran
...la fin des haricots

39

4. Les mesures de protection

1. Introduction 2. Failles du protocole DNS 3. La faille de Kaminsky (+ dmo) 4. Des mesures de protection
1. Quelques mesures de base 2. Pour aller plus loin... 3. Et contre la faille de Kaminsky ?

5. Conclusion
40

4. Des mesures de protection

Attention : aucune mesure n'est infaillible !

L'augmentation du TTL :

Efficace dans la plupart des cas; Mais inefficace devant la faille de Kaminsky.

Mme des patches de scurit peuvent ajouter des vulnrabilits au protocole.

41

4.1 Quelques mesures de base

Mettre jour les serveurs DNS (patches) Sur les systmes non autoriss tre des serveurs DNS :

Dsactiver le dmon de noms BIND (named), Supprimer ce dmon si besoin est, pour viter les backdoor. Bloquer certains ports de communication via le pare-feu.
42

Activer les options de filtrage avanc.

4.2 Pour aller plus loin...

Utiliser, si possible, une table ARP statique sur le serveur DNS :

Evite les attaques via l' ARP spoofing, par exemple.

Excuter BIND (named) en tant qu'utilisateur non privilgi.

L'excuter dans une structure chroot()e.

Cacher la version de BIND. Surveiller le trafic DNS...

43

4.2 Pour aller plus loin...

Utiliser les extensions de scurit DNS (DNSSEC) : RFC 4033, 4034, 4035.

Ajoute l'authentification de la source.

Nouveaux RR (Resource Records) Modifications du protocole DNS. Mais c'est pas la panace (exploit BIND 8.2 NXT)

Le pirate peut excuter du code root sur le serveur. Il peut utiliser la mthode de Kaminsky pour changer le serveur d'autorit du domaine vis.

44

4.3 Et contre la faille de Kaminsky ?

Contre Kaminsky appliquer les correctifs !

Ports des requtes rcursives alatoires

On allonge le TXID de 16 bits (environ)

...

45

5. Conclusion
1. Introduction 2. Failles du protocole DNS 3. La faille de Kaminsky (+ dmo) 4. Des mesures de protection 5. Conclusion

46

5. Conclusion

Rels problmes de scurit dans DNS (pas pens pour a) Globalement bien protg (ajouts successifs) Le buzz de Kaminsky est avant tout un buzz Scuriser le DNS revient aussi scuriser le rseau Avenir : DNSSEC + TCP

47

Annexes
1. Bibliographie 2. Quelques calculs...

48

Bibliographie

Gnralits :

COLE E., Hackers, attention danger !, CampusPress, Paris, 2001 RUSSEL R. et al., Stratgies anti-hackers, Eyrolles, 2002 LIU C., ALBITZ P., DNS & BIND, O'Reilly, Paris, 2006 BETOUIN P., Failles intrinsques du protocole DNS, 2003, http://www.packetfactory.net/projects/dnsa/ArticleDNS.pdf SAINSTITUTE, Attacking the DNS Protocol Security Paper v2, Security Associates Institute, 2003, http://www.net-security.org/dl/articles/Attacking_the_DNS_Protocol.pdf SAIZ J., DNS, retour sur une vulnrabilit hors-norme, Security Vibes, 2008, http://fr.securityvibes.com/vulnerabilite-dns-kaminski-retour-article-924.html XMCO Partners, L'actuScu N 20 : UPNP, un protocole dangereux ?, Conseil en Scurit en Informatique, 2008, http://www.xmcopartners.com/actu-secu/XMCO-ActuSecu-20-UPNP.pdf
49

Bibliographie

Faille de Kaminsky :

KAMINSKY D., Its The End Of The Cache As We Know It, BlackHat, Las Vegas, 2008, http://www.doxpara.com/DMK_BO2K8.ppt DOUGHERTY C. R., Vulnerability Note VU#800113 : Multiple DNS implementations vulnerable to cache poisoning, US Computer Emergency Readiness Team, 2008, http://www.kb.cert.org/vuls/id/800113 BORTZMEYER S., Comment fonctionne la faille DNS Kaminsky ?, 2008, http://www.bortzmeyer.org/comment-fonctionne-la-faille-kaminsky.html SAIZ J., DNS, retour sur une vulnrabilit hors-norme, Security Vibes, 2008, http://fr.securityvibes.com/vulnerabilite-dns-kaminski-retour-article-924.html

50

Bibliographie

RFCs (Disponibles sur http://www.bind9.net/rfc) :

RFC 1034 - Domain Names - Concepts and Facilities RFC 1035 - Domain Names - Implementation and Specification RFC 4033 - DNS Security Introduction and Requirements RFC 4034 - Resource Records for the DNS Security Extensions RFC 4035 - Protocol Modifications for the DNS Security Extensions

51

Quelques calculs...
Soit Pk la proba de trouver la bonne rponse au bout de k tentatives infructeuses. Soit m le nombre de combinaisons de TXID possibles. Soit n le nombre de rponses que le pirate peut donner pour une tentative. On a : Avec :
Pk = P
k 1

1 P k

n / m

P 0= n / m

Objectif : trouver k (le nombre de tentatives) en fonction de la probabilit de russite dsire.

52

Quelques calculs...

Ceci nous donne : Pour n = 1 et m = 65536

P > 50% K = 45426 tentatives soit si TTL = 1 jour : 124 ans P > 90% K = 150 902 tentatives soit si TTL = 1 jour : 413 ans
53

Quelques calculs...

Exprimentalement : 1 tentative toute les 75 ms 16 rponses spoofes par tentative

Pour n = 16 et m = 65536

P > 90%

k = 9431 tentatives soit si 1 tentative dure 75 ms : 700 sec (moins de 11 minutes !) Pour n = 6 et m = 65536

P > 90%

k = 25150 tentatives soit si 1 tentative dure 75 ms : 1886 sec (plus de 30 minutes)

54

Quelques calculs...

Rponses spoofes = 1120 bits 10Mbits/s Envoi d'1 spoof = 0,112 ms Or ici 1 ms spare chaque spoof => mauvais

55