Re: SAD DNS mitigation

j'ai compris que depuis 2008, la fameuse attaque "Kaminsky" a été parée en rendant aléatoire le port source de la réponse du serveur , traditionnellement port 53 
cela a permit de faire passer artificiellement le numéro de transaction (TxID) codé sur 16bits (64K valeurs possibles) à 32 bits => 16 bits TxID + 16 bits N° port aléatoire 
et donc a largement étendre le temps de "brute force" de 64K (10seondes) valeurs a +4Milliard valeurs possibles. 

Mais aujourdh'ui , grace a ce "Side channel AttackeD" via les retours d'erreur ICMP quand un port sollicité n'est pas ouvert, l'attaquant peut déterminer le numero de port Aleatoire choisit par le serveur DNS dans sa reponse et ainsi revenir comme en 2008 a un brute force du TxID a 16 bits , facile a trouver en 10s . 

les kernel recents linux limitent le nombre d'ICMP a 50 par adresse IP source par tranches de 20ms, voire rendent aléatoire ce nombre de réponse . Mais avec IPv6 un attaquant peux disposer d'une quantité importantes d'IP sources et ainsi multiplier/distribuer en // les tranches de 50 essais. 

Si le serveur DNS est bien a jours de l'attaque originale "Kaminsly 2008" il a des reponses sur des ports aleatoires, donc les port UDP sur le serveur se doivent d'etre ouverts . 

je pense qu'il n'y a pas d'autre façon de parer correctement cette nouvelle version d'attaque DNS qu'en disposant d'un noyau configuré pour limiter et rendre aléatoire le nombre d'ICMP reply . 

PS: ce lien montre si votre resolver actuel est vulnérable : 

https://551779394.www.saddns.net/check/check/ 

De: "Jérôme BERTHIER" <[email protected]> 
À: "Jehan PROCACCIA" <[email protected]>, "dns-fr" <[email protected]> 
Envoyé: Lundi 23 Novembre 2020 16:00:21 
Objet: Re: [dns-fr] SAD DNS mitigation 

Le 23/11/2020 à 15:46, Jehan PROCACCIA a écrit : 



Bonjour, 

je ne crois pas avoir vu passer de mail sur cette liste a propos du sujet du moment : SAD DNS 
EN: [ https://blog.cloudflare.com/sad-dns-explained/ | https://blog.cloudflare.com/sad-dns-explained/ ] 
EN: [ https://www.isc.org/blogs/2020-saddns/ | https://www.isc.org/blogs/2020-saddns/ ] 
FR: [ https://www.undernews.fr/alertes-securite/sad-dns-une-nouvelle-vulnerabilite-des-resolveurs.html | https://www.undernews.fr/alertes-securite/sad-dns-une-nouvelle-vulnerabilite-des-resolveurs.html ] 

est-ce que le risque est trop minime ou faut-il vraiment s'en inquiéter ? 

Merci . 





Bonjour, 

Je m'en suis tenu à ce schéma : [ https://www.saddns.net/poster.pdf | https://www.saddns.net/poster.pdf ] 


Au risque de me tromper, j'aurais tendance à penser que si l'ensemble des ports UDP du serveur DNS resolver (ceux pouvant être utilisés comme source de sa requête au serveur faisant autorité) ne sont pas ouverts et exposés (statiquement) alors l'attaque n'est pas jouable. Dans la deuxième partie de l'attaque, pour identifier le port source actif, l'attaquant joue deux salves de probes UDP pour calculer le nombre de ports ouverts dans la plage testée (la différence de messages ICMP unreachable reçus entre les deux salves). Or, si le trafic UDP entrant (autre que port 53) est filtré, la seconde salve de mesures issue de l'attaquant lui même ne pourra pas être reçue par le serveur (qui ne renverra pas les messages ICMP). 

Du coup, ça serait un avantage au pare-feu à état qui ne laisserait passer que les réponses au trafic émis par le resolver pour interroger les serveurs faisant autorité. Je sais que le dit état d'un pare-feu exposant un service sur Internet est une limite bien fragile cela étant dit. 

Je laisse les vrais experts répondre. \uD83D\uDE01 

Bonne fin de journée 
-- 
Jérôme BERTHIER
DSI - Service Conception d'Infrastructure
Inria Bordeaux - Sud-Ouest
+ 33 5 24 57 40 50