Broken-by-Design/posts/cache-poisoning/index.md

---
title: "L’empoisonnement de cache DNS : toujours d’actualité ?"
slug: cache-poisoning
author: "Florian Maury"
date: 2020-07-01
type: posts
lang: fr
categories: 
- internet
tags:
- security
- dns
---

Le {{< abbr DNS "Domain Name System" >}} est l’un des protocoles réseau centraux
au bon fonctionnement de l’Internet moderne. Ce protocole permet la résolution
de noms « symboliques » – les noms de domaine – en des ressources, notamment des
adresses IP. Malgré son omniprésence dans notre quotidien, sa sécurisation a été
incrémentale et laborieuse. Cet article traite d’une attaque aussi vieille que
le DNS, l’empoisonnement de cache, contre laquelle les dernières avancées, comme
DNS-over-HTTPS, pourraient permettre de se protéger enfin complètement. Ou le
pourront-elles ?

<!--more-->

# 1. Rappels sur le fonctionnement nominal du DNS

Le DNS désigne simultanément un protocole de transmission d’informations sur
Internet, et une arborescence administrative et technique organisant les données
qui sont transmises par ce protocole. Comprendre finement ces deux aspects est
nécessaire pour approcher les attaques par empoisonnement de cache, également
appelées attaques par pollution de cache.

Les données stockées dans le DNS sont d’ordres multiples : des adresses IP
(types A, AAAA...), des informations utiles pour la livraison des courriers
électroniques (types MX, TXT...), des politiques de sécurité (types TXT, TLSA...),
des clés cryptographiques (types DNSKEY, TLSA...), ou encore des informations
techniques nécessaires au bon fonctionnement et à la sécurisation du DNS
lui-même (types NS, RRSIG, DS...). Ces données sont rangées sous la forme d’un
arbre, dont chaque nœud, chaque intersection, forme un domaine, comme le montre
la figure 1.

![Illustration de l’arborescence DNS](./arbo_0.jpg "Fig. 1 : Illustration de l’arborescence DNS. Chaque intersection constitue un domaine, qui couvre l’ensemble des domaines situés en dessous de lui, et qui sont donc appelés sous-domaines.")

Entre chaque domaine de cette arborescence peut se trouver une séparation, une
frontière administrative ou technique, que l’on nomme délégation, représentée
par un trait plein dans la figure 1. Cette frontière se manifeste techniquement
par des données, stockées sous la forme d’enregistrements DNS de type NS, qui
indiquent où trouver les serveurs qui seront responsables du domaine délégué.

L’extrait de console suivant fournit un exemple d’une réponse DNS comportant de
tels enregistrements formant une délégation. Dans cet exemple, le domaine
`john.domaine-fictif.fr` est délégué, et deux serveurs font autorité sur ce
dernier : `srv.autre-domaine.fr`, et `truc.john.domaine-fictif.fr`. Ces
informations de délégations sont fournies dans la section `Authority` de la
réponse DNS. Nous verrons ultérieurement le rôle des sections dans les
empoisonnements de cache. Comme le nom de domaine `truc.john.domaine-fictif.fr`
est situé à l’intérieur du domaine délégué `john.domaine-fictif.fr`, une adresse
doit être fournie pour ce dernier, dans la section `Additional` de la réponse
DNS de délégation.

```sh
$ dig -t NS john.domaine-fictif.fr @ns1.domaine-fictif.fr
<snip>
;; QUESTION SECTION:
john.domaine-fictif.fr. IN NS
 
;; AUTHORITY SECTION:
john.domaine-fictif.fr. 172800 IN NS srv.autre-domaine.fr.
john.domaine-fictif.fr. 172800 IN NS truc.john.domaine-fictif.fr.
 
;; ADDITIONAL SECTION:
truc.john.domaine-fictif.fr. 172800 IN A 198.51.100.53
```

Pour comprendre le rapport entre ces sections et les attaques par empoisonnement
de cache, il est également nécessaire d’étudier le fonctionnement d’une
interrogation DNS. Une interrogation DNS fait intervenir au minimum trois types
d’acteurs : le demandeur, le serveur récursif, et les serveurs faisant autorité
sur des domaines.

