GS Mag : Quelle est cette faille corrigée en urgence par Microsoft, Sun, Cisco, IBM, etc ?

Frédéric Charpentier : Cette vulnérabilité permettait à un attaquant de corrompre l’intégrité d’un ou plusieurs serveurs DNS d’Internet et d’être en mesure de rediriger des millions d’utilisateurs vers des sites malveillants.

Cette faille n’est en réalité pas nouvelle ! Il s’agit d’un réveil général des éditeurs dû au fait qu’un chercheur en sécurité informatique, Dan Kaminsky, va présenter une méthode d’exploitation de cette faille lors de la conférence BlackHat à Las Vegas dans 3 semaines.

Il s’agit d’une faille de sécurité inhérente au protocole DNS : c’est faille est causée par un manque d’entropie des ID DNS et par une implémentation laxiste du protocole par tous les éditeurs depuis de nombreuses années.

Cette nouvelle méthode d’exploitation permettrait de corrompre efficacement et durablement le cache des serveurs DNS. Jusqu’alors, les attaques de DNS Cache-Poisonning ne pouvaient fonctionner que sur un laps de temps réduit.

Ainsi, un pirate serait en mesure de changer malicieusement l’adresse IP d’un serveur connu dans un serveur DNS public. Dès lors, tous les utilisateurs de ce serveur DNS seraient dupés et redirigés vers la fausse adresse IP. Ce type d’attaque consiste à corrompre un serveur DNS pour qu’il redirige ses utilisateurs vers des sites malicieux(man-in-the-middle, faux sites, etc).

Lorsque l’on sait que le système DNS est la base de l’Internet, il est possible d’imaginer une attaque où plus personne ne serait sûr de visiter un vrai site web. La conséquence aurait pu être une sorte d’attaque de phising globalisée

GS Mag : Comment fonctionne cette attaque ?

Frédéric Charpentier : L’attaque peut survenir lorsqu’un serveur DNS ne connait pas l’URL demandée par un internaute et interroge donc un autre serveur DNS au-dessus de lui dans la hiérarchie DNS.

Pour bien comprendre l’attaque, il faut imaginer le scénario suivant :

T0, Serveur A demande un Serveur B : "Connais-tu l’adresse IP de cette URL là car je ne la connais pas ?"
T0+n, Serveur Pirate : "Oui, la voici : adresse-IP usurpée".
T0+N, Serveur B : "Oui, la voici : véritable adresse IP".
T0+x : Serveur A "Merci, j’enregistre cette réponse pour ne plus te la demander à l’avenir".

Le pirate répond avant que le vrai serveur DNS ait eu le temps de répondre.

Pour que cette attaque fonctionne, il faut :

1 - n < N pour que l’attaque fonctionne.
2 - Que le serveur A sache effectuer des requêtes récursives, c’est-à-dire demander à un autre serveur la réponse.
3 - Que le serveur pirate usurpe l’identité du serveur B lors de l’envoi de la fausse réponse.

C’est ce troisième point qui nous intéresse ici.

Le protocole DNS est basé sur le protocole UDP. UDP est un protocole non fiable, car "non connecté". Le protocole UDP peut alors être "spoofé", c’est-à-dire que n’importe qui sur Internet peut envoyer des paquets UDP en usurpant l’adresse IP source d’un autre serveur, et donc dans le cas présent d’un serveur DNS.

Dans notre exemple, le serveur Pirate envoie une fausse réponse forgée en se faisant passer pour le serveur DNS B. La seule sécurité proposée par le protocole DNS afin de garantir l’intégrité d’une réponse DNS repose sur l’identifiant (ID) envoyé avec la question initiale. Ainsi, pour accepter la réponse de B ou du serveur Pirate, le serveur A envoi un numéro ID aléatoire avec sa question et attend cet ID dans la réponse.

La faille est très précisément ici. L’algorithme utilisé pour générer les identifiants des requêtes DNS utilise un espace de recherche trop restreint. De plus, les ports sources UDP utilisés sont simplement incrémentés sur la majorité des systèmes voire fixés à la valeur "53".
Un pirate est donc en mesure de prédire l’identifiant et d’envoyer des réponses DNS falsifiées. Cette vulnérabilité peut être exploitée afin de mener une attaque nommée ’DNS Cache Poisonning’. Ce type d’attaque permet au pirate de répondre avant le véritable serveur DNS de la victime, afin de rediriger le trafic réseau vers le serveur de son choix. Afin d’optimiser les temps de réponse, les serveurs DNS enregistrent ’en cache’ les réponses. L’attaque persistera donc dans le temps au travers du cache du serveur.

Scénario d’attaque avec Google

Objectif : rediriger les utilisateurs vers un faux Google.

1 : L’internaute demande au serveur DNS de son Fournisseur d’Accès à Internet l’adresse IP de www.google.fr.

2 : Le serveur du FAI ne connait pas la réponse et décide de faire une requête récursive au serveur DNS ayant autorité (soit le DNS de Google).

3 : Le pirate envoie massivement des fausses réponses au serveur du FAI en se faisant passer pour le DNS de Google. Le pirate devine l’ID utilisé par le DNS du FAI (c’est la faille).

4 : Le serveur du FAI accepte la fausse réponse du pirate, l’enregistre dans son cache et répond à l’internaute en lui indiquant la fausse adresse IP.
L’internaute est alors dirigé vers un faux site Google. Le faux site pourra alors lui proposer de télécharger des virus, des bots, des malwares, l’envoyer vers d’autres faux sites de commerce en ligne, etc.

GS Mag : Quels serveurs DNS sont vulnérables ?

Frédéric Charpentier : Tous les serveurs DNS publics configurés pour accepter « les requêtes récursives ».

Tous les serveurs DNS (Sun, Linux, AIX, Cisco, Juniper...) basés sur le logiciel BIND (named), version 8 et 9 (CVE-2008-1447).

Les serveurs DNS Microsoft Windows (MS08-037/CVE-2008-1454)

GS Mag : Quelle est la solution proposée par les éditeurs ?

Frédéric Charpentier : Les éditeurs, dont Microsoft, augmentent l’entropie, c’est-à-dire l’aspect aléatoire, du choix de l’ID DNS. Les éditeurs modifient également l’entropie dans le choix du port source UDP, qui jusqu’alors était nulle, afin de réduire les chances de réussites d’une telle attaque.