IUT Montpellier - Architecture (DU) V. Poupet

TD no 8 - Domain Name System (DNS)

Dans ce TD nous allons nous intéresser au fonctionnement du Domain Name System (DNS), puis pourillustrer son fonctionnement, à une faille de sécurité découverte par Dan Kaminsky en 2008 permettantd’empoisonner le cache d’un serveur DNS afin de prendre le contrôle d’un domaine.

Exercice 1. Fonctionnement général

DNS est un acronyme signifiant Domain Name System. C’est un protocole permettant d’associer à desnoms de domaine (par exemple www.chezmoi.fr) une adresse IP (par exemple 140.78.132.45). Lesmachines se connectent entre-elles à l’aide d’adresses IP, mais les noms de domaine servent à faciliter lamémorisation et l’utilisation pour les humains et permettent également de structurer hierarchiquementl’ensemble du réseau (en domaines, sous-domaines, etc.).

Lorsqu’un utilisateur veut contacter la machine nommée www.banque.net, il doit obtenir son adresseIP. Ceci se fait en plusieurs étapes (illustrées sur la Figure 1) :

a. le client demande l’IP de www.banque.net au serveur DNS de son fournisseur d’accès à Internet(FAI) ;

b. le serveur DNS du FAI ne connaît pas l’adresse. Il demande alors au serveur DNS responsable detous les noms de domaines 1 (a.root-servers.net) l’adresse de www.banque.net ;

c. bien évidemment, ce serveur ne connaît pas toutes les adresses. Mais il sait que le serveur res-ponsable du domaine .net est b.gtld.servers.net. Il renvoie alors le nom et l’adresse IP dece serveur ;

d. le FAI demande alors à ce serveur l’adresse de www.banque.net ;e. le DNS du domaine .net renvoie alors le nom et l’adresse du serveur DNS responsable du do-

maine .banque.net ;f. le FAI interroge ce dernier serveur DNS, qui connaît l’adresse de la machine www.banque.net

et la lui envoie ;g. le serveur DNS du FAI peut finalement renvoyer l’adresse IP de la machine demandée par l’uti-

lisateur.

En pratique les serveurs DNS des FAI mémorisent les réponses aux questions qu’ils ont posées dansun cache, ce qui leur permet d’éviter de faire certaines requêtes s’ils connaissent déjà la réponse.

1. Quels sont les avantages apportés par l’utilisation d’un cache pour le FAI, les serveurs DNS (parti-culièrement ceux de haut niveau et ceux correspondant à des domaines très demandés, par exemplegoogle.com) et l’utilisateur ?

R. Le cache permet de limiter le nombre de requêtes effectuées sur les serveurs les plus demandés etd’accélérer la réponse. Pour le FAI, il y a moins de traffic avec l’extérieur puisque les réponses auxrequêtes DNS les plus fréquentes (par exemple l’adresse du domaine .fr ou d’un domaine commegoogle.com) sont déjà connues (dans le cache) et qu’il n’est donc pas nécessaire d’aller demanderaux domaines concernés.Pour les domaines les plus demandés, le fait que les FAI utilisent des caches permet de ne passurcharger leurs serveurs (imaginez si chaque fois qu’un personne voulait accéder à un élémentquelconque du domaine .com il fallait faire une requête sur le serveur !). En pratique, les serveursde plus haut niveau (les serveurs racines, et les serveurs des domaines .com, .fr, etc.) sont assezpeu sollicités puisque seuls les FAI les interrogent directement et comme leur IP ne change presquejamais, la réponse est gardée dans le cache pendant longtemps.Enfin, même les utilisateurs en profitent puisque les réponses à leurs requêtes sont plus rapides sielles sont connues par leur FAI.

1. Parce qu’il faut bien pouvoir commencer quelque part, tous les FAI connaissent les adresses des serveursDNS de plus haut niveau. Ces serveurs sont très importants et leurs adresses ne changent pas.

1

FIGURE 1 – Exemple de communications lors d’une requête DNS.

2. N’importe qui peut créer un serveur DNS qui prétend connaître les adresses IP des machinesd’un domaine donné (et qui pourrait donc donner de fausses adresses IP). Pourquoi n’est-ce pas unproblème ?