Le demandeur est une application qui a besoin d’une donnée stockée dans le DNS.
Ce peut être, par exemple, un navigateur ou un serveur de courriers
électroniques, ou tout simplement la commande `ping`. Ces applications peuvent
contenir du code servant à interroger le DNS, ou simplement utiliser les
dispositifs mis à disposition par le système d’exploitation : un résolveur
primitif (en anglais, stub resolver).

Le serveur récursif, quant à lui, reçoit la requête DNS du demandeur, et
interroge, de manière itérative, les serveurs faisant autorité pour obtenir la
réponse adéquate. Pour cela, le serveur récursif suit les délégations, comme
celles de l’extrait de console précédent. Son fonctionnement est illustré dans
la figure 2, où l’on observe avec les étapes 2, 3, et 4, le processus itératif.
Comme l’interrogation itérative est relativement coûteuse, en temps, mémoire, et
CPU, les serveurs récursifs sont dotés d’une mémoire persistante, dénommée
cache, dans laquelle ils stockent les réponses temporairement, afin d’économiser
des ressources en cas de réception d’une nouvelle requête DNS identique (étape
6).

![Résolution DNS standard](./resolve_dns.jpg "Fig. 2 : Résolution DNS standard. Une requête est envoyée par un résolveur primitif à un serveur récursif ; celui-ci entreprend le processus de récursion, puis répond au résolveur primitif. Un second résolveur primitif interroge ensuite le même serveur DNS récursif.")

Finalement, les serveurs faisant autorité contiennent les données recherchées.
Ils répondent aux requêtes DNS ayant trait à des domaines sur lesquels ils ont
reçu l’autorité par d’autres serveurs ayant eux-mêmes autorité sur des domaines
« parents ». Seule la racine du DNS n’a pas de domaine parent, et la
localisation de ses serveurs doit être spécifiée dans la configuration des
serveurs DNS récursifs.

Souvent, l’interrogation du DNS n’est pas aussi triviale que le cas présenté
dans la figure 2. En effet, toujours à des fins d’optimisations, parfois
également pour des raisons de sécurité, un autre type d’acteurs du DNS peut être
employé : les relais. Les relais sont des serveurs qui n’ont pour objectif que
de faire suivre les requêtes et les réponses entre plusieurs autres acteurs du
DNS (par exemple, entre des résolveurs primitifs et des serveurs récursifs).
Généralement, ces serveurs ont également une mémoire persistante (cache), afin
de décharger les serveurs récursifs ou d’économiser le transit sur le réseau des
requêtes et réponses. Ces relais sont souvent utilisés par le système
d’exploitation pour mettre en commun les réponses pour plusieurs applications,
ou par les box Internet et autres routeurs {{< abbr SOHO "Small Office, Home Office" >}} 
pour mettre en commun les réponses pour plusieurs équipements d’un
même réseau. La figure 3 illustre un exemple d’interrogation DNS employant des
relais.

![Résolution DNS avec un relais](./relais.jpg "Fig. 3 : Résolution DNS avec un relais. Plusieurs applications sollicitent un relais installé directement sur le poste de travail. Ce dernier relaie les requêtes au serveur DNS récursif, qui procède comme dans la figure 2.")

# 2. L’empoisonnement de cache

L’attaque par empoisonnement de cache vise à insérer dans une mémoire
persistante (cache) une valeur frauduleuse, qui sera ensuite servie à de
multiples demandeurs.

Les conséquences d’une réponse DNS frauduleuse peuvent être très variables : le
détournement de connexions vers une adresse IP sous le contrôle de l’attaquant,
le contournement de politiques de sécurité, ou encore la fuite d’informations
sensibles, comme détaillée dans l’article « SMTP : la killer-app de DNSSEC »,
publié dans MISC n°97 [^SMTP].

Il est intéressant de noter qu’un attaquant peut utiliser les mêmes techniques
détaillées ultérieurement dans cet article pour empoisonner juste une réponse
pour un demandeur spécifique. Cela est cependant rarement fait, puisqu’étant à
la fois potentiellement plus difficile à effectuer, et ayant un impact moins
grand, puisqu’une seule application en est victime.

L’empoisonnement de cache peut généralement être exécuté par quatre vecteurs,
chacun objet d’une des sections suivantes.

## 2.1. Le cas d’école : l’attaque de l’homme du milieu

