xx-xx2010-2011

Étude de la faille DNS

« Dan Kaminsky 2008 »

Proposé par:M. xx xx

Réalisé 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 façon de l'exploiter, ses impacts, les logiciels impactés, 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 résultat de l'attaque (et incluant au moins une requête de type A pour « ns.shayol.org » et retournant l'adresse 194.199.90.1). On ne vous demande pas de coder vous-même les programmes permettant l'attaque. Vous pouvez utiliser des programmes récupérés sur internet. Vous expliquerez le fonctionnement du programme récupéré (ce qu'il fait, pas la façon dont il est codé). trouver un programme en python serait un plus.

1

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 hôtes dans un domaine [RFC 1034]. Le but de DNS est de fournir un mécanisme de nommage des ressources d'une façon à ce que ces noms soit utilisés sur différents hôtes, réseaux, protocole, internet, etc. [RFC 1035]

Ce non servira à référencer des ressources dans un réseau. DNS manient des noms DNS dans ne base de données DNS qui contient le nom DNS d'un hôte 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 très 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 réseau. Un élément de cette cache sera supprimé si le TTL « Time To Live » est nul (la valeur de TTL est définie 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 utilisés dans la suite de ce rapport pour éviter toute confusion avec d'autres termes;

• Zone: d’un point de vu de serveur de noms « DNS », le domaine est constitué d'un ensemble d’informations locales appelées « zones ». Le Serveur de noms doit mettre à jour périodiquement ces zones à partir de copie des fichiers locaux de zones de son serveur DNS maître ou d'autres serveurs de noms [RFC 1034].

• Serveur de nom: se serveur répond à des questions de la part des clients (les requêtes: « Quelle est l'adresse IP de shayol.org ? »). Parfois le serveur de nom répond directement aux requêtes 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 réponse à 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 hôte/IP » (« ns.shayol.org est 194.199.90.1 », et ainsi de suite). Généralement c'est une tache administrative sur une seule machine. C'est la « zone maître ».

• Resolver (Client DNS): c'est le moyen qui permet à un client de poser des questions sur un serveur à propos d'un nom d’hôte.

• Serveur de nom récursif: C’est un serveur qui se permet d'aller sur Internet pour rechercher sur d'autres zones sur lesquelles il n'est pas autoritaire pour répondre à une requête 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 configurés pour fournir ce service aux clients (sauf les abonnés d'un ISP par exemple). Il y a encore des cas où le client demande à son serveur de noms de ne pas jouer le rôle d'un serveur de noms récursif et le laisser lui-même se débrouiller d'interroger d'autres serveurs de noms.

• Cache DNS: Un serveur de nom local récursif qui accède à internet pour répondre à une requête client, récupère une réponse après une série de requête vers les serveurs de noms sur internet jusqu'au serveur autoritaire pour le nom d’hôtes recherché. Ensuite le serveur de nom local satisfait le client demandeur et enregistre ce nom de hôte et son adresse IP dans un espace appelé « cache DNS », pour que d'autres client qui font la même requête reçoivent la même réponse que le premier client mais cette fois ci plus rapidement (réponse directe), malgré que le serveur de noms n'est pas autoritaire de nom recherché. Le « TTL: Time To Live » d'un élément dans le cache est spécifie par administrateur de la zone pour chaque type d'enregistrement.

Ex: Interroger le serveur de noms de système (/etc/resolv.conf)

« host -a shayol.org » (le client demande au serveur de noms de rechercher « shayol.org »)

2

« 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 débrouiller 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.

3

• 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)

• Délégation: Dans un cas où le serveur de noms ne trouve pas le nom de hôte dans sa zone, il se permet de répondre au client et de lui suggérer un autre serveurs de noms qui peut lui à son tour luis suggérer un autre serveur de noms qui est autoritaire sur la zone. C'est généralement 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:Connaître toute les étapes de fonctionnement de DNS et les échanges de requêtes DNS

(questions et réponses) sont très importante pour mieux comprendre la suite de ce document.

• Resolver(client DNS):

Un client fait une requête (question) « Quelle est l'adresse IP de shayol.org ?» à son serveur de noms (dans Linux c'est généralement /etc/resolv.conf). Cette question recherche donc une réponse de type « A : adresse IP». A la réception le serveur de nom vérifie s’il 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 s’il peut trouver une adresse IP de « shayol.org » récemment consultée. Donc le serveur ne peut pas répondre au client, mais généralement les serveurs de nom (par exemple des ISP) sont configurés à chercher une réponse sur Internet pour pouvoir répondre aux requêtes clients(ou uniquement pour

4

ces abonnés). Mais si le serveur de noms est autoritaire pour « shayol.org » une réponse est directement envoyée 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 accéder à internet.

