Fin février 2019, l’Internet Corporation for Assigned Names and Numbers (ICANN), organisme gérant les adresses IP et les noms de domaines utilisés sur le web, alertait sur les risques d’attaque systémique de l’Internet, et pointait plusieurs incursions. Pour comprendre ce qui est en jeu, voici ce qu’il faut avoir en tête.
Le DNS, c’est quoi ?
Le service de noms de domaine (domain name service en anglais, DNS) fait correspondre à un nom de domaine (par exemple le domaine ameli.fr de l’assurance maladie) une adresse IP (Internet protocol, ici « 31.15.27.86 »). C’est un service indispensable aujourd’hui, car il permet de mémoriser facilement des identifiants de services numériques, sans connaître leur adresse. Mais comme beaucoup de protocoles anciens, il a été conçu robuste mais non sécurisé.
Le DNS définit des zones dans lesquelles une autorité va être libre de créer des noms de domaine et de les communiquer à l’extérieur. L’intérêt de ce mécanisme est que l’association entre adresse IP et nom de domaine est gérée au plus près de cette dernière. L’inconvénient est qu’il peut être nécessaire d’effectuer plusieurs interrogations pour résoudre un nom, c’est-à-dire l’associer à une adresse.
De très nombreuses entités offrant des services Internet possèdent un ou plusieurs noms de domaines, enregistrés auprès de fournisseurs de ce service d’enregistrement. Ces fournisseurs de service sont eux-mêmes enregistrés, directement ou indirectement, auprès de l’ICANN, organisme américain chargé de l’organisation d’Internet. En France, l’organisme de référence est l’AFNIC, qui gère le domaine « .fr ».
On parle fréquemment de nom complet (fully-qualified domain name ou FQDN en anglais). L’Internet est en effet découpé en domaines racines (top-level domain ou TLD). Les domaines initiaux, américains, permettaient un découpage en type d’organisation (commerciale, universitaire, gouvernementale, etc.). Très rapidement sont arrivés les domaines nationaux comme « .fr ». Plus récemment, l’ICANN a autorisé l’enregistrement de domaines racines très variés. L’information relative à ces domaines racines est conservée dans un ensemble de 13 serveurs répartis partout dans le monde, pour assurer une bonne fiabilité et une rapidité importante dans les réponses.
Le protocole DNS établit une communication entre la machine de l’utilisateur et un serveur de noms (serveur DNS). Cette communication permet d’interroger ce serveur de nom pour résoudre un nom de domaine, c’est-à-dire obtenir l’adresse IP associée à un nom de domaine. La communication peut permettre également d’obtenir d’autres informations, comme de retrouver un nom de domaine associé à une adresse, ou de retrouver le serveur de messagerie associé à un nom de domaine pour lui envoyer un message électronique. Un exemple : lorsque nous chargeons une page dans notre navigateur, celui-ci effectuer une résolution DNS pour trouver la bonne adresse.
De par la nature distribuée de la base de données, il est fréquent que le serveur de premier contact ne connaisse pas l’association entre le nom de domaine et l’adresse. Il va alors contacter d’autres serveurs pour obtenir la réponse, par processus itératif ou récursif, jusqu’à interroger un des 13 serveurs racines. Ces serveurs forment la racine du système DNS.
Afin d’éviter de multiplier les interrogations, chaque serveur DNS conserve localement pour quelques dizaines de secondes les réponses reçues, associant nom de domaine et adresse. Ce cache permet de répondre plus rapidement au cas où la même requête surviendrait dans un intervalle de temps faible.
Un protocole vulnérable
DNS est un protocole passe-partout, notamment au sein des réseaux d’entreprise. Il peut donc permettre à un attaquant de contourner leurs mécanismes de protection pour communiquer avec des machines compromises. Cela permet par exemple à cet attaquant de contrôler des réseaux de robots (botnets). La défense repose sur un filtrage plus précis des communications, obligeant par exemple à faire un usage systématique d’un relais DNS maîtrisé par l’organisation attaquée. L’analyse des noms de domaines contenus dans les requêtes DNS, associée à des filtres de listes blanches ou listes noires, permet d’identifier et de bloquer des requêtes anormales.
Le protocole DNS permet également de mener des attaques par déni de service. En effet, n’importe qui peut émettre une requête DNS vers un service en usurpant une adresse IP. Le serveur DNS répondra naturellement à l’adresse usurpée. Cette adresse usurpée est en fait la victime de l’attaque, puisqu’elle reçoit du trafic non désiré. Le protocole DNS permet en complément de mener des attaques par amplification, c’est-à-dire que le volume de trafic émis du serveur DNS vers la victime est beaucoup plus important que celui émis de l’attaquant vers le serveur DNS. La saturation du lien réseau de la victime est donc plus facile.
Le service DNS lui-même peut être victime d’une attaque par déni de service, comme l’a été DynDNS en 2016. Cela a pu déclencher des défaillances en cascade, certains services reposant sur la disponibilité du DNS pour fonctionner.
La protection contre les attaques par déni de service peut prendre plusieurs formes. La plus utilisée aujourd’hui est un filtrage du trafic réseau pour éliminer le trafic surnuméraire. L’usage d’Anycast commence également à se répandre pour répliquer les services attaqués en cas de besoin.
Empoisonnement de cache
Une troisième vulnérabilité largement utilisée dans le passé est d’attaquer le lien entre le nom de domaine et l’adresse IP. Cela permet à un attaquant d’usurper l’adresse d’un serveur et d’attirer du trafic vers lui. Il peut ainsi « cloner » un service légitime et obtenir des utilisateurs trompés des informations sensibles : noms d’utilisateurs, mots de passe, informations relatives aux cartes de crédit, etc. Cette manière de faire est relativement difficile à déceler.
Comme indiqué précédemment, les serveurs DNS ont la capacité de mémoriser, pour des durées de quelques minutes, les réponses aux requêtes qu’ils ont émises, et d’utiliser cette information pour répondre directement aux demandes suivantes. L’attaque dite de l’empoisonnement de cache permet à un attaquant de falsifier l’association dans le cache d’un serveur légitime. L’attaquant peut par exemple inonder de réponses le serveur DNS intermédiaire, qui acceptera la première réponse correspondant à sa demande.
Les conséquences en sont que pour un certain temps, les demandes présentées au serveur victime renverront vers une adresse qui est sous le contrôle de l’attaquant. Comme il n’existe dans le protocole initial aucun moyen de vérifier l’association domaine-adresse, le client ne peut se prémunir de l’attaque.
Il en résulte le plus souvent une partition d’Internet, les clients en communication avec le serveur DNS compromis étant dirigés vers un site malveillant alors que les clients en communication avec d’autres serveurs DNS sont mis en relation avec le site initial. Notons que pour ce dernier, il est quasiment impossible de détecter l’attaque, sauf par une baisse de trafic. Cette baisse de trafic peut par ailleurs avoir des conséquences financières importantes pour le service victime.
Certificats de sécurité
Le DNS sécurisé ( domain name system security extensions, DNSSEC) a pour but de rendre cette attaque impossible, en permettant à l’utilisateur ou au serveur intermédiaire de vérifier l’association entre le nom de domaine et l’adresse. Il repose sur l’usage de certificats, comme ceux utilisés pour vérifier la validité d’un site web (le petit cadenas qui apparaît dans la barre d’un navigateur). Il suffit donc théoriquement de vérifier le certificat pour détecter une compromission.
Cette protection n’est pas parfaite. La vérification de l’exactitude des associations « nom de domaine-adresse IP » reste encore incomplète, ne serait-ce que parce que nombre de registres ne mettent pas en place l’infrastructure nécessaire. Même si la norme elle-même a été publiée il y a près de quinze ans, le déploiement de la technologie et des structures nécessaires se fait attendre. La généralisation des certificats, nécessaire pour une navigation sécurisée ainsi que pour une protection du DNS, s’est accélérée de manière significative avec l’apparition de services comme Let’s Encrypt. Cependant, l’usage de ces technologies par les registres et fournisseurs de service reste inégal, certains pays étant plus avancés que d’autres.
Même s’il existe des vulnérabilités résiduelles (comme le fait d’attaquer directement le registre ou d’obtenir des domaines et certificats valides), DNSSEC fournit une solution au type d’attaques dénoncées récemment par l’ICANN. Elles reposent en effet sur le principe de l’usurpation DNS. Plus exactement, de la falsification d’enregistrements DNS dans les bases de données des registres, ce qui suppose soit une compromission de ceux-ci, soit leur perméabilité à l’injection de fausses informations. Cette modification de la base de données du registre peut s’accompagner de l’injection d’un certificat, si l’attaquant y a pensé. Cela permettrait de contourner DNSSEC, dans le plus mauvais cas.
Cette modification des données DNS implique une certaine fluctuation dans les données d’association domaine-adresse IP. Cette fluctuation peut être observée et éventuellement donner lieu à des alertes. Il est donc difficile pour un attaquant d’être complètement silencieux. Mais comme ces fluctuations se produisent de manière régulière par exemple lorsqu’un client change d’hébergeur, le superviseur doit être particulièrement vigilant pour porter le bon diagnostic.
Des institutions ciblées
Dans le cas des attaques dénoncées par ICANN, deux caractéristiques sont particulièrement importantes. Tout d’abord, elles ont été actives pendant une durée de l’ordre de plusieurs mois, ce qui suppose un attaquant stratège déterminé et bien équipé. Ensuite, elles ont effectivement ciblé des sites institutionnels, ce qui indique une motivation forte de l’attaquant. Il est donc particulièrement important de les mettre en évidence et de comprendre les mécanismes mis en œuvre par l’attaquant pour y remédier, probablement par un renforcement des bonnes pratiques.
La publicité faite au protocole DNSSEC par l’ICANN pose cependant question. Il est évident qu’il doit se généraliser. Par contre, rien ne dit que ces attaques auraient effectivement été bloquées par DNSSEC, ni même qu’elles auraient été significativement plus difficiles à mettre en œuvre. Des analyses complémentaires sont donc nécessaires pour mettre à jour l’état de la menace sur le protocole et la base de données DNS.