Le mode opératoire de l’empoisonnement de cache par l’homme du milieu est simple : 
l’attaquant se situe en coupure sur le réseau entre le serveur DNS victime et
le serveur interrogé. Ce cas peut survenir lorsqu’un routeur est compromis, par
exemple. Une variante de cette attaque consiste à manipuler le réseau ou le DNS
pour détourner le trafic vers les serveurs de l’attaquant.

Dans ces deux cas, l’homme du milieu peut intercepter toutes les requêtes et
réponses DNS. Ainsi, il peut observer les requêtes en transit sur le réseau et
fournir des réponses DNS correspondantes contenant les informations frauduleuses
de son choix, à la place du serveur interrogé.

Cette attaque est de loin la plus triviale à comprendre, mais sa complexité
d’exécution est très variable en fonction du réseau sur lequel elle est mise en
œuvre. En effet, sur un réseau local, il est souvent possible de faire des
attaques de type *ARP poisoning*, afin de détourner le trafic local en se
faisant passer pour la passerelle du réseau. Sur Internet, en revanche, les
attaques {{< abbr ARP "Address Resolution Protocol" >}} ne sont pas possibles.
Détourner du trafic reste, bien entendu, possible, notamment grâce à des
attaques sur les protocoles de routage dynamiques comme  {{< abbr BGP "Border Gateway Protocol" >}}. 
Ces attaques ont cependant le mauvais goût d’être peu discrètes. Cela n’empêche
pas des attaquants de la pratiquer, comme en 2018, où le trafic vers les
serveurs DNS d’Amazon a été détourné avec une attaque BGP afin de dérober des
cryptomonnaies [^Dyn]. La NSA a également monté le programme QUANTUMDNS pour
effectuer ce genre d’empoisonnement de cache [^NSA].

Si l’on omet les autres attaques nécessaires pour se placer en homme du milieu,
effectuer un empoisonnement de cache en étant l’homme du milieu est l’affaire
d’une dizaine de lignes de Python : intercepter le trafic, inverser le bit de
l’en-tête DNS indiquant que ce message DNS est une question ou une réponse,
ajouter la réponse frauduleuse au message DNS, et renvoyer le paquet dans «
l’autre sens ».

## 2.2. La compromission des serveurs faisant autorité ou de la chaîne d’approvisionnement

L’empoisonnement de cache consiste à faire persister une donnée frauduleuse qui
sera redistribuée à des demandeurs qui seront les victimes réelles ;
l’empoisonnement n’est pas une fin en soi, mais bien un moyen. En conséquence,
un serveur DNS disposant d’une mémoire persistante peut parfaitement recevoir
une donnée frauduleuse d’un serveur désigné comme légitime par l’arborescence
DNS. Cela peut se produire si ce serveur légitime a été compromis, ou bien
lorsque les attaquants mènent une attaque sur la chaîne d’approvisionnement du
DNS.

Les attaques sur la chaîne d’approvisionnement du DNS sont très fréquentes. La
chaîne d’approvisionnement du DNS est formée, au minimum, par le bureau
d’enregistrement auprès duquel est acheté un domaine, et le registre. Les
registres sont les organismes qui possèdent les domaines situés juste en dessous
de la racine du DNS et qui accréditent les bureaux d’enregistrement pour vendre
des noms de domaine. Par exemple, on peut citer l’AFNIC, registre en charge des
noms de domaine français, dont le .fr, et OVH ou Gandi pour les bureaux
d’enregistrement.

Parmi les attaques sur la chaîne d’approvisionnement, il peut notamment être
cité le cas de la compromission des authentifiants permettant de se connecter
auprès du bureau d’enregistrement. Une fois authentifié, l’attaquant peut
modifier les informations de délégation d’un domaine, et désigner ses propres
serveurs comme faisant autorité sur ce domaine. Ces serveurs peuvent alors
servir des données frauduleuses qui resteront potentiellement dans la mémoire
persistante des serveurs DNS qui les auront interrogés bien après que le
propriétaire légitime de ce domaine ait repris le contrôle de son domaine. Un
exemple d’une telle attaque sur la chaîne d’approvisionnement peut être le
détournement de PayPal et d’eBay, en 2014, par l’intermédiaire d’une attaque du
bureau d’enregistrement Mark Monitor [^OhHi].