Chaque client DNS, quand il fait une requête de question au serveur de noms il prend un identifiant de cette requête appelée « QID: Query ID, ou TXID: Transaction ID » pour que le serveur de noms puisse rediriger la réponse de sa requête vers le client, mais là encore le serveur de noms doit gérer plusieurs QID de plusieurs clients et peut être plusieurs QID en même 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 récursif ou que le client veut se débrouiller lui-même pour trouver l'adresse IP de « shayol.org »).

• Requête de Serveur de noms local vers l'extérieur:

à présent notre serveur de nom local jouera le rôle d'un client DNS sur Internet. Les serveurs de noms récursifs sont configurés avec les 13 serveurs de noms qui gèrent Internet (requêtes 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 très souvent, et jamais en même temps. Et qui peuvent gérés plusieurs requêtes DNS à la fois et en même temps.

Notre serveur de nom local va choisir, aléatoirement, un serveur DNS racine sur Internet « root», et envoie sa requête DNS « Mon client veut savoir l'adresse IP de shayol.org? » vers « b.root-servers.net » (IP: 192.228.79.201)

• Le serveur « b.root-servers.net »n'a pas d'information sur « shayol.org », mais il peut envoyer

5

des informations de type « NS: NameServer » au serveur de noms local. Ces informations sont des noms de serveurs de noms responsable des noms de domaine « .com », « .net », et « .org » appelés « GTLD: Global Top Level Domain ». Le domaine « .org » est géré 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.root-servers.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

• Après la réception d'une liste des serveurs de noms GTLD de la part de « b.root-servers.net », le serveur de noms local choisit, encore une fois, au hasard, un serveur GTLD, « b2.org.afilias-nst.org », et envoie la même question (requête question) au serveur « b2.org.afilias-nst.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 réponse exacte à la requête 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 associés.

• Le serveur de noms local reçoit donc une liste (un ou plusieurs NS) de serveur de noms autoritaire pour « shayol.org ». Le serveur de noms local envoie donc la même 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 répondre à 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 récupéré 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 résultats (requête réponse) qui contient l'adresse IP de « shayol.org » au client, qui est définit par son QID sur le serveur.