R. Si quelqu’un met en place un serveur DNS qui prétend donner des adresses IP correspondantà un domaine déjà existant, aucun des serveurs DNS ne renverra les utilisateurs sur ce nouveauserveur et donc aucune requête n’arrivera sur ce faux serveur.Lorsque l’on achète un nom de domaine, on déclare le serveur DNS qui lui est associé afin qu’il soitconnu des serveurs du niveau supérieur. Un serveur qui n’est pas référencé par le niveau supérieurn’est jamais atteint.

Exercice 2. Détail des communications

Les messages DNS sont échangés selon le protocole User Datagram Protocol (UDP). Les commu-nications UDP sont beaucoup plus simples qu’en TCP car elles ne nécessitent pas l’ouverture d’unecommunication entre les deux participants, le message est directement envoyé à son destinataire sansque celui-ci ait à répondre. Bien que plus simple, UDP présente deux inconvénients par rapport à TCP :d’une part il n’est pas tolérant aux erreurs et d’autre part il n’est pas possible de s’assurer de l’adresseIP dont provient un message.

Une communication DNS contient entre autres les informations suivantes :– les adresse IP et port de l’émetteur ;– les adresse IP et port du destinataire ;– le numéro de requête ;– la question posée et les réponses éventuelles (« Quelle est l’adresse de la machine xxx.yyy.zzz ? », « Demander au serveur xxx.yyy.zzz. » ou encore « L’adresse de xxx.yyy.zzz est aa.bb.cc.dd. »)

Le numéro de requête est fixé par la machine qui émet une requête DNS. Cela permet en particulier desavoir à quelle question correspond une réponse reçue. Lorsque le message est une réponse, on rappelle

2

également la question qui avait initialement été posée.

1. Les adresses qui apparaissent dans le message sont écrites par l’émetteur du message. En par-ticulier, l’adresse de l’émetteur peut être falsifiée. Pourquoi est-il absurde de falsifier l’adresse dudestinataire ?

R. Un paquet UDP est transmis de serveur en serveur jusqu’au destinataire qui est indiqué sur lepaquet. S’il est vrai qu’on peut mettre n’importe quelle adresse d’émetteur (en faisant croire qu’on nefait que transmettre un paquet qui provient de quelqu’un d’autre), changer l’adresse du destinatairerevient à changer le destinataire.La situation est identique à celle du courrier papier : on peut mettre n’importe quelle adresse d’émet-teur au dos de l’enveloppe, mais l’adresse sur la face principale est forcément celle du vrai destina-taire puisque c’est à lui que sera transmise l’enveloppe.

Lorsqu’un serveur DNS indique une adresse dans une réponse, cette réponse est accompagnée d’unedurée appelée Time to Live (TTL) qui correspond à la durée de validité de l’information transmise. Leserveur qui reçoit l’information ne doit donc la conserver dans son cache que pendant la durée indiquée.

2. Pourquoi est-il important de limiter la durée de vie des informations dans le cache ? Expliquezpourquoi certaines adresses IP peuvent être gardées en mémoire plus longtemps que d’autres. Pour-quoi est-il important de bien estimer l’ordre de grandeur des TTL ? (quels sont les inconvénientsd’un TTL trop petit ou trop grand)

R. Indépendamment de problèmes d’empoisonnement que nous allons voir par la suite, les infor-mations dans le cache ne doivent pas être éternelles parce que les adresses IP des machines changentau cours du temps.Ainsi, si un FAI apprend que l’adresse du serveur responsable du domaine youpi.tralala.frest 138.67.123.43 et qu’il décide de stocker cette adresse pendant 10 jours (si le TTL indiqué parle serveur au moment de la première réponse est de 10 jours), mais que le lendemain l’adresse IPdu serveur responsable du domaine change, alors pendant 9 jours le FAI aura une adresse erronéedans son cache. Si l’ancienne adresse n’est plus utilisée du tout, le FAI se rendra compte de l’erreuret redemandera probablement l’adresse du serveur au niveau supérieur. Mais si cette adresse IPcorrespond à une machine différente, alors le serveur du FAI renverra toutes les requêtes concernantle domaine youpi.tralala.fr à cette machine, ce qui peut entraîner des risques de sécurité, ouune surcharge sur la machine ciblée.Il est donc important de bien estimer le TTL d’un serveur en fonction du temps qu’il reste avant unchangement. Si l’on choisit un TTL trop court sur un domaine très demandé, il recevra énormémentde requêtes (une nouvelle de la part de chaque FAI à l’expiration du TTL). Mais si on choisit unTTL trop long et que l’adresse change avant la fin du TTL, celà provoque une période intermédiairependant laquelle les informations contenues dans le cache du FAI sont fausses.En pratique, les serveurs des domaines très demandés changent très rarement d’adresse ce qui per-met d’attribuer des TTL assez longs (de plusieurs jours) aux réponses envoyées. Lorsque l’on saità l’avance qu’on va devoir changer un serveur on attend l’expiration de tous les TTL des réponsesqui ont été données renvoyant sur ce serveur avant de l’arrêter (pendant la période intermédiaire,on renvoie toutes les nouvelles requêtes sur un serveur différent).

