Google partage son approche pour lutter contre les attaques par empoisonnement de cache. Parmi les mesures : un support pour les cookies DNS, la randomisation des cas et le DNS sur TLS.
L’attaque par empoisonnement du cache est une forme de piratage de la scurit informatique dans laquelle des donnes corrompues du systme de noms de domaine sont introduites dans le cache du rsolveur DNS, ce qui amne le serveur de noms renvoyer un enregistrement de rsultat incorrect, par exemple une adresse IP. Le trafic est alors dtourn vers n’importe quel ordinateur choisi par l’attaquant.
Normalement, un ordinateur en rseau utilise un serveur DNS fourni par un fournisseur d’accs Internet (FAI) ou par l’organisation de l’utilisateur de l’ordinateur. Les serveurs DNS sont utiliss dans le rseau d’une organisation pour amliorer les performances des rponses de rsolution en mettant en cache les rsultats des requtes prcdemment obtenues. Les attaques par empoisonnement d’un seul serveur DNS peuvent affecter les utilisateurs desservis directement par le serveur compromis ou ceux desservis indirectement par son (ses) serveur(s) en aval, le cas chant.
Pour raliser une attaque par empoisonnement de cache, l’attaquant exploite des failles dans le logiciel DNS. Un serveur doit valider correctement les rponses DNS pour s’assurer qu’elles proviennent d’une source faisant autorit (par exemple en utilisant DNSSEC) ; dans le cas contraire, le serveur peut finir par mettre en cache les entres incorrectes localement et les servir d’autres utilisateurs qui font la mme demande.
Cette attaque peut tre utilise pour rediriger les utilisateurs d’un site web vers un autre site choisi par l’attaquant. Par exemple, un attaquant usurpe les entres DNS de l’adresse IP d’un site web cible sur un serveur DNS donn et les remplace par l’adresse IP d’un serveur qu’il contrle. Le pirate cre ensuite sur le serveur qu’il contrle des fichiers dont les noms correspondent ceux du serveur cible. Ces fichiers contiennent gnralement un contenu malveillant, tel que des vers informatiques ou des virus. L’utilisateur dont l’ordinateur a rfrenc le serveur DNS empoisonn est incit accepter le contenu provenant d’un serveur non authentique et tlcharge son insu le contenu malveillant. Cette technique peut galement tre utilise pour des attaques par hameonnage, o une fausse version d’un site web authentique est cre pour recueillir des informations personnelles telles que les coordonnes bancaires et celles des cartes de crdit/dbit.
La vulnrabilit des systmes l’empoisonnement du cache DNS va au-del de ses effets immdiats, car elle peut exposer les utilisateurs d’autres risques tels que l’hameonnage, l’injection de logiciels malveillants, le dni de service et le dtournement de sites web en raison des vulnrabilits du systme. Diverses mthodes, allant de l’utilisation de tactiques d’ingnierie sociale l’exploitation des faiblesses prsentes dans le logiciel du serveur DNS, peuvent conduire ces attaques.
L’approche de Google Public DNS pour lutter contre les attaques par empoisonnement de cache
Le systme de noms de domaine (DNS) est un protocole fondamental utilis sur internet pour traduire les noms de domaine lisibles par l’homme (par exemple, www.example.com) en adresses IP numriques (par exemple, 192.0.2.1) afin que les appareils et les serveurs puissent se trouver et communiquer entre eux. Lorsqu’un utilisateur saisit un nom de domaine dans son navigateur, le rsolveur DNS (par exemple Google Public DNS) localise les serveurs de noms DNS faisant autorit pour le nom demand et interroge un ou plusieurs d’entre eux pour obtenir la ou les adresses IP renvoyer au navigateur.
Lorsque le DNS a t lanc au dbut des annes 1980 en tant qu’infrastructure fiable et neutre en termes de contenu, la scurit n’tait pas encore une proccupation urgente, mais au fur et mesure que l’internet se dveloppait, le DNS est devenu vulnrable diverses attaques. partir d’ici, nous examinerons les attaques par empoisonnement de cache DNS et la manire dont Google Public DNS traite les risques qui y sont associs.
Attaques par empoisonnement du cache DNS
Dans la plupart des applications, les recherches DNS sont transmises un rsolveur de cache (qui peut tre local ou ouvert, comme le DNS public de Google). Le chemin entre un client et le rsolveur se trouve gnralement sur un rseau local ou peut tre protg par des transports crypts tels que DoH, DoT. Le rsolveur interroge les serveurs DNS faisant autorit pour obtenir des rponses aux demandes des utilisateurs. Cette communication s’effectue principalement via UDP, un protocole non scuris sans connexion, dans lequel les messages peuvent tre facilement usurps, y compris l’adresse IP source. Le contenu des requtes DNS peut tre suffisamment prvisible pour que mme un attaquant hors trajectoire puisse, avec suffisamment d’efforts, falsifier des rponses semblant provenir du serveur faisant autorit. Cette rponse sera mise en cache si elle correspond aux champs ncessaires et arrive avant la rponse authentique. Ce type d’attaque s’appelle une attaque par empoisonnement du cache, qui peut causer de graves dommages une fois qu’elle a russi. Selon la RFC 5452, la probabilit de russite est trs leve en l’absence de protection. Les rponses DNS falsifies peuvent entraner un dni de service, voire compromettre la scurit de l’application.
Attnuations de l’empoisonnement du cache dans le DNS public de Google
L’amlioration de la scurit du DNS est un objectif de Google Public DNS depuis son lancement en 2009. Google a adopt une approche multidimensionnelle pour protger les utilisateurs contre les attaques par empoisonnement du cache DNS. Il n’existe pas de solution miracle ou de contre-mesure qui rsolve entirement le problme, mais leur combinaison rend les attaques russies beaucoup plus difficiles.
RFC 5452 et cookies DNS
Google a mis en uvre les contre-mesures de base dcrites dans la RFC 5452, savoir la randomisation des ports sources des requtes et des identifiants des requtes. Mais ces mesures ne sont pas suffisantes.
Google :
C’est pourquoi nous avons galement mis en place un support pour le RFC 7873 (DNS Cookies) qui peut rendre le spoofing impraticable s’il est support par le serveur faisant autorit. Les mesures indiquent que les cookies DNS ne fournissent pas une couverture suffisante, mme si environ 40 % des serveurs de noms par IP prennent en charge les cookies DNS, ceux-ci reprsentent moins de 10 % du volume global de requtes. En outre, de nombreux serveurs de noms non conformes renvoient des rponses incorrectes ou ambigus pour les requtes avec des cookies DNS, ce qui cre d’autres obstacles au dploiement. Pour l’instant, nous avons activ les cookies DNS par configuration manuelle, principalement pour des zones TLD slectionnes.
Randomisation des cas (0x20)
Le mcanisme de randomisation des cas des noms de requte, propos l’origine dans un projet de mars 2008 intitul « Use of Bit 0x20 in DNS Labels to Improve Transaction Identity » (Utilisation du bit 0x20 dans les tiquettes DNS pour amliorer l’identit des transactions), est toutefois trs efficace, car tous les serveurs de noms, l’exception d’une petite minorit, sont compatibles avec la randomisation des cas des noms de requte. Depuis 2009, Google procde la randomisation des noms de requtes sur un petit ensemble de serveurs de noms choisis qui ne traitent qu’une minorit de du volume de requtes.
En 2022, Google a commenc travailler sur l’activation de la randomisation par dfaut. Lorsqu’elle est utilise, le nom de la requte dans la section des questions est randomis et la rponse du serveur DNS est cense correspondre exactement au nom de la requte randomis dans la requte. Par exemple, si « ExaMplE.CoM » est le nom envoy dans la requte, le nom dans la section question de la rponse doit galement tre « ExaMplE.CoM » plutt que, par exemple, « exemple.com ». Les rponses qui ne respectent pas la casse du nom de la requte peuvent tre rejetes en tant qu’attaques potentielles d’empoisonnement du cache (et relances par TCP).
Google :
Nous sommes heureux d’annoncer que nous avons dj activ et dploy cette fonctionnalit par dfaut au niveau mondial. Elle couvre plus de 90 % de notre trafic UDP vers les serveurs de noms, ce qui rduit considrablement le risque d’attaques par empoisonnement du cache.
Entre-temps, nous maintenons une liste d’exceptions et mettons en uvre des mcanismes de repli pour viter les problmes potentiels avec les serveurs de noms non conformes. Cependant, nous recommandons fortement que les implmentations de serveurs de noms prservent le cas de requte dans la rponse.
DNS sur TLS
En plus de la randomisation des cas, Google a dploy le DNS-over-TLS (DNS sur TLS) vers des serveurs de noms faisant autorit (ADoT), en suivant les procdures dcrites dans le RFC 9539 (Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS). Des mesures en conditions relles montrent que l’ADoT a un taux de russite plus lev et une latence comparable celle de l’UDP. L’ADoT est utilis pour environ 6 % du trafic de sortie. Au prix d’un peu d’unit centrale et de mmoire, on obtient la fois la scurit et la confidentialit pour les requtes de serveurs de noms sans problmes de conformit DNS.
En rsum
Google Public DNS prend la scurit de ses utilisateurs au srieux. Grce de multiples contre-mesures aux attaques par empoisonnement de cache, ils visent fournir un service de rsolution DNS plus sr et plus fiable, amliorant ainsi l’exprience globale d’Internet pour les utilisateurs du monde entier. Grce aux mesures dcrites ci-dessus, Google annonce tre en mesure de fournir une protection contre les attaques passives pour plus de 90 % des requtes faisant autorit.
Pour renforcer la scurit du DNS, Google recommande aux oprateurs de serveurs DNS de prendre en charge un ou plusieurs des mcanismes de scurit dcrits ici. Ils travaillent galement avec la communaut DNS pour amliorer la scurit du DNS.
Source : Google
Et vous ?
Pensez-vous que ces mesures sont crdibles ou pertinentes ?
Quel est votre avis sur le sujet ?
Voir aussi :