En outre, la nature arborescente du DNS signifie qu’il est possible de servir
des données frauduleuses pour un domaine en compromettant n’importe lequel de
ses domaines parents. Ainsi, en 2017, Matthew Bryant, un chercheur en sécurité,
a détourné une fraction des requêtes pour les domaines se terminant en .io, en
identifiant une faiblesse dans la délégation de la racine du DNS vers les
serveurs en charge du domaine io [^IOFail].

## 2.3. L’exploitation de bugs de logique logicielle

Il est bien entendu que si le serveur ou le logiciel rendant le service DNS sont
compromis par un attaquant, ce dernier peut envoyer des réponses de son choix.
Cette section de l’article ne s’intéresse cependant pas à ce cas de figure.

Il est ici question du niveau de confiance qu’un serveur DNS récursif a dans les
informations reçues dans une réponse DNS. Par exemple, est-ce que le serveur
responsable de example.com a le droit de fournir l’adresse IP de
www.example.net, dans le cadre d’un « complément de réponse » à une requête qui
lui serait envoyée ? Et quid de la réponse illustrée dans l’extrait ci-dessous ?
Est-elle acceptable ? Doit-elle être ajoutée à la mémoire persistante (cache) ?
Peut-elle remplacer une donnée contraire déjà en mémoire ?

```sh
$ dig -t A any1.abc.com
<snip>
;; QUESTION SECTION:
any1.abc.com.         IN    A
;; ANSWER SECTION:
any1.abc.com.        IN    A    1.2.3.4
;; AUTHORITY SECTION:
abc.com.    172800    IN    NS    www.abc.com.
;; ADDITIONAL SECTION:
www.abc.com.        172800    IN    A    6.6.6.6
```

La réponse n’est pas simple, car il y a de nombreux facteurs à considérer :

* sur quel(s) domaines(s) le serveur produisant la réponse fait-il autorité ;
* dans quelle section de la réponse DNS l’information a-t-elle été fournie :
  section réponse (Answer), autorité (Authority) ou complément d’information
  (Additional) ;
* l’information reçue est-elle signée cryptographiquement, avec les extensions
  de sécurité du DNS : DNSSEC.

Pendant près de dix ans après la conception du DNS, aucune norme n’a documenté
l’arbre de décision permettant de choisir si une donnée est suffisamment digne
de confiance pour être stockée en mémoire persistante. C’est seulement avec la
RFC 2181, en 1997, que des conseils ont enfin été donnés, après un processus
itératif ayant compris essais et erreurs. À ce jour, le serveur DNS BIND
implémente sept niveaux de confiance différents pour qualifier une donnée et
décider si celle-ci peut être mémorisée, utilisée ou retournée dans le cadre
d’une réponse. Les autres serveurs DNS ont implémenté leurs propres variantes.
Les réponses DNS n’ont donc pas les mêmes effets en fonction du serveur récursif
recevant la réponse.

Cela a notamment été documenté dans l’étude « *The Hitchhiker’s Guide to DNS
Cache Poisoning* » [^Hitch], qui compare les implémentations de trois serveurs
DNS récursifs (BIND9, Unbound, et MaraDNS), modélise leurs comportements, et
utilise un modèle formel pour découvrir des réponses DNS provoquant des
empoisonnements de cache. Par exemple, la réponse montrée dans l’extrait de
console ci-dessus peut inciter BIND9 et Unbound à enregistrer un serveur DNS
faisant autorité additionnel, à une adresse du choix de l’attaquant. Cette
réponse ne permettra cependant pas d’écraser l’adresse IP de www.abc.com si
celle-ci a déjà été mémorisée dans le cadre d’une réponse où elle figurait dans
la section Answer.

Le processus de décision est désormais bien établi dans les implémentations
principales. Il reste cependant parfois des bugs, comme la CVE-2009-4022, qui
affectait BIND. En outre, les nouvelles implémentations peuvent se faire piéger
comme des débutants, comme ce fut le cas pour systemd-resolved, en 2014 [^SysD].

## 2.4. L’attaque à l’aveugle

