La faille au cœur d'Internet

Dan Kaminsky, contrairement à son habitude, ne cherchait pas de bogues plus tôt cette année lorsqu'il est tombé sur une faille au cœur d'Internet. Le chercheur en sécurité utilisait sa connaissance de l'infrastructure Internet pour trouver un meilleur moyen de diffuser des vidéos aux utilisateurs. L'expertise de Kaminsky réside dans le système de noms de domaine (DNS) d'Internet, le protocole chargé de faire correspondre les URL des sites Web avec les adresses numériques des serveurs qui les hébergent. Un même contenu peut être hébergé par plusieurs serveurs avec plusieurs adresses, et Kaminsky a pensé qu'il avait une bonne astuce pour diriger les utilisateurs vers les serveurs les mieux à même de traiter leurs demandes à un moment donné.

Voir le problème : Le chercheur en sécurité Dan Kaminsky a détecté pour la première fois une vulnérabilité de base sur Internet l'hiver dernier.

Normalement, DNS est fiable mais pas agile. Lorsqu'un ordinateur, par exemple un serveur qui aide à diriger le trafic sur le réseau de Comcast, demande l'adresse numérique associée à une URL donnée, il stocke la réponse pendant une période appelée durée de vie, qui peut aller de quelques secondes à plusieurs jours. Cela permet de réduire le nombre de requêtes effectuées par le serveur. L'idée de Kaminsky était de contourner le temps de vie, permettant au serveur d'obtenir une nouvelle réponse chaque fois qu'il voulait connaître l'adresse d'un site. Par conséquent, le trafic sur le réseau de Comcast serait envoyé à l'adresse optimale à chaque instant, plutôt qu'à l'adresse déjà stockée. Kaminsky était convaincu que la stratégie pourrait accélérer considérablement la distribution de contenu.

Ce n'est que plus tard, après avoir discuté de l'idée avec désinvolture avec un ami, que Kaminsky s'est rendu compte que son astuce pouvait complètement briser la sécurité du système de noms de domaine et, par conséquent, d'Internet lui-même. Il s'avère que le temps de vivre était au cœur de la sécurité DNS ; être capable de le contourner a permis une grande variété d'attaques. Kaminsky a écrit un petit code pour s'assurer que la situation était aussi mauvaise qu'il le pensait. Une fois que je l'ai vu fonctionner, mon estomac est tombé, dit-il. Je me suis dit : « Qu'est-ce que je vais faire à ce sujet ? Cela affecte tout.

La technique de Kaminsky pourrait être utilisée pour diriger les internautes vers n'importe quelle page Web choisie par un attaquant. L'utilisation la plus évidente est d'envoyer des personnes vers des sites de phishing (sites Web conçus pour amener les gens à saisir des mots de passe bancaires et d'autres informations personnelles, permettant à un attaquant de voler leur identité) ou d'autres fausses versions de pages Web. Mais le danger est encore pire : les protocoles tels que ceux utilisés pour envoyer des e-mails ou pour des communications sécurisées sur Internet reposent en fin de compte sur DNS. Un attaquant créatif pourrait utiliser la technique de Kaminsky pour intercepter des e-mails sensibles ou pour créer des versions falsifiées des certificats qui garantissent des transactions sécurisées entre les utilisateurs et les sites Web bancaires. Chaque jour, je trouve un autre domino, dit Kaminsky. Une autre chose tombe si le DNS est mauvais. … Je veux dire, littéralement, vous regardez autour de vous et voyez tout ce qui utilise un réseau – tout ce qui utilise un réseau – et cela utilise probablement le DNS.

Multimédia

• Affichez un aperçu d'une attaque d'empoisonnement du cache.

Kaminsky a appelé Paul Vixie, président de l'Internet Systems Consortium, une société à but non lucratif qui prend en charge plusieurs aspects de l'infrastructure Internet, y compris le logiciel le plus couramment utilisé dans le système de noms de domaine. Habituellement, si quelqu'un veut signaler un problème, vous vous attendez à ce qu'il lui faille pas mal de temps pour l'expliquer - peut-être un tableau blanc, peut-être un document Word ou deux, dit Vixie. Dans ce cas, il lui a fallu 20 secondes pour expliquer le problème, et encore 20 secondes pour qu'il réponde à mes objections. Après cela, j'ai dit: 'Dan, je te parle sur un téléphone portable non sécurisé. S'il vous plaît, ne dites plus jamais à personne ce que vous venez de me dire sur un téléphone portable non sécurisé.

