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 sécurité informatique dans laquelle des données corrompues du système de noms de domaine sont introduites dans le cache du résolveur DNS, ce qui amène le serveur de noms à renvoyer un enregistrement de résultat incorrect, par exemple une adresse IP. Le trafic est alors détourné vers n'importe quel ordinateur choisi par l'attaquant.
Normalement, un ordinateur en réseau utilise un serveur DNS fourni par un fournisseur d'accès à Internet (FAI) ou par l'organisation de l'utilisateur de l'ordinateur. Les serveurs DNS sont utilisés dans le réseau d'une organisation pour améliorer les performances des réponses de résolution en mettant en cache les résultats des requêtes précédemment 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 échéant.
Pour réaliser une attaque par empoisonnement de cache, l'attaquant exploite des failles dans le logiciel DNS. Un serveur doit valider correctement les réponses 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 entrées incorrectes localement et les servir à d'autres utilisateurs qui font la même demande.
Cette attaque peut être utilisée pour rediriger les utilisateurs d'un site web vers un autre site choisi par l'attaquant. Par exemple, un attaquant usurpe les entrées 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 contrôle. Le pirate crée ensuite sur le serveur qu'il contrôle des fichiers dont les noms correspondent à ceux du serveur cible. Ces fichiers contiennent généralement un contenu malveillant, tel que des vers informatiques ou des virus. L'utilisateur dont l'ordinateur a référencé le serveur DNS empoisonné est incité à accepter le contenu provenant d'un serveur non authentique et télécharge à son insu le contenu malveillant. Cette technique peut également être utilisée pour des attaques par hameçonnage, où une fausse version d'un site web authentique est créée pour recueillir des informations personnelles telles que les coordonnées bancaires et celles des cartes de crédit/débit.
La vulnérabilité des systèmes à l'empoisonnement du cache DNS va au-delà de ses effets immédiats, car elle peut exposer les utilisateurs à d'autres risques tels que l'hameçonnage, l'injection de logiciels malveillants, le déni de service et le détournement de sites web en raison des vulnérabilités du système. Diverses méthodes, allant de l'utilisation de tactiques d'ingénierie sociale à l'exploitation des faiblesses présentes 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 système 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 numériques (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 résolveur 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 début des années 1980 en tant qu'infrastructure fiable et neutre en termes de contenu, la sécurité n'était pas encore une préoccupation urgente, mais au fur et à mesure que l'internet se développait, le DNS est devenu vulnérable à diverses attaques. À partir d'ici, nous examinerons les attaques par empoisonnement de cache DNS et la manière dont Google Public DNS traite les risques qui y sont associés.
Attaques par empoisonnement du cache DNS
Dans la plupart des applications, les recherches DNS sont transmises à un résolveur de cache (qui peut être local ou ouvert, comme le DNS public de Google). Le chemin entre un client et le résolveur se trouve généralement sur un réseau local ou peut être protégé par des transports cryptés tels que DoH, DoT. Le résolveur interroge les serveurs DNS faisant autorité pour obtenir des réponses aux demandes des utilisateurs. Cette communication s'effectue principalement via UDP, un protocole non sécurisé sans connexion, dans lequel les messages peuvent être facilement usurpés, y compris l'adresse IP source. Le contenu des requêtes DNS peut être suffisamment prévisible pour que même un attaquant hors trajectoire puisse, avec suffisamment d'efforts, falsifier des réponses semblant provenir du serveur faisant autorité. Cette réponse sera mise en cache si elle correspond aux champs nécessaires et arrive avant la réponse authentique. Ce type d'attaque s'appelle une attaque par empoisonnement du cache, qui peut causer de graves dommages une fois qu'elle a réussi. Selon la RFC 5452, la probabilité de réussite est très élevée en l'absence de protection. Les réponses DNS falsifiées peuvent entraîner un déni de service, voire compromettre la sécurité de l'application.
Atténuations de l'empoisonnement du cache dans le DNS public de Google
L'amélioration de la sécurité du DNS est un objectif de Google Public DNS depuis son lancement en 2009. Google a adopté une approche multidimensionnelle pour protéger les utilisateurs contre les attaques par empoisonnement du cache DNS. Il n'existe pas de solution miracle ou de contre-mesure qui résolve entièrement le problème, mais leur combinaison rend les attaques réussies beaucoup plus difficiles.
RFC 5452 et cookies DNS
Google a mis en œuvre les contre-mesures de base décrites dans la RFC 5452, à savoir la randomisation des ports sources des requêtes et des identifiants des requêtes. 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, même si environ 40 % des serveurs de noms par IP prennent en charge les cookies DNS, ceux-ci représentent moins de 10 % du volume global de requêtes. En outre, de nombreux serveurs de noms non conformes renvoient des réponses incorrectes ou ambiguës pour les requêtes avec des cookies DNS, ce qui crée d'autres obstacles au déploiement. Pour l'instant, nous avons activé les cookies DNS par configuration manuelle, principalement pour des zones TLD sélectionnées.
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, même si environ 40 % des serveurs de noms par IP prennent en charge les cookies DNS, ceux-ci représentent moins de 10 % du volume global de requêtes. En outre, de nombreux serveurs de noms non conformes renvoient des réponses incorrectes ou ambiguës pour les requêtes avec des cookies DNS, ce qui crée d'autres obstacles au déploiement. Pour l'instant, nous avons activé les cookies DNS par configuration manuelle, principalement pour des zones TLD sélectionnées.
Le mécanisme de randomisation des cas des noms de requête, 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 améliorer l'identité des transactions), est toutefois très efficace, car tous les serveurs de noms, à l'exception d'une petite minorité, sont compatibles avec la randomisation des cas des noms de requête. Depuis 2009, Google procède à la randomisation des noms de requêtes sur un petit ensemble de serveurs de noms choisis qui ne traitent qu'une minorité de du volume de requêtes.
En 2022, Google a commencé à travailler sur l'activation de la randomisation par défaut. Lorsqu'elle est utilisée, le nom de la requête dans la section des questions est randomisé et la réponse du serveur DNS est censée correspondre exactement au nom de la requête randomisé dans la requête. Par exemple, si "ExaMplE.CoM" est le nom envoyé dans la requête, le nom dans la section question de la réponse doit également être "ExaMplE.CoM" plutôt que, par exemple, "exemple.com". Les réponses qui ne respectent pas la casse du nom de la requête peuvent être rejetées en tant qu'attaques potentielles d'empoisonnement du cache (et relancées par TCP).
Google :
Nous sommes heureux d'annoncer que nous avons déjà activé et déployé cette fonctionnalité par défaut au niveau mondial. Elle couvre plus de 90 % de notre trafic UDP vers les serveurs de noms, ce qui réduit considérablement le risque d'attaques par empoisonnement du cache.
Entre-temps, nous maintenons une liste d'exceptions et mettons en œuvre des mécanismes de repli pour éviter les problèmes potentiels avec les serveurs de noms non conformes. Cependant, nous recommandons fortement que les implémentations de serveurs de noms préservent le cas de requête dans la réponse.
Nous sommes heureux d'annoncer que nous avons déjà activé et déployé cette fonctionnalité par défaut au niveau mondial. Elle couvre plus de 90 % de notre trafic UDP vers les serveurs de noms, ce qui réduit considérablement le risque d'attaques par empoisonnement du cache.
Entre-temps, nous maintenons une liste d'exceptions et mettons en œuvre des mécanismes de repli pour éviter les problèmes potentiels avec les serveurs de noms non conformes. Cependant, nous recommandons fortement que les implémentations de serveurs de noms préservent le cas de requête dans la réponse.
En plus de la randomisation des cas, Google a déployé le DNS-over-TLS (DNS sur TLS) vers des serveurs de noms faisant autorité (ADoT), en suivant les procédures décrites dans le RFC 9539 (Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS). Des mesures en conditions réelles montrent que l'ADoT a un taux de réussite 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 mémoire, on obtient à la fois la sécurité et la confidentialité pour les requêtes de serveurs de noms sans problèmes de conformité DNS.
En résumé
Google Public DNS prend la sécurité de ses utilisateurs au sérieux. Grâce à de multiples contre-mesures aux attaques par empoisonnement de cache, ils visent à fournir un service de résolution DNS plus sûr et plus fiable, améliorant ainsi l'expérience globale d'Internet pour les utilisateurs du monde entier. Grâce aux mesures décrites ci-dessus, Google annonce être en mesure de fournir une protection contre les attaques passives pour plus de 90 % des requêtes faisant autorité.
Pour renforcer la sécurité du DNS, Google recommande aux opérateurs de serveurs DNS de prendre en charge un ou plusieurs des mécanismes de sécurité décrits ici. Ils travaillent également avec la communauté DNS pour améliorer la sécurité du DNS.
Source : Google
Et vous ?
Pensez-vous que ces mesures sont crédibles ou pertinentes ? Quel est votre avis sur le sujet ?Voir aussi :
Google introduit les domaines de premier niveau .zip et .mov et suscite des préoccupations en matière de sécurité sur Internet, ils pourraient être utilisés dans des attaques par hameçonnage Google Public DNS supporte désormais la spécification DNS-over-TLS pour mieux protéger les communications des utilisateurs avec leurs résolveurs DNS Des chercheurs font revivre l'empoisonnement du cache DNS, une attaque Internet de 2008, en se servant du protocole ICMP. Cette technique a pour but ultime d'usurper l'identité d'un site