De plus, lorsqu’on interroge un serveur qui ne connaît pas directement l’adresse demandée, il renvoienon seulement le nom du nouveau serveur à interroger mais également son adresse IP. Ces informationssupplémentaires (liste de noms de serveurs et adresses associées) sont appelées glue records et servent àéviter les boucles infinies de requêtes.

3. Expliquez sur l’exemple du début de l’exercice ce qui se passerait s’il n’y avait pas de glue record,c’est-à-dire si les serveurs DNS se contentaient de donner le nom du serveur suivant à interroger,sans donner son adresse.Indication : le serveur b.gtld.servers.net appartient lui-même au domaine dont il est respon-sable...

3

R. Lorsque l’on demande l’adresse de la machine recherchée, et qu’un serveur DNS nous indiquequ’il faut interroger le serveur b.gtld.servers.net qui est responsable de ce domaine, s’il nenous donne pas l’adresse IP de cette machine, il faut faire une requête DNS pour obtenir l’IP du ser-veur. Or cette requête DNS va de nouveau nous rediriger vers ce même serveur (puisqu’il appartientà un domaine dont il est responsable), ce qui entraînerait une nouvelle requête DNS pour la mêmeinformation...Afin d’éviter cette boucle infinie, certains serveurs connaissent directement les IP des serveurs surlesquels ils renvoient et peuvent les ajouter à leurs réponses.

Exercice 3. L’attaque simple

Le but de l’attaque consiste à envoyer à un serveur DNS des informations fausses afin d’empoisonnerson cache. Par exemple, quelqu’un essaiera de faire croire au DNS du FAI que l’adresse de la machinewww.banque.net est 140.10.11.12 alors qu’en réalité cette adresse est l’adresse d’une machine qu’ilcontrôle.

1. Pourquoi quelqu’un voudrait-il empoisonner le cache d’un serveur DNS ?

R. Falsifier des données de DNS peut permettre à une personne de prendre le contrôle d’un do-maine. En effet, si un utilisateur parvient à faire croire à un certain FAI que le serveur responsablede toutes les adresses sur un domaine donné est une machine lui appartenant, et que cette adresseest enregistrée dans le cache du FAI, toutes les requêtes effectuées par des clients du FAI sur ledomaine en question seront renvoyées vers la machine de l’attaquant. Si cette machine envoie desréponses qui ressemblent assez au site (ou n’importe quel autre service informatique) que les utili-sateurs attendent, ils ne se rendront pas compte qu’ils ne sont pas en train de communiquer avec lebon domaine.L’attaquant peut alors obtenir des informations confidentielles (que seul le serveur que le clientvoulait atteindre devrait connaître) ou bien donner de fausses informations au client en se faisantpasser pour le domaine usurpé.

2. Quelles sont les personnes affectées par l’attaque ?

R. Les personnes qui sont affectées par un empoisonnement de cache DNS sont les personnes quieffectuent des requêtes DNS sur le serveur empoisonné. Ainsi, si l’on arrive à falsifier l’entrée ducache d’un FAI contenant l’adresse du serveur d’un certain domaine, tous les utilisateurs de ce FAIqui feront des requêtes DNS sur ce domaine recevront de fausses informations.Il est important de voir que la durée de l’attaque correspond au TTL de l’information falsifiée. Maiscomme cette dernière information est donnée par l’attaquant, le TTL est en général très long afind’augmenter la durée.