Le plus effrayant était peut-être que, parce que la vulnérabilité n'était localisée dans aucun matériel ou logiciel particulier, mais dans la conception du protocole DNS lui-même, il n'était pas clair comment la corriger. En secret, Kaminsky et Vixie ont réuni certains des meilleurs experts DNS au monde : des membres du gouvernement américain et des ingénieurs de haut niveau des principaux fabricants de logiciels et de matériel DNS, dont Cisco et Microsoft. Ils ont organisé une réunion en mars sur le campus de Microsoft à Redmond, WA. Les arrangements étaient si secrets et précipités, dit Kaminsky, qu'il y avait des gens sur des jets pour Microsoft qui ne savaient même pas quel était le bogue.

Une fois à Redmond, le groupe a tenté de déterminer l'étendue de la faille et de trouver une solution possible. Ils ont opté pour une mesure provisoire qui résolvait la plupart des problèmes, serait relativement facile à déployer et masquerait la nature exacte de la faille. Étant donné que les attaquants identifient généralement les failles de sécurité par des correctifs d'ingénierie inverse destinés à les corriger, le groupe a décidé que tous ses membres devaient publier le correctif simultanément (la date de sortie serait le 8 juillet). Kaminsky a également demandé aux chercheurs en sécurité de ne pas spéculer publiquement sur les détails de la faille pendant 30 jours après la publication du correctif, afin de donner aux entreprises suffisamment de temps pour sécuriser leurs serveurs.

Le 6 août, lors de la conférence Black Hat, le rassemblement annuel des experts mondiaux de la sécurité Internet, Kaminsky révélerait publiquement quelle était la faille et comment elle pouvait être exploitée.

Demander des ennuis
Kaminsky n'a pas vraiment découvert une nouvelle attaque. Au lieu de cela, il a trouvé un moyen ingénieux de donner vie à un très ancien. En effet, la faille fondamentale ciblée par son attaque est antérieure à Internet lui-même.