L’attaque à l’aveugle est la plus terrifiante des attaques par empoisonnement de
cache ; et pour cause, l’attaquant peut la mener depuis virtuellement n’importe
où sur le réseau, y compris parfois Internet dans sa globalité ! Pour cette
attaque, il n’est pas nécessaire d’intercepter le trafic DNS de la victime, d’où
son nom d’attaque à l’aveugle. L’attaquant se « contente » d’envoyer une réponse
(probablement plutôt des millions) à une requête dont il ignore tout, et joue
les probabilités afin que sa réponse (l’une d’entre-elles, en tout cas) soit
acceptée par le serveur DNS récursif victime comme étant la réponse légitime. Ce
dernier met alors à jour sa mémoire persistante avec les informations
frauduleuses.

Cette notion de probabilité de succès tient au fait que pour qu’une réponse soit
acceptée par un serveur DNS récursif, plusieurs critères doivent être réunis :

* l’identifiant de transaction DNS (QXID), un champ aléatoire présent dans
  l’en-tête des réponses DNS doit être identique à celui envoyé dans la requête
  ;
* la réponse doit être reçue (c’est-à-dire qu’elle doit être envoyée à la bonne
  adresse IP et au bon port) ;
* la réponse doit (sembler) provenir du serveur interrogé (c’est-à-dire que la
  réponse a été envoyée à partir de l’adresse IP et du numéro de port auxquels
  la requête a été envoyée).

À cela, il faut également ajouter les éventuelles informations spécifiques au
protocole de transport employé : UDP, TCP, D-TLS [^DoD], TLS [^DoT] ou HTTP/2
[^DoH]. Le DNS peut les utiliser tous, même si UDP est actuellement généralement
privilégié, pour des raisons de performance. En UDP, aucune information
supplémentaire ne doit être devinée par un attaquant tentant de créer une
réponse DNS frauduleuse. HTTP/2 repose (dans les faits) sur TLS, qui lui-même
transite sur TCP. Chacun de ces protocoles ajoute des informations inconnues de
l’attaquant, à commencer par le numéro de séquence TCP (32 bits
pseudo-aléatoires). L’attaquant doit devenir ce dernier, car il usurpe l’adresse
IP du serveur DNS interrogé et il ne reçoit donc pas le segment TCP SYN/ACK
contenant le numéro de séquence du serveur.

D-TLS, quant à lui, introduit, entre autres, des éléments cryptographiques très
difficiles à deviner par un attaquant.

En somme, si l’on considère le protocole de transport par défaut, UDP, le nombre
de bits inconnus d’un attaquant essayant de fabriquer une réponse frauduleuse
est :

* QXID au maximum 16 bits ;
* l’adresse IP du résolveur DNS : certaines infrastructures DNS utilisent
  plusieurs adresses IP émettrices de requêtes vers les serveurs faisant
  autorité, ce qui ajoute une incertitude de l’ordre de 0 à 3 ou 4 bits dans les
  cas extrêmes ;
* l’adresse IP du serveur DNS interrogé : la plupart des domaines disposent d’au
  moins deux serveurs DNS faisant autorité, soit au moins 1 bit d’incertitude ;
* le port sur lequel la réponse doit être envoyée : si ce dernier est choisi
  aléatoirement, selon les recommandations [^DJB] [^Res], au maximum 16 bits.

Au total, l’attaquant qui tente de fabriquer une réponse DNS frauduleuse doit
donc deviner, dans le cas le plus défavorable pour lui, $16 + 16 + 4 + 1 = 37$
bits. Une autre manière de considérer ce résultat est de dire qu’une réponse DNS
frauduleuse d’un attaquant à l’aveugle a une probabilité d’au mieux $2^-37$
(environ une chance sur 137 milliards) d’être acceptée par un serveur DNS
récursif.

L’attaquant n’est cependant pas contraint d’envoyer une unique réponse
frauduleuse. En effet, le serveur DNS récursif est en attente d’une réponse
valide. Il rejettera généralement silencieusement les tentatives infructueuses
de l’attaquant, et attendra patiemment une réponse correcte. Cette attente dure
le temps que le serveur réellement interrogé réponde. Pendant ce laps de temps,
l’attaquant peut donc envoyer autant de tentatives de réponses frauduleuses que
la victime est capable de recevoir et de traiter. Une réponse DNS de taille
moyenne pouvant faire dans les 100 octets, l’attaquant peut envoyer 125000
réponses frauduleuses par seconde vers une victime capable de traiter 100 Mb/s.
En admettant un délai raisonnable de réponse du serveur légitime autour des 100
millisecondes, l’attaquant a donc le temps d’envoyer 12500 réponses
frauduleuses. En conséquence, une tentative d’empoisonnement de cache d’une
victime capable de gérer 100 Mb/s de trafic, avec un serveur légitime mettant
100 millisecondes à répondre, a une probabilité de succès d’autour de
$log(12500)/log(2) * 2^-37$, soit environ $2^-23$ ou approximativement une
chance sur huit millions. Il existe, en outre, des techniques obscures pouvant
permettre d’améliorer encore cette probabilité [^Bloc] [^Frag] (note : le calcul
ci-dessus est faux, mais constitue une approximation compréhensible acceptable).