3. Le phishing est une technique visant à attirer un utilisateur vers un site qui ressemble à un site sen-sible (banque, achat en ligne, etc.) pour lui faire envoyer ses informations bancaires ou personnelles.En général, on utilise des liens hyper-texte pour amener l’utilisateur sur le faux site.La plupart des attaques de phishing reposent sur le fait que l’adresse réelle du faux site ressemblefortement à l’adresse du site imité.En quoi l’empoisonnement de cache DNS est-il similaire à du phishing ? En quoi l’attaque DNS est-elle plus puissante que les techniques de phishing ?

R. Sur le principe, les deux attaques sont similaires : diriger un utilisateur vers un site contrôlépar l’attaquant, se faisant passer pour le site sensible afin d’obtenir des informations confidentielles.Toutefois l’empoisonnement de cache DNS est plus subtile et bien plus difficile à détecter (quasimentimpossible du point de vue de l’utilisateur).La plupart des attaques de fishing peuvent être évitées par un utilisateur attentif qui vérifie lesadresses des liens avant de cliquer. Dans le cas du DNS c’est le FAI qui envoie une informationfausse (alors que l’utilisateur fait confiance au FAI) et il n’y a aucun moyen de savoir que cetteinformation est fausse (à moins de connaître toutes les distributions d’adresses IP, ou bien de fairetoutes les requêtes DNS en double à différents serveurs...).

4

Pour réussir à empoisonner le cache DNS, il faut envoyer une réponse au serveur de telle sorte qu’ilcroie que c’est une réponse à une question qu’il a posée... Pour qu’une réponse soit acceptée par leserveur qui a posé la question il faut :

– qu’elle arrive sur le bon port de communication ;– que la question rappelée dans le message corresponde à une question posée par le serveur ;– que le numéro de requête corresponde à celui qui avait été décidé par le serveur dans la question ;– que les adresses données dans la réponse (glue records) correspondent toutes à des noms de ma-

chines se trouvant dans le même domaine que le nom demandé initialement (si l’on demandel’adresse de www.banque.net on n’acceptera pas les messages qui prétendent donner l’adressede la machine www.google.com).

4. Expliquez l’intérêt de la dernière contrainte.Indication : N’importe qui peut ouvrir un nom de domaine quelconque puis contrôler totalementle serveur DNS correspondant à ce nom de domaine. Que se passerait-il alors si cette personnedemandait au DNS de son FAI l’adresse d’une machine se trouvant dans son domaine ?

R. Il est capital de ne pas accepter d’informations sous forme de glue records concernant des domainesextérieurs au domaine demandé. En effet, sinon il suffirait à un utilisateur quelconque possédant unnom de domaine (ce qui est à la portée de n’importe qui) de dire à son serveur DNS que lorsquel’on effectue une requête sur son domaine, il renvoie sous forme de glue record une fausse adresseIP correspondant à un domaine important (par exemple le domaine d’une banque). Il est normalque le FAI fasse confiance au serveur de l’utilisateur pour tout ce qui concerne son domaine (il n’aaucun intérêt à donner de fausses adresses concernant son propre domaine) mais il ne faut surtoutpas faire confiance à n’importe quel serveur DNS en ce qui concerne des informations sur les autresdomaines.Dans l’exemple précédent, si le FAI ne tient compte que des glue records concernant le domainedemandé, la fausse adresse du domaine de la banque sera ignorée.

La seule information difficile à deviner est le numéro de requête. Cependant, beaucoup de serveursDNS se contentent d’incrémenter d’un le numéro à chaque requête qu’ils envoient, il est donc très facilede deviner un numéro de requête si l’on en reçoit une...

5. Comment un utilisateur malveillant peut-il obtenir le numéro de requête courant du serveur DNSde son FAI ? (utiliser l’indication de la question précédente)

