Ils ont découvert une nouvelle variante du DNS SAD pour remplacer les données factices dans le cache DNS

Un groupe de chercheurs de l'Université de Californie à Riverside a publié ça fait quelques jours une nouvelle variante de l'attaque DNS SAD 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 généralement similaire à la vulnérabilité de l'année dernière et uniquement différenciée par l'utilisation d'un type de packages différent ICMP pour vérifier les ports UDP actifs. L'attaque proposée permet de substituer des données factices dans le cache d'un serveur DNS, qui peut être utilisé pour usurper l'adresse IP d'un domaine arbitraire dans le cache et rediriger les appels vers le domaine vers le serveur de l'attaquant.

La méthode proposée est exploitable uniquement sur la pile réseau Linux En raison de sa connexion aux particularités du mécanisme de traitement des paquets ICMP sous Linux, il agit comme une source de fuites de données qui simplifie la détermination du numéro de port UDP utilisé par le serveur pour envoyer une requête externe.

Selon les chercheurs qui ont identifié le problème, la vulnérabilité affecte environ 38% des solveurs ouverts sur le réseau, y compris les services DNS populaires comme OpenDNS et Quad9 (9.9.9.9). Pour le logiciel serveur, l'attaque peut être effectuée à l'aide de packages tels que BIND, Unbound et dnsmasq sur un serveur Linux. Les serveurs DNS exécutés sur les systèmes Windows et BSD ne montrent pas le problème. L'usurpation d'adresse IP doit être utilisée pour mener à bien une attaque. Il est nécessaire de s'assurer que le FAI de l'attaquant ne bloque pas les paquets avec une adresse IP source usurpée.

Pour rappel, l'attaque SAD DNS permet de contourner la protection supplémentaire des serveurs DNS pour bloquer la méthode classique d'empoisonnement du cache DNS proposé en 2008 par Dan Kaminsky.

La méthode de Kaminsky manipule la taille négligeable du champ d'ID de requête DNS, qui n'est que de 16 bits. Pour trouver le bon identifiant de transaction DNS nécessaire pour usurper le nom d'hôte, envoyez simplement environ 7.000 140.000 requêtes et simulez environ XNUMX XNUMX fausses réponses. L'attaque se résume à l'envoi d'un grand nombre de faux paquets IP au système Résolution DNS avec différents identifiants de transaction DNS.

Pour se protéger de ce type d'attaque, Fabricants de serveurs DNS mis en place une distribution aléatoire des numéros de port réseau source à partir de laquelle les demandes de résolution sont envoyées, ce qui a compensé la taille de l'identifiant insuffisamment grande. Après la mise en œuvre de la protection pour l'envoi d'une réponse fictive, en plus de la sélection d'un identifiant 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 vous permet de simplifier radicalement la détermination du numéro de port réseau et de réduire les attaques à la méthode classique de Kaminsky. Un attaquant peut déterminer l'accès aux ports UDP inutilisés et actifs en tirant parti des informations divulguées sur l'activité des ports réseau lors du traitement des paquets de réponse ICMP.

La fuite d'informations qui vous permet d'identifier rapidement les ports UDP actifs est due à une faille dans le code pour gérer les paquets ICMP avec des requêtes de fragmentation (indicateur de fragmentation ICMP requis) ou de redirection (indicateur de redirection ICMP). L'envoi de tels paquets modifie l'état du cache sur la pile réseau, permettant, en fonction de la réponse du serveur, de déterminer quel port UDP est actif et lequel ne l'est pas.

Les modifications qui bloquent les fuites d'informations ont été acceptées dans le noyau Linux à la fin du mois d'août (Le correctif a été inclus dans le noyau 5.15 et les mises à jour de septembre des branches LTS du noyau.) La solution consiste à utiliser l'algorithme de hachage SipHash dans les caches réseau au lieu de Jenkins Hash.

Enfin, si vous souhaitez en savoir plus, vous pouvez consulter le détails dans le lien suivant.


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.