Une chance sur 137 milliards peut paraître être un risque négligeable. C’est en
particulier le cas si l’on considère qu’en cas d’échec, l’attaquant doit
attendre que l’information envoyée par le serveur DNS légitime expire de la
mémoire persistante du serveur récursif ciblé. Pendant cette période
d’expiration, toutes les requêtes sont, en effet, répondues avec l’information
mémorisée ; l’attaquant ne peut donc plus tenter sa chance, car le serveur DNS
récursif n’émet plus de requête.

Le risque n’a cependant pas toujours été aussi faible. En 2008, le chercheur en
sécurité Dan Kaminsky a publié une attaque permettant un empoisonnement de cache
à l’aveugle pouvant s’effectuer en quelques minutes, voire quelques secondes
suivant les « optimisations » appliquées. À l’époque, les serveurs DNS récursifs
n’utilisaient pas systématiquement un port source aléatoire. La probabilité
qu’une réponse frauduleuse puisse être acceptée pouvait donc être aussi basse
que $2^-16$, soit une chance sur 65536. Le seul élément inconnu était l’identifiant
de transaction (QXID) ! En outre, Kaminsky a abusé de la mécanique permettant
aux serveurs DNS de juger de la confiance qu’ils peuvent porter dans les
informations contenues dans une réponse DNS. Ainsi, son attaque consistait à
faire des tentatives d’empoisonnement de cache, non pas sur des domaines
existants, mais sur des domaines inexistants aux noms aléatoires. Son but
n’était pas de compromettre ces domaines inexistants, mais de fournir des
informations complémentaires écrasant d’autres données déjà présentes dans la
mémoire persistante du serveur DNS récursif victime. De surcroît, le génie de
cette attaque était d’utiliser des domaines inexistants, qui sont quasiment
innombrables. Grâce à ces noms aléatoires, en cas de tentative infructueuse, au
lieu d’attendre que le serveur DNS récursif vide sa mémoire persistante ou
invalide la réponse légitime après un certain délai, une nouvelle tentative
pouvait être immédiatement effectuée par l’attaquant, avec un nouveau nom
aléatoire.

# 3. Défenses

Le DNS a été conçu à la fin des années 80. Ce vénérable protocole a connu de
nombreux changements, et moult augmentations. Pendant longtemps, les seules
améliorations de sa sécurité ont été des rustines visant à rendre de plus en
plus difficiles les attaques à l’aveugle et compenser l’absence de lignes
directrices pour les niveaux de confiance à porter dans les données reçues.

C’est ainsi que la RFC 5452, publiée en 2009, documente, après la débâcle causée
par l’attaque de Dan Kaminksy, que le port source devrait être aléatoire pour
plus de sécurité.

La technique connue sous le nom de 0x20 a également vu le jour. 0x20 est la
distance, dans la table ASCII, entre une lettre majuscule et la lettre minuscule
correspondant : A (65) et a (97) donnent $97 - 65 = 32 = 0x20$ en hexadécimal. Son
principe est de changer aléatoirement la casse des lettres d’un nom de domaine
dans une requête DNS, et d’escompter voir les mêmes variations de casse dans la
réponse DNS. Si la réponse ne contient pas les bonnes majuscules, alors la
réponse est rejetée, même si tous les autres paramètres sont bons. Un attaquant
à l’aveugle ne peut connaître les lettres qui ont été mises en majuscule ; il
doit donc les deviner, en plus de tout le reste.