R. Pour avoir le numéro de requête courant d’un serveur, il faut recevoir une requête de la part dece serveur (puisque si on reçoit une requête, cette requête contiendra le numéro). Il est très facilepour un utilisateur de forcer le serveur DNS de son FAI à lui envoyer une requête : il suffit decontrôler un domaine personnel sur lequel on contrôle le serveur DNS et de faire une requête surune machine quelconque de ce domaine. Pour obtenir l’adresse IP du serveur demandé, le FAI vafaire des requêtes DNS en descendant dans la hiérarchie jusqu’à ce qu’on le redirige vers le DNSdu serveur demandé (contrôlé par l’utilisateur), qui recevra donc le numéro de requête courant duserveur DNS de son FAI.Si l’utilisateur veut de nouveau trouver le numéro courant du serveur du FAI alors que l’adresse dela machine qu’il avait demandée est dans le cache du serveur (dans ce cas il n’y aurait pas de nou-velle requête), il suffit de demander l’adresse d’une autre machine dans le même domaine (même sicette machine n’existe pas, il faut une requête DNS pour que le FAI sache qu’elle n’existe pas).

6. Que se passe-t-il si l’utilisateur malveillant demande à son FAI l’adresse de www.banque.netpuis immédiatement après envoie une fausse réponse DNS contenant la bonne question, le bonnuméro de requête (qu’il connaît par la méthode de la question précédente) et qui prétend quel’adresse IP de la machine www.banque.net est l’adresse IP d’une machine qu’il contrôle ? (onsuppose que l’adresse de www.banque.net n’est pas dans le cache du serveur DNS du FAI).

R. Au moment où le FAI reçoit la requête de l’utilisateur, il va effectuer une requête DNS pourobtenir l’adresse de la machine www.banque.net (qu’il ne connaît pas puisqu’elle n’est pas dansson cache). L’utilisateur connaît alors tous les paramètres de la requête (il sait quelle est la machine

5

demandée, le port sur lequel communique le serveur de son FAI, le numéro de requête, etc.) et peutdonc écrire et envoyer au serveur DNS de son FAI une fausse réponse. Si cette réponse arrive avant laréponse du vrai serveur DNS qui a été interrogé pendant ce temps, le serveur du FAI la considèreracomme correcte et enregistrera la nouvelle information dans son cache.La réponse du vrai serveur arrivera également par la suite, mais comme elle répond à une questionpour laquelle le serveur du FAI a déjà eu une réponse elle sera ignorée.

En pratique, cette attaque est très difficile à réaliser car il faut à la fois que le cache du FAI ne contiennepas l’adresse demandée et que la réponse envoyée arrive avant celle du véritable DNS du site attaqué(par ailleurs il faut deviner du premier coup le bon numéro de requête ce qui n’est pas si facile si l’onconsidère des gros FAI qui reçoivent énormément de requêtes DNS)...

Exercice 4. La version améliorée

On peut cependant améliorer grandement les chances de réussir l’attaque en falsifiant non plusl’adresse d’une machine, mais en prenant le contrôle de tout le domaine correspondant à l’aide desglue records...

1. Que se passe-t-il si un utilisateur demande au DNS de son FAI l’adresse de la machine bidon01.banque.net, puis envoie immédiatement une réponse contenant la bonne question, un numéro derequête qui a de fortes chances d’être correct et qui prétend que le serveur responsable du domaine.banque.net est ns.banque.net et que son adresse est l’adresse d’une machine qu’il contrôle ?

R. Toute l’astuce de cette nouvelle attaque est d’utiliser les glue records en envoyant de fausses infor-mations concernant le domaine demandé (donc à la différence de ce qui a été discuté à la question10, ici les informations données correspondent à ce que le serveur attend et seront donc prises encompte).Si la réponse envoyée par l’attaquant arrive avant la vraie réponse du serveur DNS de banque.net,elle sera considérée comme vraie. Le serveur du FAI va non seulement considérer que l’adressedonnée pour la machine bidon01.banque.net est correcte (mais cette machine est sans intérêt,et n’existe même probablement pas), mais surtout il va tenir compte des glue records et considérerque ces informations qu’il vient de recevoir sont justes et plus récentes que celles qui sont dans lecache. Le serveur du FAI va donc mettre à jour son cache en changeant l’adresse qu’il connaissait duserveur de banque.net.Ainsi, si l’attaquant parvient à envoyer sa réponse avant le véritable serveur DNS (ce qui n’est pas sidifficile étant donné qu’il peut envoyer la réponse avant même que la requête soit arrivée au serveurDNS ciblé) et qu’il connaît le numéro de requête (c’est moins facile, mais faisable, et comme on va levoir dans la question suivante, on peut recommencer l’attaque autant de fois que nécessaire), il auraeffectivement empoisonné l’entrée DNS du FAI concernant tout le domaine banque.net.Notons qu’à ce stade, il n’y a plus de raison que l’erreur soit corrigée. À partir de là toutes les re-quêtes faites par le FAI vers le domaine banque.net seront envoyées à la machine de l’attaquant etplus aucune n’atteindra le vrai serveur DNS du domaine. Il n’y a donc aucune raison qu’un nouveauglue record vienne écraser l’information falsifiée.

