Le « système des noms de domaines » est un ensemble de standards décrivant le fonctionnement d'une part essentielle de l'infrastructure d'Internet : celle qui permet par exemple à votre navigateur de savoir à quel serveur il doit se connecter en fonction de l'adresse que vous avez tapée. On parle des serveurs DNS ou serveurs de noms pour désigner les nombreux agents qui opèrent, dans l'ombre, cette traduction pour vous.

Ces serveurs sont structurés selon une hiérarchie, à travers laquelle transitent nos requêtes (« quelqu'un connaît le numéro du serveur www.exemple.com ? ») et les réponses des agents compétents. Certains de ces agents sont responsable de multiples noms de domaines, d'autres sont de simples intermédiaires. Tout cela fonctionne très bien. Mais le problème est que la manière de communiquer de ces serveurs n'est pas formidablement protégée.

En fait, l'on se rend compte qu'il est possible de truquer certaines de ces réponses, par divers procédés et à diverses échelles, dans des conditions de plus en plus réalistes. En clair, cela signifie que l'on pourrait vous faire croire, par exemple, que vous êtes connectés au site de votre banque, alors que vous êtes en réalité connecté à un serveur mouchard. Et c'est de plus en plus « facile ».

Mobilisation internationale

C'est pour mieux maîtriser ce type de risques que CISCO, Sun, Microsoft et de nombreuses autres grandes sociétés et organisations internationales se sont mobilisés ces derniers jours, sous l'impulsion de Dan Kaminsky. Ce chercheur, reconnu dans le milieu de la sécurité, semble avoir découvert il y a environ une année une technique d'attaque inédite reposant sur un défaut de conception du système. Cette technique permettrait facilement de forcer des agents intermédiaires à stocker des adresses de serveurs trafiquées dans leur cache.

Pas facile de résoudre le problème : il faudrait modifier en profondeur le standard utilisé et déployer ces modifications à l'échelle internationale. Plus réalistement, les experts réunis autour de Kaminsky ont choisi de seulement renforcer certains aspects du système actuel, d'une façon qui rende la nouvelle attaque impratiquable - du moins pour un temps.

Des correctifs ont ainsi été mis à disposition et les administrateurs réseau sont invités à les appliquer d'urgence sur leurs serveurs. Une campagne de sensibilisation, bien contrôlée jusqu'à maintenant, laisse filtrer quelques informations technique - en attendant le 6 août prochain, où Kaminsky rendra publique ses traveaux lors de la conférence Black Hat à Las Vegas.

Faut-il avoir peur ?

Pour les utilisateurs, le risque principal se situe au niveau des fournisseurs d'accès. Les serveurs DNS de relais qu'ils mettent à la disposition à notre disposition peuvent en effet être la cible de cette attaque. On peut bien sûr espérer qu'ils seront les premiers, si ce n'est déjà fait, à mettre à jour leurs serveurs.

Parallèlement à cela, il faut tenir compte du fait que la plupart des sites sensibles utilisent une couche de protection supplémentaire : SSL (les adresses commençant par le fameux https://). Ce procédé, bien qu'il ne soit pas infaillible, permet de crypter et de signer la communication entre le serveur et votre navigateur. En pratique, cela vous permet de vérifier avec une relative certitude que le site sur lequel vous êtes connecté est bien celui qu'il prétend être (mais il faut pour cela vérifier que le certificat SSL correspond bien à l'institution en question, en cliquant sur l'icone en forme de cadenas du navigateur).

Enfin, il faut comprendre que la mise en oeuvre, hors du laboratoire, de ce type d'attaques n'est pas forcément à la portée du premier adolescent venu : cela suppose la mise en place d'une petite infrastructure et demandes certaines connaissances avancées ainsi que de l'organisation. De plus les informations techniques disponibles à ce sujet sont encore éparses.

Il ne faut donc pas s'attendre à un déploiement massif de ces attaques dans les semaines à venir. Mais un minimum de prudence n'est jamais superflu sur Internet.

Mise à jour : les détails techniques de la faille semblent avoir été rendus publics. Voir notre article.

Pour en savoir plus

• http://www.doxpara.com/?p=1164
• http://www.kb.cert.org/vuls/id/800113