ClickCease Les correctifs de KernelCare pour SAD DNS sont arrivés - TuxCare

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Les correctifs de KernelCare pour SAD DNS sont arrivés

18 novembre 2020 - L'équipe de relations publiques de TuxCare

Les correctifs de KernelCare pour SAD DNS sont en routeSad DNS (Side-channel AttackeD DNS) est une vulnérabilité qui a été divulguée par des universitaires de l'Université de Californie et de l'Université de Tsinghua, lors de la conférence ACM sur la sécurité des ordinateurs et des communications CCS 2020. La vulnérabilité a été attribuée à CVE-2020-25705. Il affecte les distributions à partir de la 7e v.o. (c'est-à-dire que RHEL6 n'est pas concerné, car son noyau n'inclut pas encore la fonctionnalité d'étranglement des réponses ICMP). Les correctifs de KernelCare seront publiés prochainement. Cette nouvelle découverte universitaire permet à un acteur malveillant d'empoisonner le cache d'un serveur DNS et donc de rediriger potentiellement le trafic des utilisateurs vers des sites ou des services hébergeant des contenus indésirables ou dangereux. 


Contenu :

  1. Comment fonctionne le DNS triste
  2. Atténuation du DNS triste
  3. La cause profonde
  4. Calendrier de publication des correctifs de KernelCare

 

Comment fonctionne le DNS triste

Comment fonctionne le DNS triste

L'empoisonnement du cache DNS a été découvert pour la première fois en 2008 par un chercheur en sécurité. Dan Kaminsky. Comme la plupart des administrateurs le savent, le système de noms de domaine (DNS) est un composant fondamental de l'Internet. Lorsqu'un utilisateur tape un domaine dans son navigateur, celui-ci effectue une requête sur un serveur DNS pour déterminer l'adresse IP correspondant au nom de domaine. 

 

La plupart des requêtes DNS utilisent le protocole UDP, qui est un protocole sans état ne nécessitant aucune authentification ou poignée de main. Les requêtes DNS utilisant UDP ne nécessitent qu'une adresse source (la machine de l'utilisateur) et une paire de ports (source et destination). Comme aucune authentification n'est requise, n'importe qui peut demander à un serveur DNS l'adresse IP associée à n'importe quel domaine enregistré.

 

UDP s'exécute sur la couche transport du modèle OSI, mais les concepteurs ont intégré l'entropie dans les requêtes DNS pour ajouter une certaine sécurité. Les requêtes intègrent un ID de transaction aléatoire qui doit être le même dans la requête et la réponse. La randomisation de cette valeur rend la falsification des requêtes moins probable en raison de son entropie. Cependant, l'ID de la requête ne comporte que 16 bits, ce qui signifie que moins de 100 000 "suppositions" sont nécessaires avant qu'un attaquant puisse obtenir une correspondance par force brute. Avec la puissance de calcul actuelle, les attaques par force brute avec seulement 100 000 possibilités peuvent être exécutées en quelques secondes.

 

L'Internet étant très vaste, les résolveurs DNS sont utilisés pour centraliser les requêtes auprès des serveurs faisant autorité et distribuer les adresses IP des domaines aux demandes des clients. Lorsqu'un serveur DNS récursif interroge un serveur faisant autorité, le port 53 est généralement utilisé pour envoyer et recevoir des messages. Comme le port est déjà connu, un attaquant n'a besoin que de l'ID de requête de 16 bits. Lors d'une attaque par empoisonnement du cache, un attaquant inonde le serveur récursif de réponses contenant toutes les ~65 000 ID possibles. Si le serveur récursif DNS reçoit la réponse de l'attaquant avant la réponse du serveur faisant autorité, le cache DNS du domaine cible est empoisonné. Comme aucune authentification ou poignée de main n'a lieu, le résolveur accepte la réponse de l'attaquant sans poser de question et l'IP malveillante se résout pour un domaine ciblé. 

 

Lorsqu'un pirate empoisonne le cache du serveur récursif DNS, tous les utilisateurs qui interrogent le domaine obtiennent l'adresse IP attribuée par le pirate pour le domaine en question. Cela signifie que l'utilisateur sera dirigé vers un serveur contrôlé par l'attaquant. Le contenu présenté à l'utilisateur est généralement un site de phishing qui a la même apparence que le domaine légitime. Grâce à cette attaque, un attaquant peut voler des informations d'identification, des données financières et des fichiers potentiellement sensibles si les utilisateurs sont incités à télécharger du contenu.

 

Pour lutter contre ce problème, les résolveurs DNS utilisent des ports aléatoires. Cela signifie que l'attaquant doit non seulement deviner l'identifiant de la requête mais aussi le port, ce qui rend l'attaque infaisable. D'autres mesures de sécurité ont été incluses dans l'architecture DNS, comme l'utilisation de TCP au lieu de UDP et l'ajout de DNSSec au processus. DNSSec exige une signature avec le message de requête, mais le protocole en est encore à ses débuts et n'a pas été universellement adopté.

 

Les attaques DNS tristes contournent la randomisation des ports à l'aide de messages d'erreur ICMP ( Internet Control Message Protocol ). Lorsqu'un port est fermé, une requête ICMP renvoie un message d'erreur "port unreachable". En utilisant ce protocole et une analyse des ports fermés, un attaquant peut déduire quels ports sont ouverts aux réponses DNS. En réduisant la "supposition" à des ports et des identifiants de requête limités, un attaquant n'a plus qu'à forcer brutalement environ cent mille réponses. Cette attaque n'est pas toujours possible car certains résolveurs utilisent des sockets UDP connectés plutôt que des sockets ouverts. Avec un socket connecté, les deux serveurs DNS sont "liés" en tant que pairs par le système d'exploitation.

 

Certains serveurs utilisent la limitation du débit pour empêcher l'inondation des ports ICMP par des attaques par réflexion. Bien que cette défense fonctionne contre les dénis de service (DoS) sur les serveurs DNS, elle peut être exploitée dans une attaque DNS triste. Lorsque les réponses ICMP sont limitées, un serveur ne répond pas par un message d'erreur lorsque la limite de débit est atteinte. Les attaquants inondent le serveur cible de suffisamment de messages ICMP pour atteindre la limite de taux et déterminer ensuite quels ports sont ouverts, éliminant ainsi le nombre de suppositions dans une attaque par force brute.

 

Pour effectuer une attaque Sad DNS, l'attaquant a besoin :

 

  • Un système capable d'effectuer des requêtes DNS contre un serveur DNS vulnérable.
  • la possibilité de recevoir des réponses ICMP dudit serveur DNS

 

 

Atténuation du DNS triste

Atténuation du DNS triste

Les attaques Sad DNS nécessitent plusieurs conditions préexistantes pour être exploitées avec succès. Les mesures d'atténuation ajoutent donc une condition supplémentaire rendant l'attaque infaisable. L'ajout de l'une des stratégies suivantes au processus DNS rendra les attaques Sad DNS infaisables pour un attaquant :

 

  • Configurer DNSSec, mais l'adoption à grande échelle de ce protocole a été lente.
  • Refuser les réponses ICMP. Cela a des effets secondaires potentiels, car ce trafic est légitimement utilisé à d'autres fins, comme la surveillance.
  • Appliquer un correctif du noyau pour corriger la cause première du problème, empêchant ainsi l'identification des ports utilisés. KernelCare travaille actuellement sur les correctifs pour CloudLinux7. Les correctifs pour les autres distributions prises en charge seront publiés prochainement.

 

 

La cause profonde

La cause profonde

Les attaques DNS sont possibles en raison de la limite prévisible du taux de réponse ICMP définie par le noyau du serveur DNS. En ayant un nombre fixe de réponses ICMP maximum par seconde, un attaquant peut déduire quels ports sont utilisés dans la communication DNS et envoyer des paquets spécialement conçus à ces ports. D'autres systèmes d'exploitation sont également concernés par ce problème, avec des limites différentes mais fixes.

 

En théorie, il est possible que Sad DNS ne soit qu'une des multiples vulnérabilités utilisées pour exploiter la randomisation inefficace des ports ICMP. D'autres services peuvent être vulnérables à des attaques similaires, mais jusqu'à présent, aucun autre service n'a été divulgué. L'application de correctifs au noyau peut aider à se prémunir contre les vulnérabilités inconnues.

A correctif concernant Sad DNS a été soumis pour le noyau Linux, et les fournisseurs de Linux publient les correctifs appropriés pour leurs distributions, notamment Redhat, Debian, Suse, Ubuntu. L'inconvénient de l'application de correctifs à l'aide d'un logiciel fourni par le fournisseur est le redémarrage nécessaire pour terminer le processus. Avec KernelCare, les administrateurs peuvent patcher en direct leurs serveurs sans redémarrage et remédier aux vulnérabilités de Sad DNS et à toute vulnérabilité future ciblant le protocole ICMP et les exploits de limite de débit.

 

 

Calendrier de publication des correctifs de KernelCare

Sortie le 23 novembre :

  • CloudLinux 6 Hybrid,
  • CloudLinux 7, 
  • Oracle Enterprise Linux 7,
  • RHEL 7,
  • CentOS 7,
  • CentOS 7 Plus

Les correctifs seront appliqués automatiquement dans la période de 4 heures sans redémarrage. Pour mettre à jour manuellement, exécutez :

/usr/bin/kcarectl --update

Prévu pour une sortie sur un Week # 48 :

  • Correctifs Ubuntu
  • Correctifs Debian

Prévu pour une sortie sur un Week # 49 :

  • Amazon Linux

Restez à l'écoute pour les mises à jour.

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information