Ces astuces ne protègent cependant pas contre les autres attaques par
empoisonnement de cache évoquées dans la section précédente de cet article.
Ainsi, au milieu des années 90, l’{{< abbr IETF "Internet Engineering Task Force" >}}, 
l’organisme qui conçoit les standards de fait de l’Internet, a donc commencé à
concevoir des extensions DNS pour la sécurité : DNSSEC. Il a fallu à la
communauté plus de dix ans pour arriver à une mouture convenable. Finalement, en
2010, son déploiement global fut rendu possible.

Le principe de DNSSEC a déjà été détaillé de nombreuses fois dans MISC, ainsi
que dans un document publié par l’Afnic [^Afnic]. Néanmoins, il convient ici d’en
présenter les grandes lignes, étant donné qu’il s’agit de l’unique contre-mesure
efficace contre l’empoisonnement de cache, à ce jour. DNSSEC permet de protéger
l’intégrité des informations contenues dans le DNS, à l’aide de signatures
cryptographiques. Ces signatures sont créées avec des clés asymétriques : une
clé privée est utilisée pour créer les signatures, et la clé publique associée à
la clé privée permet de vérifier ces signatures.

La personne ou le serveur en charge d’un domaine signe donc, avec une clé
privée, les informations contenues dans ce domaine (plus spécifiquement, dans sa
zone... mais la différence subtile de terminologie peut être ignorée ici). La «
magie » mathématique de la cryptographie asymétrique permet à tout acteur DNS de
valider l’intégrité cryptographique des données ayant trait à ce domaine. Pour
cela, la clé publique est employée. Les signatures et les clés publiques
nécessaires à leur vérification sont publiées dans l’arborescence DNS elle-même.
À chaque délégation d’un sous-domaine, le domaine parent signe une information
permettant de vérifier l’authenticité de la clé qui signe le sous-domaine. Il se
crée ainsi une chaîne de clés-signatures, permettant de vérifier toutes les
informations du DNS... pour peu que les domaines soient signés.

Les validateurs des signatures DNS sont généralement les acteurs de
l’infrastructure DNS qui maintiennent une mémoire persistante : les serveurs DNS
récursifs et les relais. Une fois les données vérifiées cryptographiquement, ces
serveurs peuvent les stocker, en toute sécurité.

Lorsqu’un résolveur primitif interroge un serveur DNS récursif validant DNSSEC,
ce dernier répondra en fournissant les informations depuis sa mémoire, et en
mettant un bit à 1 (AD : Authentic Data) pour signaler qu’en ce qui le concerne,
ces informations ont été déterminées comme authentiques.

Paradoxalement, et de façon parfaitement incompréhensible, les concepteurs de
DNSSEC n’ont pas jugé utile de protéger en intégrité le bit AD... En
conséquence, si un relais maintenant une mémoire persistante ne fait pas
lui-même la validation DNSSEC, son cache peut être empoisonné par un attaquant,
quand bien même le domaine est signé avec DNSSEC ! Il peut être jugé que sur un
réseau local maîtrisé, comme dans un réseau d’entreprise, la probabilité d’une
telle attaque soit faible. Cependant, il est difficile de tenir le même argument
lorsque le serveur DNS récursif validant DNSSEC est celui de résolveurs publics,
comme ceux de Google, Cloudflare ou OpenDNS ; en effet, les réponses de ces
serveurs transitent sur l’Internet sans protection !

Plusieurs propositions ont été avancées pour combler cette absence.

Le protocole DNSCrypt [^Crypt] figure parmi les premières propositions viables.
Hélas, malgré ses nombreux mérites et son support par OpenDNS dès 2011, son
déploiement reste faible à ce jour.

De son côté, la communauté DNS a, des années après la publication de DNSCrypt,
mis au monde DNS-over-TLS (DoT) en 2018. Ses atouts sur son prédécesseur sont au
mieux douteux, et son adoption est également anecdotique à l’aube de la nouvelle
décennie.

