Thibault Koechlin et Philippe Humeau

Comprendre le principe de l’attaque :

Dans le principe du DNS, une machine cherche à identifier un nom de site (par exemple Google) pour avoir une adresse IP qu’elle peut traiter. Le DNS fait cette opération dans les deux sens (nom -> IP, IP -> nom). Le souci c’est qu’un DNS traite beaucoup de requêtes, alors pour accélérer son travail, on garde en mémoire un certain temps les résultats. Par exemple si un utilisateur dans une entreprise demande à 10h du matin la résolution du nom www.google.com et que le DNS donne une (ou plusieurs) IP, l’utilisateur qui fera la même demande quelques heures plus tard aura la même réponse. Le DNS de l’entreprise n’aura pas réinterrogé son collègue, il donnera la réponse qu’il a eu un peu plus tôt et qui doit toujours être valide (en effet Google ne change pas d’IP tous les jours).

Si ce nouvel exploit concerne bien les Transaction ID, à quoi servent-ils ?

Si l’on étudie un peu plus avant la communication DNS, voici ce que ça donne :

Le poste du client s’adresse à son DNS (généralement celui de son ISP ou celui de son entreprise). Le DNS en question s’adresse à son « parent » ou directement à celui qui gère le nom de domaine concerné. Les deux parties « protègent » leur communication en utilisant une « Transaction ID », un nombre qui permet d’être sûr qu’on parle bien de la même transaction.

En effet un DNS traite plusieurs requêtes simultanément, il faut donc s’assurer que la transaction ID d’une demande ne sera pas la même que celle d’une autre, histoire de ne pas donner la réponse de l’un à l’autre et vice versa. Ce n’était pas exactement un mécanisme de sécurité en soit mais plutôt un mécanisme « anticollision ». Donc il y a 15 ans, on utilisait tout bêtement un numéro incrémental. La première demande avait la Transaction ID 1, la 2° la 2 etc…

Se faire passer pour le serveur :

Des petits malins se sont vite aperçu qu’en envoyant un petit nombre de paquets à la place du serveur DNS interrogé, on pouvait se faire passer pour lui en utilisant le bon Transaction ID. Du coup le DNS du poste client était persuadé que la réponse était valide et la mettait en cache. Toutes les requêtes suivantes au même nom de domaine (dans un temps donné) passaient ensuite par le cache du DNS (le mien en local sur mon poste ou celui de mon serveur) et la même réponse fausse était envoyée à plusieurs personnes… C’est le « Cache Poisoning ». Le TID (Transaction ID) en est la clef de voute.

Le problème a été corrigé en mettant de « l’entropie » de l’aléa dans le système. On n’utilise plus des séquences 1, 2, 3 mais une transaction ID tirée au hasard dans un univers de 16 bits, soit 65 536 possibilités… Il ne s’agissait plus d’éviter les collisions mais bien de protéger les réponses.

Oui mais… Avec 32 768 paquets on avait une chance sur deux d’intoxiquer le cache avec une mauvaise réponse DNS. Plus tard, Amit Klein en 2007 a sortit une vulnérabilité qui, elle, est passé quasiment inaperçue alors qu’elle est très dangereuse. Le principe de fond est d’attaquer le générateur de Transaction ID (TID) du système Bind (serveur DNS) qui est défectueux. Le système Bind utilise un code dit LSFR pour calculer les TID. Ce code est vulnérable si l’on « chaine » les requêtes CNAME une quinzaine de fois. Du coup le TID devient prévisible en très peu de paquets si un attaquant arrive à faire venir un internaute sur une de ses pages Web.

L’attaque de Dan Kaminsky est elle un nouveau type de birthday attack ? Une nouvelle implémentation de l’attaque du CNAME chaining d’Amit Klein de 2007 ? Ou une combinaison de cette attaque et de la faille de réorganisation des paquets par le firewall… ? Ou encore même quelque chose de totalement nouveau ? Cela parait difficile à croire puisque Bind est très audité de par le monde, mais sait on jamais, on ne le saura réellement que lors de la blackhat 2008.

Nous pouvons cependant expliquer en quoi consiste une attaque dite « Birthday attack ». Le nom vient du paradoxe de l’anniversaire. Avec 23 personnes dans une même pièce, on a une chance sur deux que deux d’entres elles soient nées le même jour.

Cette probabilité se calcule comme suit : c’est un arrangement de n dates parmi 365 possibles, soit (365-0)(365-1)…(365-n+1) ou (365 ) !/(365-n) !. A partir de 23 personnes cela fait 50% de chances.

Dans le cas du DNS c’est également « l’univers des possibles » qui est trop petit. En réalité, pour des considérations d’implémentation, 5000 paquets étaient nécessaire pour couvrir 20% des possibilités ce qui était déjà dangereux, surtout pour un mécanise fondamental comme le DNS.

