L’empoisonnement du cache DNS est de retour

Dan Kaminsky avait présenté en 2008 une technique permettant à des attaquants de modifier la réponse des serveurs DNS, afin d’orienter les internautes vers de faux sites, même après avoir tapé une adresse aussi connue que « google.com ».

Quand DNS a été conçu, ses architectes ont compris que le mécanisme pouvait être abusé. Ils ont donc inclus un ID de 16 bits, afin qu’un résolveur n’accepte en réponse à ses requêtes que celles incluant le même identifiant.

Mais Kaminsky avait perçu la limite : un identifiant codé sur 16 bits ne laisse que 65 536 possibilités. Il ne restait plus qu’à « flooder » le serveur DNS avec des adresses IP pointant vers des domaines présentant de faibles variations avec celui que l’on voulait détourner, par exemple « 1.google.com ». On finissait par obtenir le bon ID, le serveur réorientant alors les requêtes vers la nouvelle adresse et mettant à jour son cache, d’où cette appellation « d’empoisonnement ».

La découverte avait donné lieu à la création de nouveaux mécanismes de sécurité, notamment l’utilisation d’un port aléatoire en combinaison de l’identifiant, alors que les requêtes DNS passaient toutes avant par le port 53. L’entropie de l’ensemble en fut très largement augmentée.

Mais des chercheurs des universités de Riverside (Californie) et de Tsinghua (Pékin) ont remis le couvert, en exploitant un canal auxiliaire (side channel) leur permettant de récupérer le fameux numéro de port.

Le canal en question est la limite d’ICMP (Internet Control Message Protocol). Au-delà d’un certain nombre de requêtes (par seconde) provenant d’un autre serveur, un serveur ne répond plus. Une mesure conçue initialement pour limiter la consommation des ressources.

Comme l'explique Ars Technica, les chercheurs ont trouvé la technique : bombarder un serveur DNS avec un très grand nombre de réponses conçues pour ressembler à celles émises par le serveur de nom du domaine qu’ils cherchent à imiter. Chaque réponse renvoie vers un numéro de port différent.

Quand le serveur reçoit une requête comportant un port qu’il ne peut pas contacter, la limite ICMP, le plus souvent fixée à 1 000, baisse de 1. Si les mille numéros de port sont tous erronés, les chercheurs testent un nouveau lot, la limite étant tombée à 0. Mais si elle est de 1 après coup, c’est que parmi les 1 000 ports testés, l’un était bon. La procédure recommence avec des échantillons de plus en plus petits, jusqu’à mettre la main sur le port gagnant.

Les résultats de recherche ont été envoyés aux nombreux acteurs concernés. Le noyau Linux a notamment été mis à jour avec un changement entrainant une fluctuation aléatoire du nombre de requêtes acceptées, de 500 à 2 000. La technique tablant sur un nombre précis, elle devient inopérante. Cloudflare a également déployé un correctif dans ses services.