Vulnérabilités DNS : Empoisonnement du cache DNS - Attaque SAD DNS

Date de publication :

[Alerte modifiée le 28/12/2020]

Une vulnérabilité extrêmement critique a été découverte sur la pile réseau de la plupart des serveurs et transmetteurs DNS. Elle est due à une implémentation incorrecte de cette dernière.

CVE-2020-25705[Score CVSS v3 : 7.4] : L’attaque (Side-channel AttackeD DNS) SAD DNS est une reprise de l'attaque classique par empoisonnement du cache du DNS (qui ne fonctionne plus depuis 2008) en tirant parti des nouveaux canaux réseau qui existent dans tous les systèmes d'exploitation modernes (Linux, Windows, MacOS et FreeBSD, etc.).

Cette attaque peut permettre à un attaquant distant et non-authentifié d'injecter un enregistrement DNS malveillant dans un cache DNS (dans BIND, Unbound et dnsmasq pour ne citer que les programmes les plus connus). Il est alors possible pour un attaquant de rediriger tout trafic (initialement destiné à un domaine spécifique) vers son propre serveur et de devenir ensuite un attaquant MITM (homme du milieu), ce qui permet d'écouter et de falsifier la communication.

Contrairement à un bogue qui affecte un certain logiciel, le SAD DNS exploite des défauts fondamentaux situés dans l’implémentation de la pile réseau des systèmes d'exploitation. En outre, il s'agit de la première attaque de type canal latéral réseau pouvant être utilisée de manière malveillante contre des applications réseau de haut niveau.

Cette vulnérabilité permet notamment à un attaquant de procéder à un scan rapide des ports UDP ouverts ce qui peut permettre de contourner la protection offerte par le mécanisme de randomisation du port source dans le protocole DNS. 

Méthodologie de l’attaque :

L’option la plus efficace et la plus employée contre une attaque classique d'empoisonnement du cache DNS est la randomisation du numéro de port source. La particularité de l’attaque SAD DNS est qu’elle permet de passer outre cette protection.

L’attaque peut se perpétrer de différentes manières selon l'architecture ciblée et le type de composant permettant l'exploitation (soit un forwarder DNS soit un serveur DNS récursif).

L'attaquant doit contrôler une machine qui est capable de déclencher une demande de la part d'un transitaire ou d'un résolveur.

Une fois cela fait, l’attaquant doit trouver le port source utilisé pour une requête DNS donnée. L’implémentation du protocole UDP est telle que lorsque un socket UDP est ouverte, elle est visible par tout le monde (et non pas seulement par l’interlocuteur de base). De ce fait, un simple scan UDP de ports ouverts permet de définir quel port est utilisé par DNS à un moment ‘t’. Le serveur renvoie une erreur ICMP pour les autres ports et rien si le port scanné est effectivement le port utilisé pour la requête DNS.

Néanmoins, la fenêtre temporelle pour exécuter ce scan de port est trop courte dans des conditions normales. L’attaquant doit alors augmenter le temps de réponse de l’interlocuteur avec une fenêtre d’attaque plus grande.

Il existe deux méthodes, l’une pour les forwarders DNS, l’autre pour les serveurs DNS récursifs :

Méthode forwarders :

L’attaquant doit envoyer une requête DNS à la machine vulnérable. Cette requête doit être forgée de manière à ce que la machine vulnérable reçoive un time-out de la part du serveur DNS qu’elle a interrogé. Ainsi la fenêtre temporelle d’attaque est maximale.

Méthode serveur récursif :

L’attaquant exploite certains mécanismes de sécurité pour le protocole DNS. Si le serveur récursif reçoit trop de requêtes d’une même machine, ce dernier va rejeter ou abandonner les paquets qu’il reçoit d’elle pendant un certain laps de temps. L’attaquant peut alors inonder le serveur DNS récursif de requête DNS portant le nom du serveur DNS que le serveur récursif interroge habituellement. Le taux de perte dans les communications entre les deux serveurs légitimes sera alors anormalement élevé, ce qui augmentera l’intervalle de temps pour la fenêtre d’attaque.

Une fois que le numéro de port source est connu, l'attaquant injecte un grand nombre de réponses DNS usurpées, afin de trouver l’identifiant de transaction DNS par une attaque de type brute-force.

Enfin, en ayant connaissance du numéro de port et de l’identifiant de transaction, l’attaquant est à même d'empoisonner le cache DNS et ainsi de rediriger les flux DNS vers lui.

 

Informations

La faille est activement exploitée :

Un correctif existe :

Une mesure de contournement existe :

Risques

Risques

  • Exposition aux malwares
  • Extraction de données sensibles
  • Violation des politiques de sécurité

Criticité

  • CVSS Score v3 : 7.4

Existence d’un code d’exploitation

  • Le code existe mais n’est pas disponible publiquement (lien Github mort), une exploitation de la vulnérabilité est disponible en vidéo sur la page mise en référence de ce bulletin.

Composants vulnérables

  • Tout serveur/forwarder DNS autorisant le traffic ICMP sortant

CVE

  • CVE-2020-25705

Solutions ou recommandations

Mise en place de correctifs de sécurité

  • Mise à jour du noyau sur les serveurs Linux

Solution de contournement

Trois types de mesure pourraient être prises pour atténuer l'attaque :

  • Détruire le canal latéral

    • Désactivation du trafic ICMP sortant

    • Randomisation de la limite de taux globale de l'ICMP (utilisée par Linux)

  • Ajouter plus de secrets aux messages DNS

    • Utilisation de DNSSEC

    • Utilisation Encodage 0x20

    • Ajout d’un cookie DNS

  • Réduire la fenêtre d'attaque

    • Réduction du délai d'attente pour les demandes en suspens