Si votre cache est empoisonné, votre site bancaire peut tout à fait devenir un site pirate, avec le même look, sans que vous vous en rendiez compte. De plus ces attaques sont quasiment impossibles à détecter pour des professionnels de l’informatique, alors pour une personne non experte, autant dire que c’est complètement invisible. C’est donc un outil de phishing / Pharming incroyablement puissant mais d’autres type d’attaques peuvent également être utilisée après un empoisonnement.

Améliorer le système de fond

Depuis plusieurs années, certains experts demandent à ce que le port source du paquet de réponse soit impliqué dans la communication pour sécuriser l’ensemble… De quoi parle-t-on précisément ?

Dans le cas d’une communication entre deux machines, le client envoie un paquet au serveur depuis un de ses ports, vers le port du service désiré. C’est comparable à un immeuble, il ne suffit pas de savoir dans quel immeuble vous allez mais également à quel appartement, sinon vous sonnez à toutes les portes pour retrouver votre interlocuteur. Pour des machines, cela passe par des ports. L’adresse IP c’est l’immeuble, la porte de l’appartement, c’est le port.

Donc, le client, dans une communication DNS, appel le serveur depuis son adresse, avec un de ses ports à lui et envoie le paquet à destination de l’adresse du serveur, sur le port DNS (53). Le serveur répond par la suite depuis son adresse avec un port source de chez lui et vers l’adresse du client.

Du coté des DNS, l’erreur de conception fondamentale, c’est que le port source du paquet renvoyé par le serveur est, la plupart du temps, le même que celui sur lequel il a été interrogé. Mon DNS (celui de mon ISP ou de mon entreprise) interroge le port 53 du serveur DNS qui va me renseigner sur le nom de domaine auquel je veux me rendre et la réponse qu’il reçoit vient du port 53 de ce serveur, depuis son adresse IP. Ensuite ma machine stocke (la plupart du temps) elle aussi un cache pour améliorer le traitement de la prochaine requête au même nom de domaine.

Pour augmenter l’aléa (entropy pool) des experts en sécurité préconisent depuis des années l’utilisation conjointe de la transaction ID et du port source du paquet réponse envoyé par le serveur DNS. De cette façon les possibilités de deviner le transaction ID sont considérablement plus faibles. Les possibilités ne sont plus de 16 bits (65536) mais de 30 bits (3 976 216) ! Autant dire qu’empoisonner un cache DNS devenait virtuellement impossible. L’attaque sur le système de génération LSFR d’Amit Klein à cependant permit de réduire ceci à 15 requêtes CNAME.

Du coté de la réorganisation des paquets par les firewalls. Même si votre serveur DNS prend les numéros de paquets sources au hasard, certain firewalls réordonnent les paquets et les modifient en utilisant des numéros de port sources qui sont séquentiels et non plus random.

Bien joué Dan !

Personne, ou presque, n’a mis en place (en dehors de DJBDNS notamment) des systèmes de génération « propre » des TID en combinaison avec l’utilisation du port source des paquets du serveur.

Les autres grands manufacturiers de services DNS (Cisco, Microsoft, SUN, ISC etc…) n’ont pas fait l’effort nécessaire en temps et en heures. La réplication du code source de Bind par les géants semble avoir dupliqué les erreurs originelles.

Dan Kaminsky a fait dans le sensationnel en sortant une attaque qui est, peut être, une combinaison ou une amélioration de failles précédentes. Mais que ce soit une combinaison d’attaque ou une amélioration d’une existante. En y ajoutant une bonne dose d’épice et de surtout de communication Dan Kaminsky a obtenu deux vraies victoires historiques :

– Il a prouvé que les experts peuvent faire bouger les choses, même chez les plus grands (Cisco, Microsoft etc…) en alertant d’abord discrètement les laboratoires de sécurité de ces groupes. Il a passé le message intelligemment et les entreprises citées ont réagit de façon positive, synchrone et rapide, une première !

– Il a ensuite prévenu la presse une fois que tout était prêt, presse qui a relayée plus ou moins adroitement l’information mais qui a tiré la sonnette d’alarme. Tout le monde utilise Internet mais peu de personnes comprennent ses mécaniques sous jacente. La presse se doit de faire le relai intelligemment et de parler de ces problèmes pour informer le public. Dan Kaminsky a réussi à faire corriger les failles d’un coté et à faire parler la presse en mettant un peu de sensationnalisme dans un domaine abstrait, ce qui était très intelligent de sa part. Finalement vaut-il mieux un chercheur qui ne communique pas, perdu dans son labo ou un expert qui utilise son nom pour faire passer en force un message que plusieurs autres n’ont jamais réussi à faire reconnaître ?

Merci Dan, tu contribue de manière pertinente et continue à l’élévation globale du niveau de sécurité, c’est bien joué !

Les paris restent ouverts jusqu’à la Blackhat 2008, Birthday attack, CNAME Chaining / LSFR, source port randomizaton ou réorganisation de paquets par les firewalls, on le saura bientôt !