Close

Détournements DNS : la solution DNSSEC, une panacée ?

Les mois de janvier et février 2019 ont été marqués par la découverte de détournements DNS massifs. Attribués à l’Iran par la société de cybersécurité américaine FireEye[1], ils ont touché notamment des fournisseurs d’accès à Internet (FAI), des entreprises de l’énergie et des télécoms et des organisations gouvernementales du Moyen-Orient, du Maghreb, d’Europe et d’Amérique du Nord.

La Société pour l’attribution des noms de domaine et des numéros sur Internet (Internet Corporation for Assigned Names and Numbers – ICANN) a réagi fin février en encourageant le déploiement du protocole DNSSEC (Domain Name System Security Extensions) pour lutter contre les détournements DNS.[2]

Le déploiement de DNSSEC est pourtant effectif au niveau des serveurs DNS racines depuis mi-2010.[3] Comment expliquer la lenteur de son déploiement sur le reste de l’infrastructure Internet ?

Fonctionnement des détournements DNS

Afin de comprendre les avantages de DNSSEC mais aussi ses limitations, il est nécessaire de revenir sur le procédé d’un détournement DNS. Rappelons d’abord que le DNS est le protocole qui traduit un nom de domaine en une adresse IP. Ainsi, lorsque l’on tape « google.fr » dans un navigateur :

  1. L’ordinateur demande à son serveur DNS (généralement celui du FAI) de transformer le nom de domaine en adresse IP (on parle de « résolution du nom de domaine ») ;
  2. L’ordinateur contacte alors l’adresse IP pour accéder au site Internet associé.

On parle de détournement DNS lorsqu’un pirate parvient à substituer des adresses IP malveillantes à des adresses IP légitimes. Lorsque cela se produit, les internautes sont dirigés vers les serveurs définis par les auteurs du détournement.

Il existe plusieurs techniques pour détourner des DNS mais le principe reste celui exposé précédemment. La résolution du nom de domaine prend alors cette forme, ou une forme approchante :

 

Empoisonnement du cache DNS (source : Wikipédia commons)

Une chaîne de confiance avec DNSSEC

Pour répondre à ce type d’attaques, l’Internet Engineering Task Force (IETF) a développé le DNSSEC. Ce protocole a pour l’objectif d’établir une chaîne de confiance entre le client et la racine du DNS. Prenons par exemple http://monsite.fr. Un serveur DNS implémentant DNSSEC :

  1. Vérifiera auprès du DNS « .fr » que « monsite.fr » est connu et obtiendra l’adresse du serveur DNS gérant ce domaine ;
  2. Obtiendra auprès de ce serveur DNS l’IP du serveur hébergeant le site web ;
  3. S’assurera de la validité de l’ensemble des signatures, de la racine jusqu’au domaine
  4. Puis il répondra à la requête du client.

Pour ce faire, le protocole emploie un mécanisme d’authentification suivant une architecture clé privée / clé publique pour chaque domaine. Chaque domaine parent certifie l’authenticité de la zone suivante. Une attaque par empoisonnement, comme schématisée plus haut, serait ainsi contrée :

Figure 1 : Processus de validation DNSSEC – cas d’un empoisonnement DNS à l’encontre d’un site possédant un enregistrement DNSSEC (Source : nic.ch)

 

Mais pour qu’un utilisateur visitant « monsite.fr » bénéficie des garanties de sécurité offertes par le protocole DNSSEC, celui-ci doit être implémenté à tous les niveaux de la chaîne :

  • Les serveurs DNS racines doivent implémenter DNSSEC (déploiement réalisé en 2009-2010) ;
  • La zone DNS .fr doit posséder une signature DNSSEC (la majorité des TLDs[4] ont aujourd’hui implémenté le protocole) ;
  • La zone monsite doit également posséder une signature, validée par la zone .fr ;
  • Le serveur de résolution DNS de l’utilisateur doit implémenter DNSSEC, ou a minima le navigateur de l’utilisateur fasse usage d’un plugin qui réalise sa propre validation DNSSEC (ce dernier point étant quoiqu’il arrive nécessaire si l’utilisateur souhaite avoir une vraie garantie de validation des informations DNS reçues).

Réalité du déploiement mondial

Une étude de 2017 dirigée par indique que « la prise en charge de DNSSEC est faible parmi les bureaux d’enregistrement les plus populaires[5] ». En 2018, moins de 20% des requêtes DNS mondiales effectuaient en effet une validation DNSSEC.[6] Les pays nord-européens présentent le taux de déploiement le plus élevé : 90% et 76% des requêtes DNS pour respectivement l’Islande et la Suède, contre seulement 23% en France[7].