La fondation du DNS a été posée en 1983 par Paul Mockapetris, alors à l'Université de Californie du Sud, à l'époque d'ARPAnet, le projet de recherche du département américain de la Défense qui reliait les ordinateurs à un petit nombre d'universités et d'instituts de recherche et a finalement conduit à Internet. . Le système est conçu pour fonctionner comme le service 411 d'une compagnie de téléphone : à partir d'un nom, il recherche les numéros qui mèneront au porteur de ce nom. Le DNS est devenu nécessaire à mesure qu'ARPAnet dépassait la capacité d'un individu à garder une trace des adresses numériques dans le réseau. Mockapetris, qui est maintenant président et scientifique en chef de Nominum, un fournisseur de logiciels d'infrastructure basé à Redwood, en Californie, a conçu le DNS comme une hiérarchie. Lorsqu'une personne tape l'URL d'une page Web dans un navigateur ou clique sur un lien hypertexte, une demande est transmise à un serveur de noms géré par le fournisseur de services Internet (FAI) de l'utilisateur. Le serveur du FAI stocke les adresses numériques des URL qu'il gère fréquemment, au moins jusqu'à l'expiration de leur durée de vie. Mais s'il ne trouve pas d'adresse, il interroge l'un des 13 serveurs racine DNS, qui dirige la demande vers un serveur de noms responsable de l'un des domaines de premier niveau, comme .com ou .edu. Ce serveur transmet la demande à un serveur spécifique à un seul nom de domaine, tel que google.com ou mit.edu. Le transfert se poursuit via des serveurs avec des responsabilités de plus en plus spécifiques - mail.google.com ou library.mit.edu - jusqu'à ce que la demande atteigne un serveur qui peut soit donner l'adresse numérique demandée, soit répondre qu'une telle adresse n'existe pas. À mesure qu'Internet mûrissait, il est devenu évident que le DNS n'était pas suffisamment sécurisé. Le processus de transmission d'une requête d'un serveur à l'autre donne aux attaquants de nombreuses opportunités d'intervenir avec de fausses réponses, et le système n'avait aucune protection pour garantir que le serveur de noms répondant à une requête était digne de confiance. Dès 1989, selon Mockapetris, il y a eu des cas d'empoisonnement du cache, dans lesquels un serveur de noms a été amené à stocker de fausses informations sur l'adresse numérique associée à un site Web.
Dans les années 1990, le travail d'empoisonneur était relativement facile. Les serveurs de noms de niveau inférieur sont généralement maintenus par des entités privées : Amazon, par exemple, contrôle les adresses fournies par le serveur de noms amazon.com. Si un serveur de noms de bas niveau ne peut pas trouver une adresse demandée, il renverra le demandeur vers un autre serveur de noms ou indiquera au demandeur que la page n'existe pas. Mais dans les années 90, le serveur de bas niveau pouvait également fournir au demandeur l'adresse du serveur de niveau supérieur. Pour empoisonner un cache, un attaquant devait simplement falsifier cette information. Si un attaquant trompait, disons, le serveur de noms d'un FAI en stockant la mauvaise adresse pour le serveur .com, il pourrait détourner la majeure partie du trafic circulant sur le réseau du FAI. Mockapetris dit que plusieurs fonctionnalités ont par la suite été ajoutées au DNS pour protéger le système. Les serveurs demandeurs ont cessé d'accepter les adresses numériques de niveau supérieur des serveurs de noms de niveau inférieur. Mais les attaquants ont trouvé un moyen de contourner cette restriction. Comme auparavant, ils renvoyaient un demandeur, disons, au serveur .com. Mais maintenant, le demandeur devait rechercher lui-même l'adresse du serveur .com. Il demanderait l'adresse et l'attaquant se précipiterait pour répondre avec une réponse falsifiée avant que la vraie réponse n'arrive. Des mesures de sécurité ad hoc ont également été ajoutées pour se protéger contre cette stratégie. Désormais, chaque requête adressée à un serveur DNS porte un identifiant de transaction généré de manière aléatoire, l'un des 65 000 nombres possibles, que la réponse doit également contenir. Un attaquant se précipitant pour battre une réponse légitime devrait également deviner l'ID de transaction correct. Malheureusement, un ordinateur peut générer tellement de fausses réponses si rapidement que s'il a suffisamment de chances, il trouvera forcément le bon identifiant. Ainsi, le temps de vivre, destiné à l'origine à empêcher les serveurs de noms d'être surchargés par un trop grand nombre de demandes, est devenu une autre fonctionnalité de sécurité provisoire. Étant donné que le serveur demandeur stockera une réponse pendant un certain temps, l'attaquant n'a que quelques chances de tenter une falsification. La plupart du temps, lorsque le serveur a besoin d'une adresse .com, il consulte son cache plutôt que de vérifier auprès du serveur .com. Kaminsky a trouvé un moyen de contourner ces fonctionnalités de sécurité ad hoc, le plus important, le temps de vivre. Cela rendait le système tout aussi vulnérable qu'il l'était lors de la découverte de l'empoisonnement du cache. En utilisant la technique de Kaminsky, un attaquant a un nombre presque infini de chances de fournir un faux. Supposons qu'un attaquant veuille détourner tous les e-mails qu'un site de réseautage social comme Facebook ou MySpace envoie aux comptes Gmail. Il crée un compte sur le réseau social et lorsqu'on lui demande une adresse e-mail, il en fournit une qui pointe vers un domaine qu'il contrôle. Il commence à se connecter au réseau social mais affirme avoir oublié son mot de passe. Lorsque le système essaie d'envoyer un nouveau mot de passe, il effectue une recherche DNS qui mène au domaine de l'attaquant. Mais le serveur de l'attaquant prétend que l'adresse demandée est invalide. À ce stade, l'attaquant pourrait renvoyer le demandeur aux serveurs de noms de google.com et se précipiter pour fournir une réponse falsifiée. Mais alors, il n'aurait qu'une seule chance de déchiffrer l'ID de transaction. Au lieu de cela, il renvoie le demandeur vers les domaines inexistants 1.google.com, puis 2.google.com, puis 3.google.com, et ainsi de suite, envoyant un flot de réponses bidons pour chacun. À chaque fois, le serveur demandeur consultera les serveurs de noms de Google plutôt que son cache, car il n'aura stocké d'adresses pour aucune des fausses URL. L'attaque contourne complètement les limites fixées par le temps à vivre. L'une des falsifications de l'agresseur est vouée à passer. Ensuite, il suffit de diriger tout ce que le serveur demandeur souhaite pour Google vers les propres serveurs de l'attaquant, car l'attaquant semble avoir autorité sur les URL se terminant par google.com. Kaminsky dit qu'il était capable de réaliser des attaques de test en aussi peu que 10 secondes.

