Un groupe de chercheurs de l'Université de Californie à Riverside a publié une nouvelle variante de l'attaque SAD DNS (CVE-2021-20322), qui fonctionne malgré la protection ajoutée l'année dernière pour bloquer la vulnérabilité CVE-2020-25705. La nouvelle méthode est globalement similaire à la vulnérabilité de l'année dernière, mais se distingue uniquement par l'utilisation d'un autre type 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, ce qui peut être utilisé pour remplacer dans le cache l'adresse IP d'un domaine arbitraire et rediriger les demandes vers le serveur de l'attaquant.
La méthode proposée ne fonctionne que dans la pile réseau Linux en raison de sa dépendance à une caractéristique du mécanisme de traitement des paquets ICMP dans Linux, qui est à l'origine d'une fuite de données facilitant la détermination du numéro de port UDP utilisé serveur pour envoyer une requête externe. Des modifications bloquant la fuite d'informations ont été incluses dans le noyau Linux à la fin du mois d'août (le correctif fait partie du noyau 5.15 et des mises à jour de septembre pour les branches LTS du noyau). Le correctif consiste à passer à l'utilisation de l'algorithme de hachage SipHash dans les caches réseau, au lieu de Jenkins Hash. Le statut de l'élimination de la vulnérabilité dans les distributions peut être évalué sur ces pages: Debian, RHEL, Fedora, SUSE, Ubuntu.
Selon les chercheurs ayant identifié le problème, environ 38 % des résolveurs ouverts accessibles sur Internet sont vulnérables, y compris des services DNS populaires tels que OpenDNS et Quad9 (9.9.9.9). En ce qui concerne les logiciels de serveur, l'attaque peut être réalisée sur un serveur Linux avec des paquets tels que BIND, Unbound et dnsmasq. Sur les serveurs DNS fonctionnant sous Windows et les systèmes BSD, le problème ne se manifeste pas. Pour réussir l'attaque, il est nécessaire d'utiliser le spoofing IP, c'est-à-dire que le fournisseur de l'attaquant ne doit pas bloquer les paquets avec une adresse IP source falsifiée.
Rappelons que l'attaque SAD DNS permet de contourner la protection ajoutée aux serveurs DNS pour bloquer la méthode classique de saturation de cache DNS, proposée en 2008 par Dan Kaminsky. La méthode de Kaminsky manipule la taille insignifiante du champ de numéro de requête DNS, qui n'est que de 16 bits. Pour deviner l'identifiant correct de la transaction DNS nécessaire pour usurper le nom d'hôte, il suffit d'envoyer environ 7000 requêtes et de simuler environ 140 000 réponses fictives. L'attaque consiste à envoyer un grand nombre de paquets au résolveur DNS avec un lien fictif à un IP et avec différents identifiants de transaction DNS. Pour éviter la mise en cache de la première réponse, chaque réponse fictive indique un nom de domaine légèrement modifié (1.example.com, 2.example.com, 3.example.com, etc.).
Pour se protéger contre ce type d'attaque, les fabricants de serveurs DNS ont mis en œuvre une distribution aléatoire des numéros de ports réseau d'origine à partir desquels les requêtes de résolution sont envoyées, ce qui compense la taille insuffisamment grande de l'identifiant. Après la mise en place de cette protection, en plus de deviner un identifiant de 16 bits, il est devenu nécessaire de deviner l'un des 64 000 ports, ce qui a augmenté le nombre d'options à 2^32.
La méthode SAD DNS permet de simplifier radicalement la détermination du numéro de port réseau et de ramener l'attaque à la méthode classique de Kaminsky. L'attaquant peut identifier les accès aux ports UDP inactifs et actifs en tirant parti d'une fuite d'informations sur l'activité des ports réseau lors du traitement des paquets ICMP de réponse. Cette méthode permet de réduire le nombre d'options 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 permettant de déterminer rapidement les ports UDP actifs est causée par un défaut dans le code de traitement des paquets ICMP contenant des demandes de fragmentation (drapeau ICMP Fragmentation Needed) ou de redirection (drapeau ICMP Redirect). L'envoi de tels paquets modifie l'état du cache dans la pile réseau, permettant ainsi 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 : Lorsque le résolveur DNS essaie de déterminer un nom de domaine, il envoie une demande UDP au serveur DNS du domaine. Pendant que le résolveur attend la réponse, l'attaquant peut rapidement identifier le numéro de port source utilisé pour envoyer la demande et envoyer une réponse falsifiée, se faisant passer pour le serveur DNS du domaine, en utilisant le spoofing. adresses IPLe résolveur DNS mettra en cache les données transmises dans la réponse falsifiée et retournera pendant un certain temps l'adresse IP substituée par l'attaquant pour toutes les autres requêtes DNS du nom de domaine.
Source : opennet.ru
