TD n o 8 - Domain Name System (DNS)

Transcription

1 IUT Montpellier - Architecture (DU) V. Poupet TD n o 8 - Domain Name System (DNS) Dans ce TD nous allons nous intéresser au fonctionnement du Domain Name System (DNS), puis pour illustrer son fonctionnement, à une faille de sécurité découverte par Dan Kaminsky en 2008 permettant d 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 à des noms de domaine (par exemple une adresse IP (par exemple ). Les machines se connectent entre-elles à l aide d adresses IP, mais les noms de domaine servent à faciliter la mémorisation et l utilisation pour les humains et permettent également de structurer hierarchiquement l ensemble du réseau (en domaines, sous-domaines, etc.). Lorsqu un utilisateur veut contacter la machine nommée il doit obtenir son adresse IP. Ceci se fait en plusieurs étapes (illustrées sur la Figure 1) : a. le client demande l IP de 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 de tous les noms de domaines 1 (a.root-servers.net) l adresse de ; c. bien évidemment, ce serveur ne connaît pas toutes les adresses. Mais il sait que le serveur responsable du domaine.net est b.gtld.servers.net. Il renvoie alors le nom et l adresse IP de ce serveur ; d. le FAI demande alors à ce serveur l adresse de ; e. le DNS du domaine.net renvoie alors le nom et l adresse du serveur DNS responsable du domaine.banque.net ; f. le FAI interroge ce dernier serveur DNS, qui connaît l adresse de la machine et la lui envoie ; g. le serveur DNS du FAI peut finalement renvoyer l adresse IP de la machine demandée par l utilisateur. En pratique les serveurs DNS des FAI mémorisent les réponses aux questions qu ils ont posées dans un 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 (particulièrement ceux de haut niveau et ceux correspondant à des domaines très demandés, par exemple google.com) et l utilisateur? R. Le cache permet de limiter le nombre de requêtes effectuées sur les serveurs les plus demandés et d accélérer la réponse. Pour le FAI, il y a moins de traffic avec l extérieur puisque les réponses aux requêtes DNS les plus fréquentes (par exemple l adresse du domaine.fr ou d un domaine comme google.com) sont déjà connues (dans le cache) et qu il n est donc pas nécessaire d aller demander aux domaines concernés. Pour les domaines les plus demandés, le fait que les FAI utilisent des caches permet de ne pas surcharger leurs serveurs (imaginez si chaque fois qu un personne voulait accéder à un élément quelconque du domaine.com il fallait faire une requête sur le serveur!). En pratique, les serveurs de plus haut niveau (les serveurs racines, et les serveurs des domaines.com,.fr, etc.) sont assez peu sollicités puisque seuls les FAI les interrogent directement et comme leur IP ne change presque jamais, 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 si elles sont connues par leur FAI. 1. Parce qu il faut bien pouvoir commencer quelque part, tous les FAI connaissent les adresses des serveurs DNS de plus haut niveau. Ces serveurs sont très importants et leurs adresses ne changent pas. 1

2 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 machines d un domaine donné (et qui pourrait donc donner de fausses adresses IP). Pourquoi n est-ce pas un problè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 nouveau serveur 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 soit connu des serveurs du niveau supérieur. Un serveur qui n est pas référencé par le niveau supérieur n est jamais atteint. Exercice 2. Détail des communications Les messages DNS sont échangés selon le protocole User Datagram Protocol (UDP). Les communications UDP sont beaucoup plus simples qu en TCP car elles ne nécessitent pas l ouverture d une communication entre les deux participants, le message est directement envoyé à son destinataire sans que 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 adresse IP 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 de savoir à quelle question correspond une réponse reçue. Lorsque le message est une réponse, on rappelle 2

3 é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 particulier, l adresse de l émetteur peut être falsifiée. Pourquoi est-il absurde de falsifier l adresse du destinataire? R. Un paquet UDP est transmis de serveur en serveur jusqu au destinataire qui est indiqué sur le paquet. S il est vrai qu on peut mettre n importe quelle adresse d émetteur (en faisant croire qu on ne fait que transmettre un paquet qui provient de quelqu un d autre), changer l adresse du destinataire revient à changer le destinataire. La situation est identique à celle du courrier papier : on peut mettre n importe quelle adresse d émetteur au dos de l enveloppe, mais l adresse sur la face principale est forcément celle du vrai destinataire 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 une durée appelée Time to Live (TTL) qui correspond à la durée de validité de l information transmise. Le serveur 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? Expliquez pourquoi certaines adresses IP peuvent être gardées en mémoire plus longtemps que d autres. Pourquoi est-il important de bien estimer l ordre de grandeur des TTL? (quels sont les inconvénients d un TTL trop petit ou trop grand) R. Indépendamment de problèmes d empoisonnement que nous allons voir par la suite, les informations dans le cache ne doivent pas être éternelles parce que les adresses IP des machines changent au cours du temps. Ainsi, si un FAI apprend que l adresse du serveur responsable du domaine youpi.tralala.fr est et qu il décide de stocker cette adresse pendant 10 jours (si le TTL indiqué par le serveur au moment de la première réponse est de 10 jours), mais que le lendemain l adresse IP du serveur responsable du domaine change, alors pendant 9 jours le FAI aura une adresse erronée dans son cache. Si l ancienne adresse n est plus utilisée du tout, le FAI se rendra compte de l erreur et redemandera probablement l adresse du serveur au niveau supérieur. Mais si cette adresse IP correspond à une machine différente, alors le serveur du FAI renverra toutes les requêtes concernant le domaine youpi.tralala.fr à cette machine, ce qui peut entraîner des risques de sécurité, ou une 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 un changement. Si l on choisit un TTL trop court sur un domaine très demandé, il recevra énormément de requêtes (une nouvelle de la part de chaque FAI à l expiration du TTL). Mais si on choisit un TTL trop long et que l adresse change avant la fin du TTL, celà provoque une période intermédiaire pendant 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 permet 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éponses qui 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 renvoie non seulement le nom du nouveau serveur à interroger mais également son adresse IP. Ces informations supplé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 responsable... 3

4 R. Lorsque l on demande l adresse de la machine recherchée, et qu un serveur DNS nous indique qu il faut interroger le serveur b.gtld.servers.net qui est responsable de ce domaine, s il ne nous donne pas l adresse IP de cette machine, il faut faire une requête DNS pour obtenir l IP du serveur. 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ême information... Afin d éviter cette boucle infinie, certains serveurs connaissent directement les IP des serveurs sur lesquels 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 empoisonner son cache. Par exemple, quelqu un essaiera de faire croire au DNS du FAI que l adresse de la machine est alors qu en réalité cette adresse est l adresse d une machine qu il contrô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 domaine. En effet, si un utilisateur parvient à faire croire à un certain FAI que le serveur responsable de toutes les adresses sur un domaine donné est une machine lui appartenant, et que cette adresse est enregistrée dans le cache du FAI, toutes les requêtes effectuées par des clients du FAI sur le domaine en question seront renvoyées vers la machine de l attaquant. Si cette machine envoie des réponses qui ressemblent assez au site (ou n importe quel autre service informatique) que les utilisateurs attendent, ils ne se rendront pas compte qu ils ne sont pas en train de communiquer avec le bon domaine. L attaquant peut alors obtenir des informations confidentielles (que seul le serveur que le client voulait atteindre devrait connaître) ou bien donner de fausses informations au client en se faisant passer 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 qui effectuent des requêtes DNS sur le serveur empoisonné. Ainsi, si l on arrive à falsifier l entrée du cache d un FAI contenant l adresse du serveur d un certain domaine, tous les utilisateurs de ce FAI qui 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. Mais comme cette dernière information est donnée par l attaquant, le TTL est en général très long afin d augmenter la durée. 3. Le phishing est une technique visant à attirer un utilisateur vers un site qui ressemble à un site sensible (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 ressemble fortement à l adresse du site imité. En quoi l empoisonnement de cache DNS est-il similaire à du phishing? En quoi l attaque DNS estelle 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 (quasiment impossible du point de vue de l utilisateur). La plupart des attaques de fishing peuvent être évitées par un utilisateur attentif qui vérifie les adresses des liens avant de cliquer. Dans le cas du DNS c est le FAI qui envoie une information fausse (alors que l utilisateur fait confiance au FAI) et il n y a aucun moyen de savoir que cette information est fausse (à moins de connaître toutes les distributions d adresses IP, ou bien de faire toutes les requêtes DNS en double à différents serveurs...). 4

5 Pour réussir à empoisonner le cache DNS, il faut envoyer une réponse au serveur de telle sorte qu il croie que c est une réponse à une question qu il a posée... Pour qu une réponse soit acceptée par le serveur 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 machines se trouvant dans le même domaine que le nom demandé initialement (si l on demande l adresse de on n acceptera pas les messages qui prétendent donner l adresse de la machine 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 totalement le serveur DNS correspondant à ce nom de domaine. Que se passerait-il alors si cette personne demandait 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 domaines extérieurs au domaine demandé. En effet, sinon il suffirait à un utilisateur quelconque possédant un nom de domaine (ce qui est à la portée de n importe qui) de dire à son serveur DNS que lorsque l on effectue une requête sur son domaine, il renvoie sous forme de glue record une fausse adresse IP correspondant à un domaine important (par exemple le domaine d une banque). Il est normal que le FAI fasse confiance au serveur de l utilisateur pour tout ce qui concerne son domaine (il n a aucun intérêt à donner de fausses adresses concernant son propre domaine) mais il ne faut surtout pas faire confiance à n importe quel serveur DNS en ce qui concerne des informations sur les autres domaines. Dans l exemple précédent, si le FAI ne tient compte que des glue records concernant le domaine demandé, 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 serveurs DNS se contentent d incrémenter d un le numéro à chaque requête qu ils envoient, il est donc très facile de deviner un numéro de requête si l on en reçoit une Comment un utilisateur malveillant peut-il obtenir le numéro de requête courant du serveur DNS de 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 de ce serveur (puisque si on reçoit une requête, cette requête contiendra le numéro). Il est très facile pour un utilisateur de forcer le serveur DNS de son FAI à lui envoyer une requête : il suffit de contrôler un domaine personnel sur lequel on contrôle le serveur DNS et de faire une requête sur une machine quelconque de ce domaine. Pour obtenir l adresse IP du serveur demandé, le FAI va faire des requêtes DNS en descendant dans la hiérarchie jusqu à ce qu on le redirige vers le DNS du serveur demandé (contrôlé par l utilisateur), qui recevra donc le numéro de requête courant du serveur DNS de son FAI. Si l utilisateur veut de nouveau trouver le numéro courant du serveur du FAI alors que l adresse de la machine qu il avait demandée est dans le cache du serveur (dans ce cas il n y aurait pas de nouvelle requête), il suffit de demander l adresse d une autre machine dans le même domaine (même si cette 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 puis immédiatement après envoie une fausse réponse DNS contenant la bonne question, le bon numéro de requête (qu il connaît par la méthode de la question précédente) et qui prétend que l adresse IP de la machine est l adresse IP d une machine qu il contrôle? (on suppose que l adresse de 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 pour obtenir l adresse de la machine (qu il ne connaît pas puisqu elle n est pas dans son cache). L utilisateur connaît alors tous les paramètres de la requête (il sait quelle est la machine 5

6 demandée, le port sur lequel communique le serveur de son FAI, le numéro de requête, etc.) et peut donc écrire et envoyer au serveur DNS de son FAI une fausse réponse. Si cette réponse arrive avant la réponse du vrai serveur DNS qui a été interrogé pendant ce temps, le serveur du FAI la considèrera comme 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 question pour 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 contienne pas 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 on considè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 plus l adresse d une machine, mais en prenant le contrôle de tout le domaine correspondant à l aide des glue records 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 de requê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 informations concernant le domaine demandé (donc à la différence de ce qui a été discuté à la question 10, ici les informations données correspondent à ce que le serveur attend et seront donc prises en compte). 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 adresse donné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érer que ces informations qu il vient de recevoir sont justes et plus récentes que celles qui sont dans le cache. Le serveur du FAI va donc mettre à jour son cache en changeant l adresse qu il connaissait du serveur de banque.net. Ainsi, si l attaquant parvient à envoyer sa réponse avant le véritable serveur DNS (ce qui n est pas si difficile étant donné qu il peut envoyer la réponse avant même que la requête soit arrivée au serveur DNS ciblé) et qu il connaît le numéro de requête (c est moins facile, mais faisable, et comme on va le voir dans la question suivante, on peut recommencer l attaque autant de fois que nécessaire), il aura effectivement 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 requêtes faites par le FAI vers le domaine banque.net seront envoyées à la machine de l attaquant et plus aucune n atteindra le vrai serveur DNS du domaine. Il n y a donc aucune raison qu un nouveau glue 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 vrai serveur arrive avant la fausse), comment peut-on répéter l attaque même si le serveur a enregistré la ré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 qui donne 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, que se passe-t-il si un autre utilisateur du même FAI essaie de se connecter à la machine net? 6

7 R. Si la véritable adresse de est encore dans le cache du FAI, il ne se passera rien. Mais cette information finira bien par expirer. Et comme c est l attaquant qui a fixé le TTL de la fausse information qu il a transmise au serveur du FAI, la fausse information durera plus longtemps que les informations correctes. Une fois que l adresse de expire du cache du FAI, lorsqu un utilisateur essaie de contacter cette machine, le FAI fait une requête DNS au serveur du domaine banque.net. Comme l adresse de ce serveur est dans son cache, le FAI s adresse directement au serveur indiqué par le cache, qui est une machine contrôlée par l attaquant. Ainsi, la réponse à la requête de l utilisateur est 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 le cache du FAI (probablement avec un TTL très long puisqu il est fixé par l attaquant) et tous les autres utilisateurs 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 dans l ordre. En effet, toute l attaque repose sur le fait que l attaquant parvient à envoyer au serveur du FAI une réponse contenant le bon numéro de requête, alors qu il n a jamais reçu la requête (puisqu elle est envoyée au vrai serveur DNS du domaine attaqué). En prendant des numéros de requête aléatoirement, il devient plus difficile de fabriquer une réponse valide. Toutefois, comme l attaque peut être répétée autant de fois que voulu, il est envisageable qu elle finisse par fonctionner. Les numéros de requête sont codés sur 16 bits (donc possibilités), ce qui n est pas énorme et on finirait par deviner le bon à force d essayer. On pourrait envisager d augmenter le nombre de numéros différents (en passant par exemple sur 32 bits) ce qui diminuerait considérablement les chances de réussite de l attaque, mais cela nécessiterait de changer le protocole DNS ce qui n est pas réalisable en pratique car tout Internet repose sur ce protocole (et le changer correspond à une quantité de mise à jours trop importante et surtout provoquerait des pannes bien trop importantes). Une autre solution consiste à utiliser une plus grande plage de ports différents pour les requêtes et réponses. En général, un serveur DNS utilise toujours le même port, ce qui rend l attaque facile puisqu il est facile de découvrir le port utilisé. Si toutefois on décide d utiliser une plus grande plage de ports, sélectionnés aléatoirement pour chaque requête, le nombre de combinaisons devient bien plus grand (avec 2500 ports ouverts, ce qui correspond à ce que peuvent utiliser certains DNS couramment utilisés, le nombre de combinaisons de port et numéro de requête est d environ 130 millions). 7