Nouvelle attaque DNS SAD pour insérer de fausses données dans le cache DNS

Une équipe de chercheurs de l'Université de Californie à Riverside a publié une nouvelle variante de l'attaque DNS SAD (CVE-2021-20322) qui fonctionne malgré les protections ajoutées l'année dernière pour bloquer la vulnérabilité CVE-2020-25705. La nouvelle méthode est généralement similaire à la vulnérabilité de l'année dernière et diffère uniquement par l'utilisation d'un type différent de paquets ICMP pour vérifier les ports UDP actifs. L’attaque proposée permet de substituer des données fictives dans le cache du serveur DNS, qui peuvent être utilisées pour remplacer l’adresse IP d’un domaine arbitraire dans le cache et rediriger les requêtes vers le domaine vers le serveur de l’attaquant.

La méthode proposée ne fonctionne que dans la pile réseau Linux en raison de sa connexion aux particularités du mécanisme de traitement des paquets ICMP sous Linux, qui agit comme une source de fuite de données simplifiant la détermination du numéro de port UDP utilisé par le serveur pour envoyer un demande externe. Des modifications bloquant les fuites d'informations ont été adoptées dans le noyau Linux fin août (le correctif a été inclus dans le noyau 5.15 et les mises à jour de septembre des branches LTS du noyau). Le correctif se résume à utiliser l’algorithme de hachage SipHash dans les caches réseau au lieu de Jenkins Hash. L'état de la correction de la vulnérabilité dans les distributions peut être évalué sur ces pages : Debian, RHEL, Fedora, SUSE, Ubuntu.

Selon les chercheurs qui ont identifié le problème, environ 38 % des résolveurs ouverts sur le réseau sont vulnérables, y compris les services DNS populaires tels que OpenDNS et Quad9 (9.9.9.9). Quant aux logiciels serveur, une attaque peut être menée en utilisant des packages tels que BIND, Unbound et dnsmasq sur un serveur Linux. Le problème n'apparaît pas sur les serveurs DNS exécutés sur les systèmes Windows et BSD. Pour mener à bien une attaque, il est nécessaire de recourir à l'usurpation d'adresse IP, c'est-à-dire il est nécessaire que le FAI de l'attaquant ne bloque pas les paquets avec une fausse adresse IP source.

Pour rappel, l'attaque DNS SAD contourne les protections ajoutées aux serveurs DNS pour bloquer la méthode classique d'empoisonnement du cache DNS proposée en 2008 par Dan Kaminsky. La méthode de Kaminsky manipule la petite taille du champ d'identification de la requête DNS, qui ne fait que 16 bits. Pour sélectionner le bon identifiant de transaction DNS nécessaire à l'usurpation du nom d'hôte, il suffit d'envoyer environ 7000 140 requêtes et de simuler environ 1 2 réponses fictives. L'attaque se résume à envoyer un grand nombre de paquets avec une liaison IP fictive et avec différents identifiants de transaction DNS au résolveur DNS. Pour éviter la mise en cache de la première réponse, chaque réponse factice contient un nom de domaine légèrement modifié (3.example.com, XNUMX.example.com, XNUMX.example.com, etc.).

Pour se protéger contre ce type d'attaque, les fabricants de serveurs DNS ont mis en place une répartition aléatoire du nombre de ports réseau sources à partir desquels sont envoyées les requêtes de résolution, ce qui compensait la taille insuffisamment grande de l'identifiant. Après avoir mis en œuvre une protection contre l'envoi d'une réponse fictive, en plus de sélectionner un identifiant de 16 bits, il est devenu nécessaire de sélectionner l'un des 64 2 ports, ce qui a augmenté le nombre d'options de sélection à 32 ^ XNUMX.

La méthode SAD DNS permet de simplifier radicalement la détermination du numéro de port réseau et de réduire l'attaque à la méthode Kaminsky classique. Un attaquant peut détecter l'accès aux ports UDP inutilisés et actifs en profitant des fuites d'informations sur l'activité des ports réseau lors du traitement des paquets de réponse ICMP. La méthode nous permet de réduire le nombre d'options de recherche de 4 ordres de grandeur - 2^16+2^16 au lieu de 2^32 (131_072 au lieu de 4_294_967_296). La fuite d'informations qui permet de déterminer rapidement les ports UDP actifs est causée par une faille dans le code de traitement des paquets ICMP avec des requêtes de fragmentation (indicateur ICMP Fragmentation Needed) ou de redirection (indicateur ICMP Redirect). L'envoi de tels paquets modifie l'état du cache dans la pile réseau, ce qui permet de déterminer, en fonction de la réponse du serveur, quel port UDP est actif et lequel ne l'est pas.

Scénario d'attaque : lorsqu'un résolveur DNS tente de résoudre un nom de domaine, il envoie une requête UDP au serveur DNS desservant le domaine. Pendant que le résolveur attend une réponse, un attaquant peut rapidement déterminer le numéro de port source qui a été utilisé pour envoyer la requête et lui envoyer une fausse réponse, se faisant passer pour le serveur DNS desservant le domaine en utilisant une usurpation d'adresse IP. Le résolveur DNS mettra en cache les données envoyées dans la fausse réponse et renverra pendant un certain temps l'adresse IP remplacée par l'attaquant pour toutes les autres requêtes DNS pour le nom de domaine.

Source: opennet.ru

Ajouter un commentaire