Pendant tout ce temps (envoie d'une requête 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 réponse pour leur question qui est reconnu par l question posée et les résultats et encore le QID de la requête de question. À la réception de ces trois éléments (question, réponse, et QID) une vérification et comparaison entre ce qui a été demandé est ce qui a été reçu pour accepter la requête réponse avec les bonnes valeurs ou tout simplement l'ignorée. En tous les cas la premières réponse qui satisfait ces trois critère est immédiatement acceptée et si dans le cas où le client(ou serveur de noms local connecté à internet) reçoit une deuxième réponse elle sera ignorée aussi. Car il a déjà reçu une réponse bonne à sa requête question.

Le serveur de noms enregistre dans sa cache la réponse à la question de client, pour satisfaire d'autres clients qui veulent se connecter à cette même nom de hôte(qui poseront la même question que le client précédant)

6

• exemple pratique d'une requête d'un serveur de noms récursif sur Internet:

7

• 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 réseau son prévis d'un service réseau, tel que un service de messagerie ou un service web. La perte de service réseau engendre une perte de connexion réseau à ce service ou au réseau en entier. Cette technique consiste à générer un trafic réseau important à destination de la machine (généralement serveur) sur laquelle le service tourne. Les limites de traitement de requête (trafic) en terme de temps et les capacités physique (mémoire processeurs, etc.) rendent le serveur instable ou le service inaccessible pour répondre à des nouvelles requêtes clients et donc soit il refuse les requêtes client ou se plante et du coup le service offert par le serveur sera arrêté.

• Distributed Denialof Service (DdoS): C'est une forme de DoS mais distribué, c'est à dire que le trafic réseau n'est pas uniquement généré par le même poste mais à partir de plusieurs sources. C'est donc, une multitude de machine s'attaquent à la même 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'accès à des fonctionnalités réservées généralement pour les tâches administratives. Ces fonctionnalités peuvent être sur une machine sur le réseau ou des droits sur le réseau lui-même. C'est généralement dû à une faille dans un service installé dans le réseau.

• Spoofing: L'attaquant injecte des paquets qui contiennent des adresses IP sources autorisées à 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 vulnérable a ce type d'attaque, ce qui résulte à un DoS qui déstabilise les services DNS.

• Empoisonnement du cache DNS (Attaque sur le cache de serveur):

C'est l'endroit idéal pour un attaquant d'injecter dans le cache d'un serveur de noms récursif un faux domaine. Supposant que le domaine voulu par le client est « shayol.org » à l'adresse IP « 88.176.64.22 », et on réponse le client reçoit le IP «  194.199.90.1 ». Le client ne va s'apercevoir de la gravité de sa requête, ni le serveur d'ailleurs. Car pour le client c'est transparent car lui l a demandé « shayol.org » et il l'a bien reçu mais pas la bonne adresse IP et ce même résultat sera propagé sur d'autres clients s’ils demandent le même nom « shayol.org » car le serveur de noms récupère l'adresse IP à partir de sa cache qui est empoisonnée. Empoisonner le cache d'un serveur de noms n'est pas l'envoie d'un simple paquet car l'acceptation d'une réponse sur un serveur de noms local récursif est basée sur des critères et conditions: Une technique de protection existe, mais qui n'est pas suffisante et donc non fiable.

• Une réponse arrive au serveur de noms local sur le même port UDP (ou TCP c'est le paquet est grand) de l'envoie de la requête question, si ce n'est pas le cas la requête réponse est ignorée.

• Le champ « Query » de paquet de réponse doit absolument contenir la même question posée par le serveur de noms qui est en attente à une réponse à sa question et qui porte le même QID(TXID) que le paquet de question.

• Les sections « Authority » et « Additional » représentent des noms qui appartiennent au même domaine que la question posée. C'est ces deux sections qui permettent de rediriger les requêtes de serveur de nom local vers les autorités sur le domaine demandé et les adresses IP des autorités afin d'éviter de nouvelles requêtes pour trouver les adresses IP des autorités pour le domaine recherché ou les serveurs de noms TLD.

Si toutes ces conditions sont satisfaites le serveur de noms local récursif acceptera le paquet comme une réponse à la requête question. La question qui se pose ici, c'est « Est ce que cela suffit pour dire que le paquet reçu est valide et sera accepté par le serveur de noms comme réponse? ». Si un attaquant arrive à trouver ou à prédire ces valeurs et envoyer au serveur de noms un paquet DNS réponse au serveur pour lui annoncer qu'il est autoritaire sur le domaine recherché. Le résultat sera dans le cache de serveur de noms, et tous les clients qui dépendent de ce serveur de noms seront piratés.

En général, l'attaquant trouve un serveur de noms vulnérable à ce type d'attaque,

8

par un balayage d'une des adresses IP de réseau 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 requête question envoyée vers son serveur de noms récursif 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 réussir à cette attaque, l'attaquant créera un site web qui est identique à l'original, et pour élever tout soupçon 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 nécessite l'envoie de plusieurs paquet vers le serveur de noms local récursif.

• 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 problème de sécurité des serveurs DNS et leurs vulnérabilité face aux attaques de type DDoS. Bien que ces attaques ne sont directement liées 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 problème qu'un attaquant peut compliquer la tâche d'empoisonner le cache DNS de serveur de noms local est de trouver le bon TXID.• Le pirate envoi une requête DNS vers le serveur de noms vulnérable à propos d'un hôte qui

veut empoisonner (www.shayol.org).• Au moment où le serveur de noms vulnérable effectue les recherches sur les serveurs de

noms. Après un moment le serveur fait des requêtes pour savoir le serveur de noms autoritaire sur la zone (shayol.org) qui est « ns.shayol.org ». Le pirate comme il connait déjà la question que le serveur de noms vulnérable, et là le pirate envoie à ce serveur sur le bon port UDP la repose qu'il voulait forgée (ns.shayol.org est à l'adresse IP 194.199.90.1).

• si le TXID de la requête réponse avec celui de la requête question de serveur vulnérable. Le serveur de noms vulnérable accepte la réponse de pirate (ns.shayol.org est à 194.199.90.1), et l’enregistre dans son cache pour un temps TTL définit par le pirate dans sa requête réponse forgée.

• A présent chaque client DNS configuré à contacter son serveur de noms vulnérable aura la mauvaise réponse car le serveur de noms consultera son cache qui a été empoisonnée par le pirate.

• Faille DNS de « Dan Kaminsky »:

Le problème avec l'exemple précédant est que la temps pour trouver le bon TXID entre l'envoi de la requête question de serveur de noms vulnérable sur internet et le brute-force de pirate pour trouver le bon TXID est très court. Et si le serveur de noms reçoit la réponse de la part e vrai serveur avant que le pirate ne réussisse à 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 à répondre à la requête de serveur de noms, et le pirate gagne plus de temps.

Kaminsky, lui propose une nouvelle approche. Au lieu de demander un hôte qui existe un demande des hôtes qui n'existent forcement pas (ns111111.shayol.org, puis ns111112.shayol.org et ainsi de suite). En plus que ces noms de hôte ne seront pas sur le cache de serveur de noms vulnérable et encore ils donnent plus de chance au pirate de tomber sur le bon TXID. Mais Kaminsky ne s'est pas arrêté là, au lieu d'empoisonner le cache d'un serveur vulnérable 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 vulnérable 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 »:

9

• Le pirate demande au serveur de noms vulnérable la résolution de nom de xyz.shayol.org.• Le pirate envoi au serveur de noms de requêtes réponse au serveur de noms, mais il glisse

dans les réponses 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 vulnérable va croire que c'est la bonne adresse IP et valide la réponse et l'enregistre dans son cache.

• Tout le trafic des clients de serveur de noms vulnérable 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 vulnérables:

Versions vulnérable à cette attaque:En effet, ce qui fait de cette faille très dangereuse est que elle n'est pas dépendante

d'une plateforme particulière ou une version ou autres, mais cette faille est exploitable si les conditions suivantes sont vérifiées: le serveur est récursif et utilise toujours le même port pour envoyer et recevoir ses requêtes et utilise UDP comme protocole. le TXID étant déjà aléatoire avec 64K valeurs possibles. Avec DNS la première réponse qui vérifie ces conditions est acceptée et s'il y a une après il l'ignore.

Parmi les versions qui sont vulnérable à 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 immédiatement (port source aléatoire) Utiliser DNSSEC (Domain Name System Security Extensions) pour protéger les échanges et les transferts des zones, cryptage pour authentifier les transactions

• Précaution:• 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 récentes dans « named.conf.options »

• Limiter la récursivité 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"; »• Désactiver le cache de serveur DNS et si besoin, installer un serveur de cache séparément

de serveur DNS. le serveur DNS peut être dans une DMZ (séparer physiquement les serveurs internes des serveurs externes)

• Faire des tests de l'extérieur pour vérifier la configuration de serveur DNS et voir également les anomalies qui peuvent arrivées et contrôler 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 modifiés le port source ce qui réduit l'efficacité de patch.

10

• Chaque serveur tourne sur un serveur dédié• 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 paramètres de l'attaque, entre autres l'adresse IP de serveur DNS récursif et qui utilise toujours le même port, le domaine à « spoofer ». En premier temps le programme crée un paquet « rep » avec les paramètres déjà initiés.

Ensuite le programme entre dans une boucle infinie « While 1 », et dans cette partie il génère un nouveau paquet « req » qui est envoyé avec l'adresse source de pirate, ce paquet envoie des requêtes « XXXX.shayol.org » avec XXXX est une valeur qui est incrémentée après chaque envoie la raison pour cela c'est pour générer plus de requêtes DNS pour sur domaine « shayol.org » et donc augmenter les chances de faire l'empoisonnement de cache de serveur vulnérable, 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 déjà dans le cache de serveur vulnérable cela empêche une nouvelle tentative d'empoisonnement mais il faut attendre l'expiration de TTL de l'enregistrement de « shayol.org » dans le cache.

Après l'envoie de paquet généré par le pirate vers les serveurs DNS récursif, le pirate crée une réponse à la requête qui a lui-même déjà posé au serveur. Et donc le pirate reprend les mêmes paramètres de sa question précédente dans la requête « req », il a tenté de faire persuader le serveur DNS qui ce nouveau paquet est la réponse à la requête "req". Pour le faire il va utiliser le paquet « rep » forgé avec les bons paramètres. le paquet « rep » est donc une réponse créée par l'attaquant qui contient comme adresse source « 194.199.90.1 » et en adresse destination l'IP de serveur DNS récursif vulnérable. Mais « rep » nécessite quelque modification, dans le champ question et le champ réponse qui doivent contenir « XXXX.shayol.org ». Après cela, le pirate commence à envoyer des réponses forgées au serveur DNS vulnérable dans une boucle finie (50 fois dans le programme), qui incrémente la valeur de champ TXID (Transaction Identifier ou QID: Query Identifier) de paquet « rep » et envoie le tout vers le serveur DNS.

Après la fin de la boucle de réponse forgée « rep » le programme teste le résultat de l'envoie de ces réponse au serveur DNS, ici ce n'est pas important si on teste ceci après chaque envoie car en cas de succès on ne va pas chercher le résultat ailleurs mais seulement au niveau de cache de notre serveur DNS et là c'est le pirate qui va lancer une nouvelle fois sa requête question « req » mais cette fois sans demande d'utilisé la récursivité. Et donc si on a un résultat, c'est à dire une réponse à la question « Quelle est l'adresse IP de shayol.org ? » de la part de serveur DNS vulnérable, réponse 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 réussi à empoisonner le cache de serveur sinon on réessaye encore et encore jusqu'au succès de l'attaque. Si le serveur est vulnérable l'attaque généralement réussie sauf en cas d'interruption de a part de l'attaquant.

En ce qui concerne l'exécution de script python à ce moment on n’a pas réussi à le faire tourner, cependant on a réussi à le faire marcher mais en « Metasploit » avec les options suivantes:msf auxiliary(bailiwicked_host) >Module options:

HOSTNAME ns.shayol.org yes Hostname to hijack INTERFACE no The name of the interface

11

NEWADDR 194.199.90.1 yes New address for hostname RECONS 208.67.222.222 yes The name server used for reconnaissance RHOST 192.168.32.128 yes The target address SNAPLEN 65535 yes The number of bytes to capture SRCADDR Real yes The source address to use for sending the queries (accepted: Real, Random) SRCPORT 53 yes The target server's source query port (0 for automatic) TIMEOUT 500 yes The number of seconds to wait for new data TTL 47410 yes The TTL for the malicious host entry XIDS 0 yes The number of XIDs to try for each query (0 for automatic)

Avec 192.168.32.128 adresse de serveur de nom vulnérable.

• Conclusion:

La sécurité de DNS est une problématique pour les expert en sécurité. En effet les requêtes sur internet son basée sur les requêtes DNS, si un problème de sécurité est signalé ça sera la panique sur ce réseau surtout quand il s'agit d'une faille de très 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 protéger les transactions. Reste à voir est ce que cette extension est efficace en terme de sécurité. Il faut préciser que aujourd'hui existe toujours de serveur de noms qui ne sont pas encore protégés contre les attaques récentes. Kaminsky avait le grande générosité de publier sa découverte après avoir prévenu les développeurs des logiciels mais il y a des gens qui gardent leurs découvertes pour mettre des buts destructifs.

Bibliographie:

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

12