Finalement, toujours en 2018, ce qui aurait pu sembler être un trait d’humour il
y a dix ans est devenu réalité : DNS-over-HTTPS a été spécifié. Encombré par
HTTP/2, sans en tirer le moindre avantage, ce protocole plaque les messages DNS
dans la pile protocolaire « DNS sur HTTP/1.1 sur HTTP/2 sur TLS sur TCP ».
Ironiquement, contre toute attente et contrairement à la raison la plus
primaire, c’est ce protocole, digne de l’œuvre du docteur Frankenstein, qui
semble être destiné à être largement adopté. Ce dernier est, en effet, largement
plébiscité par les navigateurs, déjà habitués à traiter avec cette pile
protocolaire absurde, et dont les intérêts sont tout autre que la protection de
l’intégrité du DNS et de la vie privée. Néanmoins, force est de constater que
grâce aux navigateurs, le bit AD aura peut-être enfin une chance d’être protégé
lors de son transit sur le réseau, grâce à TLS, et les attaques par
empoisonnement de cache deviendront réellement impossibles grâce à DNSSEC.

# 4. Conclusion

Dans cet article, nous avons étudié les différents types d’attaques par
empoisonnement de cache, au sens large. Nous avons ainsi pu observer, au travers
d’exemples, que ces attaques sont toujours d’actualité, à l’aube de la nouvelle
décennie, et plus de 30 ans après la conception du protocole DNS. Enfin, nous
avons fait un point sur les techniques de défense disponibles, et celles en
cours de déploiement.

Disposer d’une boîte à outils complète pour contrer ces attaques est un luxe
dont nous pouvons/allons pouvoir enfin jouir. Hélas, le taux d’adoption de
DNSSEC est encore très faible, notamment pour les noms de domaine en .fr. En
2017, l’ANSSI relevait que 10% des noms en .fr étaient signés, et que l’adoption
volontaire était anecdotique (1% des domaines qui existaient déjà l’année
précédente) [^Obs].

En conséquence, étudier les empoisonnements de cache est encore à ce jour
pertinent, et cela devrait, hélas, continuer de l’être pour encore de nombreuses
années.

# 5. Remerciements

Je tiens à remercier Benjamin Cohen et Piotr Chmielnicki pour leurs suggestions
d’amélioration de cet article. Les opinions exprimées dans cet article ne
sauraient les engager.

# 6. Références

[^Afnic]: Dossier DNSSEC de l’Afnic : https://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf

[^Bloc]: Blocking DNS messages is Dangerous : https://www.ssi.gouv.fr/uploads/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf

[^Crypt]: Site du projet DNSCrypt : https://dnscrypt.info/

[^Frag]: Fragments Considered Poisonous : https://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf

[^DJB]: DNS forgery : http://cr.yp.to/djbdns/forgery.html

[^DoH]: DNS Queries over HTTPS (DoH) : https://www.rfc-editor.org/rfc/rfc8484.txt

[^DoT]: Specification for DNS over Transport Layer Security (TLS) : https://www.rfc-editor.org/rfc/rfc7858.txt

[^DoD]: DNS over Datagram Transport Layer Security (DTLS) : https://www.rfc-editor.org/rfc/rfc8094.txt

[^Dyn]: Article sur l’attaque BGP pour détourner les serveurs DNS d’Amazon : https://dyn.com/blog/bgp-hijack-of-amazon-dns-to-steal-crypto-currency/

[^Hitch]: The Hitchhiker’s Guide to DNS Cache Poisoning : https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf

[^OhHi]: Article sur l’attaque via Mark Monitor : https://mashable.com/2014/02/01/syrian-electronic-army-ebay/

[^IOFail]: Blog de Matthew Bryant : https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/

[^NSA]: Quantum DNS : https://arstechnica.com/information-technology/2015/01/nsa-secretly-hijacked-existing-malware-to-spy-on-n-korea-others/

[^Obs]: Rapport de l’observatoire de la résilience de l’Internet français : https://ssi.gouv.fr/observatoire

[^Res]: Measures for Making DNS More Resilient against Forged Answers : https://www.rfc-editor.org/rfc/rfc5452.txt

[^RFCs]: DNS related RFCs : https://www.statdns.com/rfc/

[^SMTP]: SMTP la killer-app de DNSSEC : https://connect.ed-diamond.com/MISC/MISC-097/SMTP-la-killer-app-de-DNSSEC

[^SysD]: Systemd-resolved DNS cache poisoning https://seclists.org/oss-sec/2014/q4/592

Publié par les [Editions Diamond](https://connect.ed-diamond.com/MISC/mischs-021/l-empoisonnement-de-cache-dns-toujours-d-actualite) sous licence [CC-BY-NC-ND](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr).