Démonstration d’un détournement possible de technologies anti-déni de service distribué (DDoS)

Auteurs: Florian Maury, Mathieu Feuillet.Intervention de l'ANSSI au "DNS OARC 2013 Fall Workshops" les 5 et 6 octobre à Phoenix, Arizona (États Unis)
Lors de la conférence DNS OARC 2013 Fall Workshops, ayant eu lieu les 5 et 6 octobre à Phoenix, Arizona (États-Unis), l'ANSSI a présenté un détournement possible de certaines technologies anti-déni de service distribué (DDoS), qui facilitent des attaques par pollution de cache DNS.

Vous trouverez ci-dessous au format PDF la présentation complète.
En complément, une FAQ répond aux principales questions soulevées par cette vulnérabilité détectée par l’ANSSI et explique quelles contre-mesures sont applicables.

Internet est régulièrement le théâtre d’attaques par déni de service (DDoS) d’amplitudes variables. Différentes méthodes existent pour mener de telles attaques, mais les incidents publics les plus récents reposent sur l’amplification de trafic DNS. Pour ce faire, l’attaquant usurpe l’adresse IP de sa victime et envoie des requêtes de faible taille, auxquelles certains serveurs DNS peuvent répondre en générant un trafic à destination de la victime dont la taille est démultipliée.

Face à cette problématique, la communauté DNS a élaboré des solutions visant à filtrer et laisser sans réponse certains messages DNS. Certaines d’entre elles ont déjà été déployées par des opérateurs de noms de premier niveau et d'autres acteurs majeurs. En étudiant ces solutions, l’ANSSI a observé que l’absence de réponses à certaines requêtes facilite les attaques par pollution de cache DNS.

Lors d'une requête DNS par un serveur cache, un attaquant peut toujours tenter d'injecter des données falsifiées dans ce dernier. Cependant, il doit pour cela répondre avant le serveur faisant autorité et la probabilité de succès d'une telle attaque est très faible. A l'inverse, lorsque le serveur faisant autorité
ne répond pas, l’habituelle course entre les serveurs faisant autorité et l’attaquant n’a pas lieu, laissant à ce dernier l’intégralité du délai de grâce du résolveur DNS pour envoyer des réponses frauduleuses. Les attaques par pollution de cache, comme l’attaque de Kaminsky, sont alors beaucoup plus efficaces.

Une modélisation mathématique du problème nous a permis d'établir qu'une attaque contre un résolveur DNS sera réussie dans 50% des cas au bout de 8 heures pour un débit émis par l’attaquant de 100 Mbps.

Une exploitation réussie permettrait à un attaquant d’injecter une fausse réponse DNS et ainsi d’intercepter le trafic à destination d’un site web ou d’un serveur d’emails en provenance de clients faisant confiance au serveur DNS dont le cache aurait été ainsi pollué.

1. La vulnérabilité a-t-elle été confirmée par des tiers ?

   L'ISC (responsable du développement de Bind), NLNet Labs (responsable du développement de NSD), le CERT gouvernemental néerlandais, et SIDN (responsable du nom de domaine de premier niveau .nl) ont tous confirmé
   publiquement la vulnérabilité.

2. Mon infrastructure est-elle vulnérable à cette attaque ?

   Toute infrastructure ou logiciel filtrant des requêtes ou des réponses DNS et laissant un résolveur DNS sans réponse est vulnérable à cette attaque. C'est le cas notamment de certains serveurs DNS ne suivant pas la recommandation de l'ANSSI (avis CERTA-2013-AVI-506 du 9 septembre 2013), des pare-feux effectuant une limitation de trafic entrant (rate-limiting) ou filtrant certains types de requêtes (par exemple, en les jugeant mal formées).

3. Quel est le statut actuel du déploiement de cette recommandation chez les éditeurs de logiciels DNS ?

   Les versions vulnérables sont détaillées dans l'avis du CERTA cité précédemment. A l'heure actuelle, seul le logiciel Knot, dans les versions 1.3.0 et ultérieures, a corrigé la valeur par défaut de ses paramètres afin de ne plus être vulnérable. Pour les logiciels BIND et NSD, il est nécessaire d'utiliser une version récente et de les configurer en accord avec les indications données dans l'avis.

4. Comment protéger mes domaines de cette attaque ?

   La solution à court terme est de s'assurer que toutes les requêtes envoyées par des résolveurs obtiennent une réponse. L'estimation de la légitimité d'une requête étant complexe, la solution la plus simple est de toujours répondre aux requêtes DNS. La réponse n'a pas nécessairement besoin d'être le contenu demandé, et peut être une réponse tronquée ou un paquet avec le code d'erreur "REFUSED". Une solution à long terme contre les attaques par pollution de cache est le déploiement de DNSSEC.

5. Toujours répondre aux requêtes augmente-t-il le risque des DDoS par paquets ?

   Les attaques employant actuellement le DNS sont des attaques par amplification de trafic (ou "DDoS volumétrique"). Le DNS n'offre en effet qu'une amplification limitée du nombre de paquets, due à la fragmentation des réponses volumineuses.

   Répondre systématiquement aux questions DNS n'aggrave pas ce risque et, en particulier, maintient le DNS à un niveau de risque inférieur à celui d'autres protocoles très répandus comme TCP.

6. Toujours répondre aux requêtes accroît-il la consommation de ressources (bande passante ou capacité de calcul) ?

   L'ANSSI a comparé en laboratoire la consommation de ressources de serveurs DNS employant RRL avec une configuration du paramètre "slip" à 1 (valeur recommandée par l'ANSSI), et à 2 (valeur par défaut dans certaines implémentations de serveurs DNS).

   Deux scénarios d'attaque ont été considérés :
   - Cas 1 : l'attaquant cherche à provoquer un déni de services sur le serveur faisant autorité employant RRL.
   - Cas 2 : l'attaquant cherche à provoquer un déni de services sur un serveur récursif interrogeant le serveur faisant autorité employant RRL.

   Dans le premier cas, la consommation réseau évolue au même rythme en entrée et en sortie, ce qui signifie qu'elles devraient saturer globalement au même rythme. Ainsi la configuration de RRL n'a pour ainsi dire pas d'importance puisqu'il ne sera pas le facteur limitant. Du point de vue de la consommation des ressources de calcul, utiliser une valeur de slip de 1'augmente de manière négligeable (inférieur à 5%).

   Dans le second cas, RRL avec une valeur de slip de 2 génère plus d'échanges sur le réseau que slip avec une valeur de 1, à cause des nouvelles tentatives déclenchées du fait de l'absence de réponse, une fois sur deux, du serveur interrogé. En ce qui concerne la consommation de ressources de calcul, le résolveur a moins de tentatives à gérer et nécessite ainsi jusqu'à 20% de ressources en moins dans la configuration recommandée par l'ANSSI.

7. Y a-t-il une preuve de concept de cette attaque ?

   Oui. L'ANSSI a évalué l'effectivité de cette attaque en laboratoire. Les résultats sont détaillés dans les planches de la présentation effectuée au DNS-OARC. En revanche, les outils développés pour effectuer ces expériences ne seront pas publiés.

8. Qui peut être visé par cette attaque ?

   Afin d'effectuer cette attaque par pollution de cache, une grande quantité de trafic doit être envoyée vers le serveur récursif ciblé. Cette attaque ne peut donc être faite que contre des opérateurs d'infrastructure Internet déjà soumises à un très fort trafic (comme par exemple les fournisseurs d'accès à Internet). Cette attaque peut cependant également être menée à l'intérieur d'un réseau local d'une entreprise dont les règles de filtrage du réseau seraient insuffisantes.

9. Qu'a fait l'ANSSI pour améliorer les choses ?

   L'ANSSI a mené une vaste campagne d'alertes et de sensibilisation pendant 4 mois, auprès des éditeurs de logiciels DNS, ainsi que des opérateurs clés du DNS (c'est-à-dire les responsables de la racine et des noms de premier niveau).

   Elle a également contacté les opérateurs nationaux afin que les opérateurs d'infrastructures critiques français soient attentifs à l'exploitation de telles vulnérabilités.