GSM : Comment avez-vous découvert cette vulnérabilité ?

Dan Kaminsky : J’avais pour mission d’optimiser une ferme de serveurs pour Wikipédia afin que les utilisateurs soient redirigés toujours vers le serveur le plus rapide et ceci sans utiliser le TTL (Time To Live) et les systèmes traditionnels de load balancing. J’ai eu l’idée de travailler sur une redirection basée sur les DNS et notamment sur la modification du TTL du cache. Théoriquement en fonction des RFC en vigueur ainsi que de la « fonction sécurisée » cela n’aurait jamais dû marcher… Gotcha ! Cela a marché très bien. De là, j’ai alerté les différents éditeurs et j’ai essayé avec un certain succès de coordonner une édition des patchs simultanés.

GS Mag : Pensez-vous que l’on a frôlé le « Big One » ?

Dan Kaminsky : Pour toute la communauté, moi inclus, on ne considérait pas que c’était une faille critique puisqu’elle avait été notée 4/5 par les CERT. En fait, cette faille est très critique car elle concerne l’intégralité de l’internet et de ses services : les emails, les authentifications par mot de passe, les mots de passe perdus, les mises à jour de patchs… Pour l’instant, il n’y a pas eu d’incident majeur identifié. Nous avons donc été chanceux sur ce coup. Avant cet événement, une grosse majorité des experts pensaient qu’il y avait des risques mais plutôt sectoriels. Par contre, cela a permis à la communauté entière de l’IT de se réveiller, de se mobiliser pour travailler ensemble sur un sujet commun : la protection du système.

GSM : L’application du patch est-elle suffisante ?

Dan Kaminsky : A ma grande satisfaction près de 70% des serveurs DNS sont patchés aujourd’hui dans le monde et également plus de 120 millions d’utilisateurs d’ADSL, car la faille concerne aussi bien les serveurs que les clients. Cependant, nous nous sommes rendus compte que patcher n’était pas une affaire de presse-bouton, mais qu’il fallait des ingénieurs de haut niveau capables de réagir au comportement erratique en temps réel et éventuellement de revenir en arrière. Il est donc primordial de suivre une méthodologie rigoureuse de mise en œuvre et de tests…

Par ailleurs, nous n’avions pas vu immédiatement l’implication des firewalls dans cette vulnérabilité, et nous avons informé les fournisseurs de firewalls dans un deuxième temps. Fort heureusement, la plupart des firewalls ont une fonction IPS/IDS qui permet de résoudre le problème de manière préventive avant même que la faille ne soit découverte. En revanche, les IPS/IDS à base de signature -sans analyse comportementale- ne peuvent analyser qu’un paquet à la fois et donc détectent mal ce type d’attaque.

GSM : Comment mieux sécuriser le DNS : le DNSSEC ou l’IPV6 sont-ils de bonnes pistes ?

Dan Kaminsky : IPV6 n’est pas une solution de sécurité ! Même s’il y a des champs de sécurité incluant la crypto, on peut se demander qui a la clé… Je suis un garçon pragmatique, si j’avais dit à l’industrie que la solution était de tout passer en DNSSEC, il aurait éclaté de rire ! Donc, j’ai préféré me concentrer sur une solution de patch qui permet de rehausser la difficulté de l’attaque, sans pour autant résoudre le problème. Nous étions sur un pont branlant, que l’on a consolidé. Aujourd’hui, il faut installer un nouveau pont.

GSM : Cette soudaine notoriété a-t-elle eu un effet positif sur IO Active, la société dans laquelle vous travaillez ?

Dan Kaminsky : Ce n’a pas été bon seulement pour IO Active, mais pour l’ensemble de l’industrie de l’informatique. En effet, elle a permis de donner une impression globale de maturité : Il est notable que tout un secteur ultra concurrentiel décide d’unir ses ressources pour résoudre un problème critique. C’est un véritable « success story » !

GSM : Quels sont les autres domaines que vous estimez être aussi faibles que le DNS et qui pourraient provoquer le même type de problème grave ?

Dan Kaminsky : Le premier que je vois est le « crackage » de MD5 avec pour conséquence le dévoiement de SSL. Le second est le système de certificats et « l’illusion » des révocations. Le troisième serait le système d’auto-update non signé ou avec des certificats « bidons ». Quand on pense que 42% des sites avec certificats sont autosignés…