Une attaque d'empoisonnement de cache
L'empoisonnement du cache amène un serveur demandeur à stocker de fausses informations sur l'adresse numérique associée à un site Web. Une version de base de l'attaque - sans certaines des techniques les plus sophistiquées employées par Kaminsky - est décrite ci-dessous. 1. Pour commencer, l'attaquant incite le serveur de la victime à contacter un domaine qu'il contrôle. L'attaquant pourrait, par exemple, prétendre avoir oublié un mot de passe, incitant la victime à répondre par e-mail.
2. La victime effectue une recherche DNS pour savoir où envoyer l'e-mail. Mais le serveur de noms de l'attaquant renvoie la victime à un autre serveur, comme celui de example.com. Étant donné que l'attaquant sait que la victime va maintenant lancer une recherche DNS pour ce serveur, il a la possibilité de tenter d'empoisonner son cache. 3. L'attaquant essaie de fournir une fausse réponse avant que le serveur légitime ne puisse fournir la vraie. Si l'attaquant devine le bon numéro d'identification, la victime accepte la réponse de devinette, ce qui empoisonne le cache.
Dans le noir
Le 8 juillet, Kaminsky a tenu la conférence de presse promise, annonçant la sortie du correctif et demandant aux autres chercheurs de ne pas spéculer sur la faille. Les fournisseurs de matériel et de logiciels avaient opté pour un correctif qui oblige un attaquant à deviner un ID de transaction plus long. Kaminsky dit qu'avant le patch, l'attaquant a dû faire des dizaines de milliers de tentatives pour réussir à empoisonner un cache. Après le patch, il lui faudrait gagner des milliards. La nouvelle de la faille est apparue dans le New York Times, sur le site Web de la BBC et dans presque toutes les publications techniques. Les administrateurs système se sont efforcés de faire fonctionner le correctif dans leurs systèmes avant qu'ils ne puissent être attaqués. Mais parce que Kaminsky n'a pas fourni de détails sur la faille, certains membres de la communauté de la sécurité étaient sceptiques. Thomas Ptacek, chercheur chez Matasano Security, a posté sur Twitter : Dites-le ici d'abord : douter qu'il y ait vraiment de la viande à cette annonce de sécurité DNS. Dino Dai Zovi, un chercheur en sécurité connu pour avoir trouvé des moyens de diffuser des logiciels malveillants sur un Macbook Pro entièrement corrigé, déclare que j'étais définitivement sceptique quant à la nature de la vulnérabilité, notamment en raison du battage médiatique et de l'attention par rapport au faible nombre de détails. . Chaque fois que je vois quelque chose comme ça, je mets instantanément mon chapeau sceptique, car cela ressemble beaucoup à quelqu'un avec un intérêt direct plutôt qu'à quelqu'un qui essaie de réparer quelque chose. Dai Zovi et d'autres ont noté que le moment était parfait pour promouvoir l'apparition de Black Hat de Kaminsky, et ils se sont hérissés à la demande de s'abstenir de toute spéculation. Le manque d'informations était particulièrement controversé car les administrateurs système sont souvent chargés d'évaluer les correctifs et de décider s'ils doivent les appliquer, en pesant le danger de la faille de sécurité par rapport à la perturbation que le correctif provoquera. Étant donné que le DNS est au cœur du fonctionnement de toute organisation dépendante d'Internet, le modifier n'est pas quelque chose qui se fait à la légère. Pour aggraver les choses, ce correctif ne fonctionnait pas correctement avec certains types de pare-feu d'entreprise. De nombreux professionnels de l'informatique ont exprimé leur frustration face au manque de détails, affirmant qu'ils n'étaient pas en mesure d'évaluer correctement le correctif alors que tant de choses restaient cachées. Préoccupé par le scepticisme suscité par ses affirmations, Kaminsky a tenu une conférence téléphonique avec Ptacek et Dai Zovi, dans l'espoir de leur faire voir à quel point le virus était dangereux. Les deux sont sortis de l'appel convertis. Mais bien que Dai Zovi note que beaucoup de choses ont changé depuis l'époque où les fabricants de matériel et de logiciels traitaient les failles en niant simplement que les chercheurs en sécurité aient identifié de vrais problèmes, il dit également : Nous ne savons pas quoi faire lorsque les vulnérabilités sont vraiment importantes. systèmes comme DNS. Les chercheurs sont confrontés à un dilemme, dit-il : ils doivent expliquer les défauts afin de convaincre les autres de leur gravité, mais une vulnérabilité comme celle trouvée par Kaminsky est si grave que la révélation de ses détails pourrait mettre le public en danger. Halvar Flake, un chercheur allemand en sécurité, était un observateur qui pensait que garder le silence était l'alternative la plus nocive. La spéculation publique est exactement ce qu'il faut, dit-il, pour aider les gens à comprendre ce qui pourrait les frapper. Flake a lu quelques documents de base, y compris l'entrée Wikipédia allemande sur DNS, et a écrit une entrée de blog sur ce qu'il pensait que Kaminsky aurait pu trouver. Déclarant que sa supposition était probablement fausse, il a invité d'autres chercheurs à le corriger. D'une manière ou d'une autre, au milieu de l'agitation que son message a provoquée dans la communauté de la sécurité, une explication détaillée de la faille est apparue sur un site hébergé par l'employeur de Ptacek, Matasano Security. L'explication a été rapidement supprimée, mais pas avant qu'elle n'ait proliféré sur Internet. Le chaos s'ensuivit. Kaminsky a posté sur Twitter, le bogue DNS est public. Vous devez appliquer un correctif ou passer à OpenDNS [basé sur le Web], MAINTENANT. En quelques jours, Metasploit, un projet de sécurité informatique qui conçoit des exemples d'attaques pour faciliter les tests, a publié deux modules exploitant la faille de Kaminsky. Peu de temps après, l'une des premières attaques basées sur la faille DNS a été observée dans la nature. Il a pris le contrôle de certains serveurs d'AT&T afin de présenter une fausse page d'accueil Google, chargée des propres publicités de l'attaquant. Plus de cookies
Trente minutes avant que Kaminsky ne monte sur scène à Black Hat pour enfin révéler les détails de la faille, les gens ont commencé à inonder la salle de bal du Caesar's Palace à Las Vegas. L'orateur précédant Kaminsky s'empressa de conclure. Il n'y avait plus de sièges et les gens s'asseyaient les jambes croisées sur chaque centimètre carré de tapis. La grand-mère de Kaminsky, qui était assise au premier rang, avait préparé 250 biscuits pour l'événement. Il n'y en avait pas assez. Kaminsky est monté sur le podium. Il y a beaucoup de monde, dit-il. Putain de merde. Kaminsky est grand et ses gestes sont un peu maladroits. Au début du mois d'août, a-t-il déclaré, plus de 120 millions de clients haut débit avaient été protégés, car les fournisseurs de services Internet appliquaient des correctifs. Soixante-dix pour cent des entreprises Fortune 500 avaient corrigé leurs systèmes, et 15 pour cent supplémentaires y travaillaient. Cependant, a-t-il ajouté, 30 à 40 pour cent des serveurs de noms sur Internet n'étaient toujours pas corrigés et vulnérables à son attaque d'empoisonnement du cache de 10 secondes. Sur scène, il a basculé entre une description joyeuse des sombres possibilités de sa découverte et des tentatives de rassembler le sérieux approprié à leur gravité. Il a parlé pendant 75 minutes, devenant visiblement plus léger alors qu'il se débarrassait de sept mois de secrets. Alors qu'il terminait son discours, la foule s'est approchée de lui et il a été emmené par un journaliste après l'autre. Même les experts en sécurité qui ont convenu que la vulnérabilité était grave ont été déconcertés par l'empressement de Kaminsky à attirer l'attention des médias et ses efforts incessants pour faire connaître la faille. Plus tard dans la journée, Kaminsky a reçu le prix Pwnie du bogue le plus surmédité par un groupe de chercheurs en sécurité. (Le mot pwn, qui rime avec propre, est un argot Internet pour dominer complètement. Le prix de Kaminsky est sous-titré The Pwnie pour pwning les médias.) Dai Zovi, présentant le prix, a essayé de répertorier les publications qui avaient diffusé l'histoire de Kaminsky. Il a renoncé, en disant, Qu'est-ce que n'étiez-vous pas?GQ! a crié quelqu'un dans le public. Kaminsky est monté sur scène et a craché deux phrases : Certaines personnes trouvent des insectes ; certaines personnes ont des bugs corrigés. Je suis content d'être dans la deuxième catégorie. Balançant le prix – un poney en peluche doré – par ses cheveux rose vif, il descendit la longue allée de la salle de bal et sortit par la porte. Qui est en charge?
Selon votre point de vue, la façon dont Kaminsky a géré la faille DNS et son correctif était soit une démagogie dangereuse qui a inutilement attiré l'attention du public sur la vulnérabilité d'Internet, soit, selon Kaminsky, un piratage médiatique nécessaire pour attirer l'attention sur les dangers du bogue. Quoi qu'il en soit, l'histoire montre l'absence troublante de tout processus d'identification et de correction des failles critiques d'Internet. Parce qu'Internet est tellement décentralisé, il n'y a tout simplement pas de personne ou d'organisation spécifique chargée de résoudre ses problèmes. Et bien que le défaut de Kaminsky soit particulièrement grave, les experts disent que ce n'est probablement pas le seul dans l'infrastructure d'Internet. De nombreux protocoles Internet n'ont pas été conçus pour les usages auxquels ils sont destinés aujourd'hui ; bon nombre de ses fonctionnalités de sécurité ont été ajoutées et ne traitent pas les vulnérabilités sous-jacentes. À long terme, sur le plan architectural, nous devons cesser de supposer que le réseau est aussi convivial qu'il l'est, dit Kaminsky. Nous sommes simplement accros au déplacement d'informations sensibles sur Internet de manière non sécurisée. Nous pouvons faire mieux. En effet, lors d'une autre conférence sur la sécurité quelques jours seulement après la présentation de Kaminsky à Black Hat, une équipe de chercheurs a donné une conférence illustrant de graves failles dans le protocole de passerelle de routage d'Internet. Comme Kaminsky, les chercheurs avaient découvert des problèmes avec la conception fondamentale d'un protocole Internet. Comme la faille DNS, le problème pourrait permettre à un attaquant d'obtenir un large accès au trafic sensible envoyé sur Internet.
De nombreux experts disent que ce qui s'est passé avec la faille DNS représente le meilleur des cas. Mischel Kwon, directeur de l'US-CERT, une division du Department of Homeland Security qui a aidé à faire connaître le bogue DNS, espère que le réseau d'organisations qui ont travaillé ensemble dans cette affaire fera de même si d'autres failles apparaissent. Bien qu'il n'y ait pas de hiérarchie d'autorité dans le secteur privé, dit Kwon, il existe des liens solides entre les entreprises et les organisations ayant le pouvoir de déployer des correctifs. Elle dit qu'elle est convaincue que, compte tenu de l'argent et des efforts investis dans l'amélioration de la sécurité sur Internet, les protocoles obsolètes seront mis à jour. Mais cette confiance ne repose pas sur une stratégie mûrement réfléchie. Et si Kaminsky n'avait pas eu de relations étendues au sein de la communauté de la sécurité ou, pire, ne s'était pas engagé à corriger la faille en premier lieu ? Et s'il avait été un vrai chapeau noir déterminé à exploiter la vulnérabilité qu'il avait découverte ? Et si sa manipulation apparemment habile des médias s'était retournée contre lui et que les détails de la faille étaient connus avant la mise en place du correctif ? De plus, même compte tenu des bonnes intentions de chercheurs comme Kaminsky, corriger les défauts de base d'Internet n'est pas facile. Les experts s'accordent à dire que le problème DNS ne fait pas exception. Plusieurs propositions sont sur la table pour le résoudre par des moyens plus fiables qu'un patch, principalement en réduisant la confiance qu'un serveur demandeur accorde à un serveur de noms. Les propositions vont de correctifs relativement simples, tels que l'inclusion d'informations encore plus aléatoires dans les demandes adressées aux serveurs de noms, au transfert de l'ensemble du système vers un ensemble de protocoles permettant aux serveurs de noms de signer leurs réponses de manière cryptographique. En attendant, Kaminsky et Vixie affirment que les attaquants ont commencé à utiliser la faille DNS et s'attendent à ce que davantage de problèmes surviennent. Kaminsky note que la faille devient particulièrement dangereuse lorsqu'elle est exploitée avec d'autres vulnérabilités. Une telle combinaison, dit-il, permettrait à un attaquant de prendre en charge les mises à jour automatiques qu'un fournisseur de logiciels envoie à ses clients, en les remplaçant par des logiciels malveillants. Kaminsky dit qu'il a passé les derniers mois au téléphone avec des entreprises qui seraient des cibles attrayantes pour ce type d'attaque, telles que les autorités de certification, les réseaux sociaux et les fournisseurs de services Internet, essayant de les convaincre de patcher dès que possible. Ce qui fait peur, dit Dai Zovi, c'est à quel point [Internet] est fragile. … Et qu'allons-nous faire à ce sujet? Erica Naone est rédactrice adjointe à Revue de la technologie.

cacher