2. En supposant que la tentative décrite dans la question précédente échoue (la réponse du vraiserveur arrive avant la fausse), comment peut-on répéter l’attaque même si le serveur a enregistré laréponse précédente dans son cache ?

R. Il suffit de refaire une requête vers une autre machine du même serveur (par exemple bidon02.banque.net) qui elle n’est pas dans le cache du FAI. Cela provoque une nouvelle requête ce quidonne une nouvelle chance d’insérer une fausse réponse avant celle du véritable serveur.

3. Lorsque l’attaquant a finalement réussi à faire passer sa réponse pour une vraie réponse DNS, quese passe-t-il si un autre utilisateur du même FAI essaie de se connecter à la machine www.banque.net ?

6

R. Si la véritable adresse de www.banque.net est encore dans le cache du FAI, il ne se passerarien. Mais cette information finira bien par expirer. Et comme c’est l’attaquant qui a fixé le TTL de lafausse information qu’il a transmise au serveur du FAI, la fausse information durera plus longtempsque les informations correctes.Une fois que l’adresse de www.banque.net expire du cache du FAI, lorsqu’un utilisateur essaie decontacter cette machine, le FAI fait une requête DNS au serveur du domaine banque.net. Commel’adresse de ce serveur est dans son cache, le FAI s’adresse directement au serveur indiqué par lecache, qui est une machine contrôlée par l’attaquant. Ainsi, la réponse à la requête de l’utilisateurest totalement contrôlée par l’attaquant, qui peut facilement rediriger l’utilisateur vers une machine(et donc un site) qu’il contrôle entièrement. L’adresse de cette machine sera donc enregistrée dans lecache du FAI (probablement avec un TTL très long puisqu’il est fixé par l’attaquant) et tous les autresutilisateurs qui demandent cette machine seront également redirigés vers la machine de l’attaquant.

4. Proposez quelques solutions pour limiter le risque d’une telle attaque.

R. La première solution est d’utiliser des numéros de requête aléatoires au lieu de les prendre dansl’ordre. En effet, toute l’attaque repose sur le fait que l’attaquant parvient à envoyer au serveur duFAI une réponse contenant le bon numéro de requête, alors qu’il n’a jamais reçu la requête (puis-qu’elle est envoyée au vrai serveur DNS du domaine attaqué). En prendant des numéros de requêtealéatoirement, il devient plus difficile de fabriquer une réponse valide. Toutefois, comme l’attaquepeut être répétée autant de fois que voulu, il est envisageable qu’elle finisse par fonctionner. Lesnuméros de requête sont codés sur 16 bits (donc 65536 possibilités), ce qui n’est pas énorme et onfinirait par deviner le bon à force d’essayer.On pourrait envisager d’augmenter le nombre de numéros différents (en passant par exemple sur 32bits) ce qui diminuerait considérablement les chances de réussite de l’attaque, mais cela nécessiteraitde changer le protocole DNS ce qui n’est pas réalisable en pratique car tout Internet repose surce protocole (et le changer correspond à une quantité de mise à jours trop importante et surtoutprovoquerait des pannes bien trop importantes).Une autre solution consiste à utiliser une plus grande plage de ports différents pour les requêteset réponses. En général, un serveur DNS utilise toujours le même port, ce qui rend l’attaque facilepuisqu’il est facile de découvrir le port utilisé. Si toutefois on décide d’utiliser une plus grandeplage de ports, sélectionnés aléatoirement pour chaque requête, le nombre de combinaisons devientbien plus grand (avec 2500 ports ouverts, ce qui correspond à ce que peuvent utiliser certains DNScouramment utilisés, le nombre de combinaisons de port et numéro de requête est d’environ 130millions).

7