xx-xx

2010-2011

tude de la faille DNS Dan Kaminsky 2008

Propos par: M. xx xx Ralis par: M. Samir ABDELLI

Objectif:
Dans ce 3e travail, vous allez tudiez les tenants et aboutissants de la faille DNS mise en vidence par Kaminsky en 2008. Kaminsky a propos une exploitation astucieuse de certaines faiblesses du DNS. Votre travail consistera :

Expliquer ce en quoi consiste cette faille, la faon de l'exploiter, ses impacts, les logiciels
impacts, etc.

Monter une maquette permettant de mettre en vidence la faille. Vous attaquerez la zone
shayol.org et fournirez une capture de trame mettant en vidence le rsultat de l'attaque (et incluant au moins une requte de type A pour ns.shayol.org et retournant l'adresse 194.199.90.1). On ne vous demande pas de coder vous-mme les programmes permettant l'attaque. Vous pouvez utiliser des programmes rcuprs sur internet. Vous expliquerez le fonctionnement du programme rcupr (ce qu'il fait, pas la faon dont il est cod). trouver un programme en python serait un plus. Il existe de nombreuses descriptions de la faille. Bien videmment, ce que vous rendrez devra

tre votre explication et pas un copier/coller de ressources internet.

Introduction:

DNS Domain Name System est un style de nommage dans pour les htes dans un domaine [RFC 1034]. Le but de DNS est de fournir un mcanisme de nommage des ressources d'une faon ce que ces noms soit utiliss sur diffrents htes, rseaux, protocole, internet, etc. [RFC 1035] Ce non servira rfrencer des ressources dans un rseau. DNS manient des noms DNS dans ne base de donnes DNS qui contient le nom DNS d'un hte et son adresse IP correspondante. Cette base est souvent mise jour. Pour des raisons de performances (surtout dans le ca s ou la taille de la base DNS est trs importante) une Cache DNS est maintenue par le serveur de noms DNS qui contient les adresses IP des noms DNS qui ont taient recensement demander par un client de rseau. Un lment de cette cache sera supprim si le TTL Time To Live est nul (la valeur de TTL est dfinie par l'administrateur de serveur DNS) Avant d'aller plus loin et voir comment DNS Domain Name System fonctionne, on va introduire des termes qui seront utiliss dans la suite de ce rapport pour viter toute confusion avec d'autres termes;

Zone: dun point de vu de serveur de noms DNS , le domaine est constitu d'un ensemble dinformations locales appeles zones . Le Serveur de noms doit mettre jour priodiquement ces zones partir de copie des fichiers locaux de zones de son serveur DNS matre ou d'autres serveurs de noms [RFC 1034]. Serveur de nom: se serveur rpond des questions de la part des clients (les requtes: Quelle est l'adresse IP de shayol.org ? ). Parfois le serveur de nom rpond directement aux requtes de ces clients (cas d'un serveur autoritaire de la zone ou bien le nom shayol.org est dans sa cache DNS) , et parfois le serveur ce charge de la recherche de la rponse la question de client sur internet afin de trouver des serveurs de noms autoritaire sur le domaine shayol.org . Serveur autoritaire: Pour chaque zone, un fichier contenant une liste de nom de hte/IP ( ns.shayol.org est 194.199.90.1 , et ainsi de suite). Gnralement c'est une tache administrative sur une seule machine. C'est la zone matre . Resolver (Client DNS): c'est le moyen qui permet un client de poser des questions sur un serveur propos d'un nom dhte. Serveur de nom rcursif: Cest un serveur qui se permet d'aller sur Internet pour rechercher sur d'autres zones sur lesquelles il n'est pas autoritaire pour rpondre une requte client, c'est un service offert par les serveurs de noms pour ces clients (cas d'un ISP). Parfois les serveurs de noms ne sont pas configurs pour fournir ce service aux clients (sauf les abonns d'un ISP par exemple). Il y a encore des cas o le client demande son serveur de noms de ne pas jouer le rle d'un serveur de noms rcursif et le laisser lui-mme se dbrouiller d'interroger d'autres serveurs de noms. Cache DNS: Un serveur de nom local rcursif qui accde internet pour rpondre une requte client, rcupre une rponse aprs une srie de requte vers les serveurs de noms sur internet jusqu'au serveur autoritaire pour le nom dhtes recherch. Ensuite le serveur de nom local satisfait le client demandeur et enregistre ce nom de hte et son adresse IP dans un espace appel cache DNS , pour que d'autres client qui font la mme requte reoivent la mme rponse que le premier client mais cette fois ci plus rapidement (rponse directe), malgr que le serveur de noms n'est pas autoritaire de nom recherch. Le TTL: Time To Live d'un lment dans le cache est spcifie par administrateur de la zone pour chaque type d'enregistrement.
Ex: Interroger le serveur de noms de systme (/etc/resolv.conf) host -a shayol.org (le client demande au serveur de noms de rechercher shayol.org )

 dig shayol.org +trace (le client demande au serveurs de noms de ne pas rechercher shayol.org sur internet s'il n'est pas autoritaire mais de le laisser se dbrouiller pour le faire, pour cela le client contactera les serveurs ROOT au nombre de 13 (de a jusqu' m ) qui garantissent le bon fonctionnement de Internet l'chelle mondial.

 Enregistrement DNS: DNS propose plusieurs types d'enregistrement, tel que: une adresse IP (enregistrement A ), NS(nameserver: serveur de noms), MX(mail exchanger), SOA(start of authority) Dlgation: Dans un cas o le serveur de noms ne trouve pas le nom de hte dans sa zone, il se permet de rpondre au client et de lui suggrer un autre serveurs de noms qui peut lui son tour luis suggrer un autre serveur de noms qui est autoritaire sur la zone. C'est gnralement le cas des serveur dits ROOT : domaine racine et des serveur GTLD: Global Top Level Domain , domaine de premier niveau qui son responsable des domaines .com , .net , et .org

Fonctionnement de DNS:

Connatre toute les tapes de fonctionnement de DNS et les changes de requtes DNS (questions et rponses) sont trs importante pour mieux comprendre la suite de ce document.

Resolver(client DNS):

Un client fait une requte (question) Quelle est l'adresse IP de shayol.org ? son serveur de noms (dans Linux c'est gnralement /etc/resolv.conf). Cette question recherche donc une rponse de type A : adresse IP. A la rception le serveur de nom vrifie sil est autoritaire sur la zone de shayol.org , et comme ce n'est pas le cas, le serveur consultera sa cache DNS locale pour voir sil peut trouver une adresse IP de shayol.org rcemment consulte. Donc le serveur ne peut pas rpondre au client, mais gnralement les serveurs de nom (par exemple des ISP) sont configurs chercher une rponse sur Internet pour pouvoir rpondre aux requtes clients(ou uniquement pour

ces abonns). Mais si le serveur de noms est autoritaire pour shayol.org une rponse est directement envoye au client demandeur, et si le serveur de noms consulte sa cache DNS et trouvera le nom DNS shayol.org il renvoie l'adresse IP associe directement au client sans accder internet. Chaque client DNS, quand il fait une requte de question au serveur de noms il prend un identifiant de cette requte appele QID: Query ID, ou TXID: Transaction ID pour que le serveur de noms puisse rediriger la rponse de sa requte vers le client, mais l encore le serveur de noms doit grer plusieurs QID de plusieurs clients et peut tre plusieurs QID en mme temps. Dans notre cas on supposera que notre serveur de noms n'est pas autoritaire pour shayol.org et qu'il n'est pas dans sa cache DNS, et donc le serveur recherchera ce nom sur Internet (sauf cas contraire, dans le cas o le serveur DNS n'est pas configur comme serveur de noms rcursif ou que le client veut se dbrouiller lui-mme pour trouver l'adresse IP de shayol.org ).

Requte de Serveur de noms local vers l'extrieur:

prsent notre serveur de nom local jouera le rle d'un client DNS sur Internet. Les serveurs de noms rcursifs sont configurs avec les 13 serveurs de noms qui grent Internet (requtes DNS) ROOT Servers , la plupart sont aux tats Unies, de la forme A.ROOT-SERVERS.NET. IN A 198.41.0.4 (de A M), et qui, heureusement ne changent pas d'adresse IP trs souvent, et jamais en mme temps. Et qui peuvent grs plusieurs requtes DNS la fois et en mme temps.

Notre serveur de nom local va choisir, alatoirement, un serveur DNS racine sur Internet root, et envoie sa requte DNS Mon client veut savoir l'adresse IP de shayol.org? vers b.rootservers.net (IP: 192.228.79.201)

Le serveur b.root-servers.net n'a pas d'information sur shayol.org , mais il peut envoyer des informations de type NS: NameServer au serveur de noms local. Ces informations sont des noms 5

de serveurs de noms responsable des noms de domaine .com , .net , et .org appels GTLD: Global Top Level Domain . Le domaine .org est gr depuis le 1er janvier 2003 par Public Interest Registry . Afilias assure la gestion technique du registre .org tout comme le nom de domaine .info , en vertu d'un contrat avec Public Interest Registry . Le serveur b.rootservers.net fournit aussi les adresses IP des serveurs GTLD pour viter une autre recherche sur les adresse IP de GTLD de la part de serveur de noms local

Aprs la rception d'une liste des serveurs de noms GTLD de la part de b.rootservers.net , le serveur de noms local choisit, encore une fois, au hasard, un serveur GTLD, b2.org.afilias-nst.org , et envoie la mme question (requte question) au serveur b2.org.afiliasnst.org , Mon client veut savoir l'adresse IP de shayol.org? Maintenant son tour le nouveau serveur de noms b2.org.afilias-nst.org n'a pas de rponse exacte la requte question de serveur de noms local, mais il peut donner des informations sur le serveur autoritaire pour shayol.org , et donc il va envoyer des enregistrements de type NS , serveur de noms avec les adresses IP associs. Le serveur de noms local reoit donc une liste (un ou plusieurs NS) de serveur de noms autoritaire pour shayol.org . Le serveur de noms local envoie donc la mme question Mon client veut savoir l'adresse IP de shayol.org? l'un des serveurs autoritaires pour shayol.org . Cette fois ci, c'est le serveur autoritaire qui va rpondre la question de serveur de noms local Mon client veut savoir l'adresse IP de shayol.org?
Dans notre cas e n'est ps une adresse IP de shayol.org qu'on a rcupr mais un SOA: Start Of Authority qui est correspond au serveur de noms autoritaire pour shayol.org , (shayol.org. 86400 IN SOA abbadingo.shayol.org.) Et abbadingo.shayol.org est l'adresse IP 88.176.64.22 et shayol.org est un CNAME: Canonical Name pour les services web.

Le serveur de noms retourne les rsultats (requte rponse) qui contient l'adresse IP de shayol.org au client, qui est dfinit par son QID sur le serveur.
Pendant tout ce temps (envoie d'une requte question) soit au niveau de client vers le serveur de noms local soit au niveau de serveur de noms local vers Internet, les deux attendent une rponse pour leur question qui est reconnu par l question pose et les rsultats et encore le QID de la requte de question. la rception de ces trois lments (question, rponse, et QID) une vrification et comparaison entre ce qui a t demand est ce qui a t reu pour accepter la requte rponse avec les bonnes valeurs ou tout simplement l'ignore. En tous les cas la premires rponse qui satisfait ces trois critre est immdiatement accepte et si dans le cas o le client(ou serveur de noms local connect internet) reoit une deuxime rponse elle sera ignore aussi. Car il a dj reu une rponse bonne sa requte question. Le serveur de noms enregistre dans sa cache la rponse la question de client, pour satisfaire d'autres clients qui veulent se connecter cette mme nom de hte(qui poseront la mme question que le client prcdant)

exemple pratique d'une requte d'un serveur de noms rcursif sur Internet:

Les attaques DNS:

Quelques types d'attaque DNS (Attaques sur le serveur):

Denial of Service (DoS): C'est le cas o les utilisateurs d'un rseau son prvis d'un service rseau, tel que un service de messagerie ou un service web. La perte de service rseau engendre une perte de connexion rseau ce service ou au rseau en entier. Cette technique consiste gnrer un trafic rseau important destination de la machine (gnralement serveur) sur laquelle le service tourne. Les limites de traitement de requte (trafic) en terme de temps et les capacits physique (mmoire processeurs, etc.) rendent le serveur instable ou le service inaccessible pour rpondre des nouvelles requtes clients et donc soit il refuse les requtes client ou se plante et du coup le service offert par le serveur sera arrt. Distributed Denialof Service (DdoS): C'est une forme de DoS mais distribu, c'est dire que le trafic rseau n'est pas uniquement gnr par le mme poste mais partir de plusieurs sources. C'est donc, une multitude de machine s'attaquent la mme machine (souvent n serveur qui fournit un service). Cette attaque augmente beaucoup plus le trafic par rapport DoS. Elevation of Privilege: C'est la capacit d'un utilisateur (ou un pirate) gagner l'accs des fonctionnalits rserves gnralement pour les tches administratives. Ces fonctionnalits peuvent tre sur une machine sur le rseau ou des droits sur le rseau lui-mme. C'est gnralement d une faille dans un service install dans le rseau. Spoofing: L'attaquant injecte des paquets qui contiennent des adresses IP sources autorises faire des transferts de zone avec le serveur DNS en question. Ce qui permet un attaquant d'envoyer des paquets particuliers pour injecter un faux domaine dans le cache DNS. Transfert de Zone Un-authentifi: Un attaquant peut utiliser un transfert de zone qui contient un code malicieux ou un format inappropri qui plante un serveur DNS vulnrable a ce type d'attaque, ce qui rsulte un DoS qui dstabilise les services DNS.
Empoisonnement du cache DNS (Attaque sur le cache de serveur):

C'est l'endroit idal pour un attaquant d'injecter dans le cache d'un serveur de noms rcursif un faux domaine. Supposant que le domaine voulu par le client est shayol.org l'adresse IP 88.176.64.22 , et on rponse le client reoit le IP 194.199.90.1 . Le client ne va s'apercevoir de la gravit de sa requte, ni le serveur d'ailleurs. Car pour le client c'est transparent car lui l a demand shayol.org et il l'a bien reu mais pas la bonne adresse IP et ce mme rsultat sera propag sur d'autres clients sils demandent le mme nom shayol.org car le serveur de noms rcupre l'adresse IP partir de sa cache qui est empoisonne. Empoisonner le cache d'un serveur de noms n'est pas l'envoie d'un simple paquet car l'acceptation d'une rponse sur un serveur de noms local rcursif est base sur des critres et conditions: Une technique de protection existe, mais qui n'est pas suffisante et donc non fiable.

Une rponse arrive au serveur de noms local sur le mme port UDP (ou TCP c'est le paquet est grand) de l'envoie de la requte question, si ce n'est pas le cas la requte rponse est ignore. Le champ Query de paquet de rponse doit absolument contenir la mme question pose par le serveur de noms qui est en attente une rponse sa question et qui porte le mme QID(TXID) que le paquet de question. Les sections Authority et Additional reprsentent des noms qui appartiennent au mme domaine que la question pose. C'est ces deux sections qui permettent de rediriger les requtes de serveur de nom local vers les autorits sur le domaine demand et les adresses IP des autorits afin d'viter de nouvelles requtes pour trouver les adresses IP des autorits pour le domaine recherch ou les serveurs de noms TLD.
Si toutes ces conditions sont satisfaites le serveur de noms local rcursif acceptera le paquet comme une rponse la requte question. La question qui se pose ici, c'est Est ce que cela suffit pour dire que le paquet reu est valide et sera accept par le serveur de noms comme rponse? . Si un attaquant arrive trouver ou prdire ces valeurs et envoyer au serveur de noms un paquet DNS rponse au serveur pour lui annoncer qu'il est autoritaire sur le domaine recherch. Le rsultat sera dans le cache de serveur de noms, et tous les clients qui dpendent de ce serveur de noms seront pirats. En gnral, l'attaquant trouve un serveur de noms vulnrable ce type d'attaque,

par un balayage d'une des adresses IP de rseau ou toute autre techniques ( l'aide de nmap par exemple). Ensuite, l'attaquant essaye de trouver un domaine, par exemple shayol.org ou un autre plus utilis par les clients de ce serveur de noms (d'un ISP), comme le domaine d'une banque. Le but de l'attaquant et de faire persuader le client de serveur de noms qu'il est bien sur le site qu'il a demand dans une requte question envoye vers son serveur de noms rcursif et comme l'attaquant injecter sont paquet qui a t accept par le serveur de noms local, et enregistr dans le cache le serveur renvoie alors la fausse adresse IP de site. Pour russir cette attaque, l'attaquant crera un site web qui est identique l'original, et pour lever tout soupon de la part des clients, l'attaquant peur redirig le trafic des clients vers le vrai site. Parfois, trouver les bonnes valeurs que le serveur de noms attendent ncessite l'envoie de plusieurs paquet vers le serveur de noms local rcursif.

Attaque des 13 serveurs DNS Root de 21 Octobre 2003: La grande importance de ces serveurs pour le bon fonctionnement d'Internet a mis en vidence le problme de scurit des serveurs DNS et leurs vulnrabilit face aux attaques de type DDoS. Bien que ces attaques ne sont directement lies aux serveurs DNS, mais les services qu'ils offrent pour garantir des services pour internet qui sont interrompus sur 9 serveurs des 13.

Exemple d'une attaque DNS (Empoisonnement de cache):

Le problme qu'un attaquant peut compliquer la tche d'empoisonner le cache DNS de serveur de noms local est de trouver le bon TXID. Le pirate envoi une requte DNS vers le serveur de noms vulnrable propos d'un hte qui veut empoisonner (www.shayol.org). Au moment o le serveur de noms vulnrable effectue les recherches sur les serveurs de noms. Aprs un moment le serveur fait des requtes pour savoir le serveur de noms autoritaire sur la zone (shayol.org) qui est ns.shayol.org . Le pirate comme il connait dj la question que le serveur de noms vulnrable, et l le pirate envoie ce serveur sur le bon port UDP la repose qu'il voulait forge (ns.shayol.org est l'adresse IP 194.199.90.1). si le TXID de la requte rponse avec celui de la requte question de serveur vulnrable. Le serveur de noms vulnrable accepte la rponse de pirate (ns.shayol.org est 194.199.90.1), et lenregistre dans son cache pour un temps TTL dfinit par le pirate dans sa requte rponse forge. A prsent chaque client DNS configur contacter son serveur de noms vulnrable aura la mauvaise rponse car le serveur de noms consultera son cache qui a t empoisonne par le pirate. Faille DNS de Dan Kaminsky : Le problme avec l'exemple prcdant est que la temps pour trouver le bon TXID entre l'envoi de la requte question de serveur de noms vulnrable sur internet et le bruteforce de pirate pour trouver le bon TXID est trs court. Et si le serveur de noms reoit la rponse de la part e vrai serveur avant que le pirate ne russisse trouver le bon TXID, le pirate doit attendre l'expiration de TTL de cache de serveur avant de relancer une nouvelle attaque. Des solution ont t propos mais pas toujours efficace, entre autres attaquer le vrai serveur de noms(ns.shayol.org) par une attaque DoS pour le faire retarde rpondre la requte de serveur de noms, et le pirate gagne plus de temps. Kaminsky, lui propose une nouvelle approche. Au lieu de demander un hte qui existe un demande des htes qui n'existent forcement pas (ns111111.shayol.org, puis ns111112.shayol.org et ainsi de suite). En plus que ces noms de hte ne seront pas sur le cache de serveur de noms vulnrable et encore ils donnent plus de chance au pirate de tomber sur le bon TXID. Mais Kaminsky ne s'est pas arrt l, au lieu d'empoisonner le cache d'un serveur vulnrable avec une seule adresse IP pour chaque sites (www.shayol.org sur 194.199.90.2, mail.shayol.org sur 194.199.90.3, etc.), on empoisonne toute la zone shayol.org on faisant croire au serveur de noms vulnrable que le serveur de noms ns.shayol.org qui est autoritaire sur la zone shayol.org est l'adresse 194.199.90.1, incluant www.shayol.org et mail.shayol.org et tout ce que le pirate veut inclure. Scenario d'attaque de Dan Kaminsky :

 Le pirate demande au serveur de noms vulnrable la rsolution de nom de xyz.shayol.org. Le pirate envoi au serveur de noms de requtes rponse au serveur de noms, mais il glisse dans les rponses la section Authority records Je ne sais pas o est xyz.shayol.org mais tu peux aller voir cette adresse IP . Cette adresse IP est l'adresse IP de serveur de noms que le pirate a cr. Le pirate a cr donc son serveur de noms qui peut contenir shayol.org mais pas la bonne adresse IP (le serveur de noms de pirate sera le serveur autoritaire sur la zone shayol.org) Si le pirate tombe sur le bon TXID le serveur de noms vulnrable va croire que c'est la bonne adresse IP et valide la rponse et l'enregistre dans son cache. Tout le trafic des clients de serveur de noms vulnrable empoisonn vers le domaine shayol.org sera redirig ver le serveur de noms pirate (www.shayol.org, mail.shayol.org, ftp.shayol.org, etc.) Les versions vulnrables: Versions vulnrable cette attaque: En effet, ce qui fait de cette faille trs dangereuse est que elle n'est pas dpendante d'une plateforme particulire ou une version ou autres, mais cette faille est exploitable si les conditions suivantes sont vrifies: le serveur est rcursif et utilise toujours le mme port pour envoyer et recevoir ses requtes et utilise UDP comme protocole. le TXID tant dj alatoire avec 64K valeurs possibles. Avec DNS la premire rponse qui vrifie ces conditions est accepte et s'il y a une aprs il l'ignore. Parmi les versions qui sont vulnrable cette faille sont: BIND:8 (toutes les versions) 9.0 (toutes les versions) 9.1 (toutes les versions) 9.2 (toutes les versions) 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4 9.4.0, 9.4.1, 9.4.2 9.5.0a1, 9.5.0a2, 9.5.0a3, 9.5.0a4, 9.5.0a5, 9.5.0a6, 9.5.0a7, 9.5.0b1 Microsoft Serveur: Windows 2000 Server Service Pack 4, Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2, Windows Server 2003 x64 Edition and Windows Server 2003 x64 Edition Service Pack 2, Windows Server 2003 with SP1 for Itanium-based Systems and Windows Server 2003 with SP2 for Itanium-based Systems, Windows Server 2008 for 32-bit Systems, Windows Server 2008 for x64-based Systems Microsoft Client: Windows 2000 Service Pack 4, Windows XP Service Pack 2, Windows XP Service Pack 3, Windows XP Professional x64 Edition, Windows XP Professional x64 Edition Service Pack 2, Windows Server 2003 Service Pack 1, Windows Server 2003 Service Pack 2, Windows Server 2003 x64 Edition, Windows Server 2003 x64 Edition Service Pack 2, Windows Server 2003 with SP1 for Itanium-based Systems, Windows Server 2003 with SP2 for Itanium-based Systems Protection contre l'attaque de Kaminsky:

Appliquer les nouveaux patches immdiatement (port source alatoire) Utiliser DNSSEC (Domain Name System Security Extensions) pour protger les changes et les transferts des zones, cryptage pour authentifier les transactions Prcaution: Si le serveur est met jour, supprimer la ligne query-source address * port 53 dans la partie options de fichier named.conf ou bien pour les versions plus rcentes dans named.conf.options Limiter la rcursivit pour les utilisateurs locaux (Ajouter des ACL: Access Control List) Cacher la version de serveur DNS, en bind dans le fichier named.conf.options on ajoute la ligne version "TOP SECRET"; Dsactiver le cache de serveur DNS et si besoin, installer un serveur de cache sparment de serveur DNS. le serveur DNS peut tre dans une DMZ (sparer physiquement les serveurs internes des serveurs externes) Faire des tests de l'extrieur pour vrifier la configuration de serveur DNS et voir galement les anomalies qui peuvent arrives et contrler les fichiers logs de serveur DNS Quelques types de routeurs, pare-feu, et passerelles qui utilise le NAT(Network Address Transaltion) et PAT(Port Address Translation) peuvent modifis le port source ce qui rduit l'efficacit de patch. Chaque serveur tourne sur un serveur ddi

10

Supprimer les services inutiles sur un serveur La maquette: Le programme qui exploite la faille de Kaminsky est un programme crit en Python, son auteur est Julien Desfossez (http://www.solisproject.net/) Il existe encore des exploits en Ruby module pour Metasploit et des programmes en C qui sont souvent plus rapide que le Python. L'exploit crit en python initialise tout d'abord les paramtres de l'attaque, entre autres l'adresse IP de serveur DNS rcursif et qui utilise toujours le mme port, le domaine spoofer . En premier temps le programme cre un paquet rep avec les paramtres dj initis. Ensuite le programme entre dans une boucle infinie While 1 , et dans cette partie il gnre un nouveau paquet req qui est envoy avec l'adresse source de pirate, ce paquet envoie des requtes XXXX.shayol.org avec XXXX est une valeur qui est incrmente aprs chaque envoie la raison pour cela c'est pour gnrer plus de requtes DNS pour sur domaine shayol.org et donc augmenter les chances de faire l'empoisonnement de cache de serveur vulnrable, c'est justement l'un des point fort de l'attaque de Kaminsky car cela vite le cas o le domaine en question shayol.org soit dj dans le cache de serveur vulnrable cela empche une nouvelle tentative d'empoisonnement mais il faut attendre l'expiration de TTL de l'enregistrement de shayol.org dans le cache. Aprs l'envoie de paquet gnr par le pirate vers les serveurs DNS rcursif, le pirate cre une rponse la requte qui a lui-mme dj pos au serveur. Et donc le pirate reprend les mmes paramtres de sa question prcdente dans la requte req , il a tent de faire persuader le serveur DNS qui ce nouveau paquet est la rponse la requte "req". Pour le faire il va utiliser le paquet rep forg avec les bons paramtres. le paquet rep est donc une rponse cre par l'attaquant qui contient comme adresse source 194.199.90.1 et en adresse destination l'IP de serveur DNS rcursif vulnrable. Mais rep ncessite quelque modification, dans le champ question et le champ rponse qui doivent contenir XXXX.shayol.org . Aprs cela, le pirate commence envoyer des rponses forges au serveur DNS vulnrable dans une boucle finie (50 fois dans le programme), qui incrmente la valeur de champ TXID (Transaction Identifier ou QID: Query Identifier) de paquet rep et envoie le tout vers le serveur DNS. Aprs la fin de la boucle de rponse forge rep le programme teste le rsultat de l'envoie de ces rponse au serveur DNS, ici ce n'est pas important si on teste ceci aprs chaque envoie car en cas de succs on ne va pas chercher le rsultat ailleurs mais seulement au niveau de cache de notre serveur DNS et l c'est le pirate qui va lancer une nouvelle fois sa requte question req mais cette fois sans demande d'utilis la rcursivit. Et donc si on a un rsultat, c'est dire une rponse la question Quelle est l'adresse IP de shayol.org ? de la part de serveur DNS vulnrable, rponse de type ns.shayol.org est autoritaire sur le domaine shayol.org et qui se trouve l'adresse IP 194.199.90.1" donc le pirate a russi empoisonner le cache de serveur sinon on ressaye encore et encore jusqu'au succs de l'attaque. Si le serveur est vulnrable l'attaque gnralement russie sauf en cas d'interruption de a part de l'attaquant. En ce qui concerne l'excution de script python ce moment on na pas russi le faire tourner, cependant on a russi le faire marcher mais en Metasploit avec les options suivantes: msf auxiliary(bailiwicked_host) > Module options:
HOSTNAME ns.shayol.org yes INTERFACE no NEWADDR 194.199.90.1 RECONS 208.67.222.222 yes Hostname to hijack The name of the interface yes New address for hostname The name server used for reconnaissance

11

RHOST 192.168.32.128 SNAPLEN 65535 SRCADDR Real (accepted: Real, Random) SRCPORT 53 automatic) TIMEOUT 500 TTL 47410 XIDS 0

yes yes yes yes yes

The target address The number of bytes to capture The source address to use for sending the queries The target server's source query port (0 for The number of seconds to wait for new data yes The TTL for the malicious host entry yes The number of XIDs to try for each query

(0 for automatic) Avec 192.168.32.128 adresse de serveur de nom vulnrable. Conclusion: La scurit de DNS est une problmatique pour les expert en scurit. En effet les requtes sur internet son base sur les requtes DNS, si un problme de scurit est signal a sera la panique sur ce rseau surtout quand il s'agit d'une faille de trs grande envergure notamment sur les serveurs racines root de l'internet. Le buzz mondial de Kaminsky en Juillet 2008 a encore montr la fragilit de DNS face aux attaques. DNSSEC est une extension qui permet de protger les transactions. Reste voir est ce que cette extension est efficace en terme de scurit. Il faut prciser que aujourd'hui existe toujours de serveur de noms qui ne sont pas encore protgs contre les attaques rcentes. Kaminsky avait le grande gnrosit de publier sa dcouverte aprs avoir prvenu les dveloppeurs des logiciels mais il y a des gens qui gardent leurs dcouvertes pour mettre des buts destructifs.

Bibliographie:
http://www.unixwiz.net http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx http://www.trusteer.com/list-context/publications/windows-dns-server-cache-poisoning http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html http://www.kb.cert.org/vuls/id/800113

12