Plusieurs raisons expliquent le faible entrain pour le déploiement du protocole DNSSEC :

  • L’impact sur les performances côté infrastructures du fait d’une part de l’augmentation du volume des requêtes (qui contraint généralement à utiliser le protocole de transport TCP[8] et non plus l’UDP[9]) ; et d’autre part des calculs liés au chiffrement, qui impliquent une augmentation des coûts pour les hébergeurs ;
  • L’impact sur les performances pour l’utilisateur final, notamment tant que le protocole n’est pas largement employé. Lors d’une requête DNS pour un domaine standard un effet de latence ralentit la transaction, car l’opération de résolution passe d’abord par la recherche d’une correspondance DNSSEC qui échouera s’il n’est pas implémenté;
  • Un coût en temps de déploiement pour les administrateurs de domaine, qui s’ajoute à la configuration standard TLS ;
  • Une problématique de confiance intrinsèque au protocole, qui implique une plus forte centralisation du contrôle des DNS. Les zones supérieures, notamment les serveurs racines contrôlés par l’ICANN et les TLDs nationaux contrôlés par les gouvernements, sont maîtresses de la validation. Et ceci d’autant plus que le protocole DANE (DNS-based Authentification of Named Entities), qui repose sur DNSSEC, permet de limiter l’authentification TLS à un Certificate Authority (CA) spécifique, voire de se passer complètement de ce système de CA ;
  • Le rapport coût/utilité qui reste défavorable tant que le protocole n’est pas largement déployé aux différents niveaux de la chaîne (l’effet réseau s’applique pleinement).

Aujourd’hui, les solutions logicielles de validation DNSSEC côté client sont quasi-inexistantes. Les principaux éditeurs ont retiré ou abandonné leurs projets d’implémentation de validation DNSSEC au sein de leur navigateur, privant ainsi les utilisateurs finaux du dernier maillon de la chaîne. Cela signifie que quand bien même le site visité possède une chaîne de signature DNSSEC complète, l’utilisateur final n’est pas en mesure de savoir si les informations fournies par son résolveur DNS sont exactes.

De l’autre côté de la chaîne, seule une infime partie des sites Internet possède une signature DNSSEC. Parmi ceux-ci, on ne compte aucun des sites web les plus populaires[10]. Effectivement, en cas de non-conformité dans la signature, un serveur DNS implémentant DNSSEC refusera d’envoyer l’IP de résolution, rendant de fait inaccessible aux utilisateurs un site signé DNSSEC même si l’adresse de résolution est légitime. Et sans implémentation logicielle côté client, ceux-ci ne connaitront pas la raison pour laquelle le nom de domaine n’est pas résolu et que le site associé n’est pas accessible. Or force est de constater que les sites web privilégient bien souvent l’accessibilité à leur site par le plus grand nombre plutôt que leur sécurité – et celle de leurs utilisateurs.

Pour que l’implémentation globale de DNSSEC devienne une réalité, il faudra que ces deux groupes d’acteurs – éditeurs logiciels côté client et administrateurs de sites Internet – acceptent de suivre le mouvement. Lorsque qu’un acteur majeur tel que Google, qui pourtant déploie DNSSEC sur ses serveurs DNS, a abandonné l’intégration logicielle à ses produits et ne signe pas ses domaines, on comprend que cette réalité reste très éloignée.

En attendant, les organisations qui souhaitent privilégier la sécurité sur la disponibilité peuvent dès aujourd’hui signer leurs domaines. Quant aux utilisateurs qui souhaitent une sécurité de bout en bout pour les domaines signés, ils ont aussi la possibilité d’utiliser une liaison VPN ou DNSCrypt[11] avec un résolveur DNSSEC.

 

[1] FireEye, Global DNS Hijacking Campaign: DNS Record Manipulation at Scale. fireeye.com

[2] ICANN, L’ICANN appelle à un déploiement complet des DNSSEC et à promouvoir la collaboration de la communauté pour protéger l’Internet. icann.org

[3] ISC, ISC Praises Momentous Step Forward in Securing the Domain Name System. isc.org

[4] Top Level Domains, niveau le plus élevé dans la hiérarchie du DNS, installés dans la zone racine : ce sont les .com, .org, .fr, etc.

[5] https://users.cs.duke.edu/~bmm/assets/pubs/ChungR-DCLMMW17.pdf

[6] Selon les statistiques de l’APNIC recensant les validations DNSSEC effectives lors de la résolution de noms de domaine

[7] https://stats.labs.apnic.net/dnssec/XA

[8] Transmission Control Protocol, qui s’utilise en mode connecté.

[9] User Datagram Protocol, qui utilise un mode de transmission sans connexion

[10] https://dnssec-name-and-shame.com

[11] https://dnscrypt.info/