Un groupe de Des chercheurs de l'Université Tsinghua et de l'Université de Californie à Riverside ont développé un nouveau type d'attaque Quoi permet la substitution de fausses données dans le cache du serveur DNS, qui peut être utilisé pour usurper l'adresse IP d'un domaine arbitraire et rediriger les appels vers le domaine vers le serveur de l'attaquant.
L'attaque contourne la protection supplémentaire des serveurs DNS pour bloquer la méthode classique d'empoisonnement du cache DNS proposée en 2008 par Dan Kaminsky.
La méthode Kaminsky manipule la taille négligeable du champ d'identification de la requête DNS, qui est seulement 16 bits. Pour trouver l'identifiant correct nécessaire pour usurper le nom d'hôte, envoyez simplement environ 7.000 140.000 requêtes et simulez environ XNUMX XNUMX réponses fausses.
L'attaque se résume à l'envoi d'un grand nombre de faux paquets IP au résolveur DNS avec différents ID de transaction DNS. Pour éviter que la première réponse ne soit mise en cache, un nom de domaine légèrement modifié est spécifié dans chaque réponse bidon.
Pour se protéger contre ce type d'attaque, Fabricants de serveurs DNS implémenté 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 (pour envoyer une réponse fictive, en plus de sélectionner un identifiant 16 bits, il était nécessaire de sélectionner l'un des 64 ports, ce qui a augmenté le nombre de options de sélection à 2 ^ 32).
L'attaque Le DNS SAD simplifie considérablement l'identification des ports en tirant parti de l'activité filtrée sur les ports réseau. Le problème se manifeste dans tous les systèmes d'exploitation (Linux, Windows, macOS et FreeBSD) et lors de l'utilisation de différents serveurs DNS (BIND, Unbound, dnsmasq).
On prétend que 34% de tous les solveurs ouverts sont attaqués, ainsi que 12 des 14 services DNS les plus testés, dont les services 8.8.8.8 (Google), 9.9.9.9 (Quad9) et 1.1.1.1 (CloudFlare), ainsi que 4 des 6 routeurs testés de fournisseurs réputés.
Le problème est dû à la particularité de la formation des paquets de réponse ICMP, Quoi permet de déterminer l'accès aux ports réseau actifs et non utilisé sur UDP. Cette fonctionnalité vous permet d'analyser très rapidement les ports UDP ouverts et de contourner efficacement la protection en fonction d'une sélection aléatoire de ports réseau source, réduisant le nombre d'options de force brute à 2 ^ 16 + 2 ^ 16 au lieu de 2 ^ 32.
La source du problème est le mécanisme permettant de limiter l'intensité de l'envoi nombre de paquets ICMP sur la pile réseau, qui utilise une valeur de compteur prévisible, à partir de laquelle commence la limitation vers l'avant. Ce compteur est commun à tout le trafic, y compris le faux trafic de l'attaquant et le trafic réel. Par défaut, sous Linux, les réponses ICMP sont limitées à 1000 paquets par seconde. Pour chaque demande qui atteint un port réseau fermé, la pile réseau incrémente le compteur de 1 et envoie un paquet ICMP avec les données du port inaccessible.
Donc, si vous envoyez 1000 paquets vers différents ports réseau, qui sont tous fermés, le serveur restreindra l'envoi des réponses ICMP pendant une seconde et l'attaquant peut être sûr qu'il n'y a pas de ports ouverts parmi les 1000 ports recherchés. Si un paquet est envoyé vers un port ouvert, le serveur ne renverra pas de réponse ICMP et la valeur du compteur ne changera pas, c'est-à-dire qu'après l'envoi de 1000 paquets, la limite de taux de réponse ne sera pas atteinte.
Étant donné que les faux paquets sont effectués à partir d'une fausse IP, l'attaquant ne peut pas recevoir de réponses ICMP, mais grâce au compteur total, après 1000 faux paquets, il peut envoyer une requête à un port inexistant depuis une vraie IP et évaluer le arrivée de la réponse; si la réponse est venue, alors dans l'un des 1000 paquets. Chaque seconde, un attaquant peut envoyer 1000 faux paquets vers différents ports et déterminer rapidement dans quel bloc se trouve le port ouvert, puis affiner la sélection et déterminer un port spécifique.
Le noyau Linux résout le problème avec un patch qui randomise les paramètres pour limiter l'intensité de l'envoi de paquets ICMP, ce qui introduit du bruit et minimise les fuites de données à travers les canaux secondaires.
source: https://www.saddns.net/