mercredi 17 septembre 2003, 18h35

Pourquoi faut-il avoir peur du WildCard DNS de Verisign sur .COM et .NET?

Depuis le mardi 16 Septembre, Verisign Registry, qui gère les DNS des domaines .COM, .NET et quelques autres annexes, a installé un "WILDCARD DNS" pointant vers l'un de ses serveurs web.


[/b]Qu'est ce qu'un Wildcard DNS? [/b]

C'est un enregistrement DNS (nom de domaine internet) qui permet de répondre une valeur identique à toutes les questions. D'un point de vue utilisateur, cela revient à dire que depuis cette nuit, .com existe et est dirigé sur le serveur Verisign http://sitefinder.verisign.com/.

Ceci n'est évidemment en place que pour les domaines qui n'existent pas (ou accessoirement et plus sournoisement, qui n'ont pas été payés à temps, ou qui ont été réservés et "parqués" sans serveur DNS enregistré).

Quelles sont les conséquences immédiates?

Tout utilisateur faisant une erreur de domaine en tapant une URL dans son navigateur, telle que www.ma-socciete.com au lieu de www.ma-societe.com, sera envoyé sur le serveur de Verisign.

Cela signifie aussi que tous les messages électroniques (e-mails) envoyés à une adresse dont la partie droite est erronée, telle que utilisateur@ma-socciete.com sera dirigé sur le serveur de Verisign (et refusé avec un message d'erreur en anglais).

Pourquoi font-ils ça?

Leur prétexte est que cela permet aux utilisateurs d'avoir une réponse plus précise que le sempiternel "This domain does not exists".

Pourquoi font-ils réellement ça?

Il y a plusieurs réponses, sans doute complémentaires:

Attirer des publicitaires sur un site qui va être accédé des millions de fois par jour.

Regarder quels sont les domaines les plus tapés en erreur, et vendre ces noms de domaines erronés aux propriétaires des domaines "voisins".

Se procurer une liste d'adresses e-mail valides afin de la revendre à des sociétés de marketing électronique (aka spammers).

Tracer vos habitudes (cf. paragraphe suivant).

Pourquoi c'est mal?

Là aussi, de multiples raisons:

Si vous vous trompez d'une seule lettre dans une URL, vous allez envoyer toute l'URL, ainsi que le Referer (l'endroit d'ou vous venez) à Verisign. Cette URL peut contenir des données très confidentielles, comme un mot de passe, une donnée d'identification, un numéro d'article...

La page sur laquelle on arrive contient un webbug (image blanche 2 par 2) placé sur le site 2o7.net, qui envoie un cookie à votre navigateur. Cela signifie que ce site, affilié à Verisign, connaît toutes vos fautes de frappes et erreurs, et est capable d'en faire un historique.

Le serveur de messagerie utilisé est complètement cassé, et ne suit pas le protocole SMTP. En particulier si un message est envoyé à plus de deux personnes, il va interrompre la transaction de telle manière qu'il restera plusieurs jours dans la file de votre serveur de messagerie.

Le site sitefinder.verisign.com est complètement saturé et ne répond que très lentement. Vous ne vous rendez donc pas compte immédiatement que vous vous êtes trompés.

Si les administrateurs de votre domaine ont installé un serveur de messagerie électronique qui envoie des messages en français quand le domaine est erroné, ce message n'est plus émis pour les domaines en .com et .net .

Il y a probablement des traces de domaines ayant expiré ou disparu dans de nombreuses configurations de logiciel, domaines qui ont subitement réapparu depuis le 16 septembre. Il faut s'attendre à divers effets de bord très gênants.

De nombreuses sociétés utilisent en interne des noms de domaines non officiels, qui existent désormais. Ainsi un PC qui cherchait www.masociete-interne.com dans le DNS avant de le rechercher dans un serveur Wins ou un fichier local, va désormais le trouver pointant vers une machine extérieure.

Enfin, sur le plan juridique, Verisign semble être complètement en dehors de son contrat avec l'ICANN qui lui confie la gestion technique de .COM et .NET.

Que peut-on faire?

Tout dépend de votre infrastructure:

Si vous êtes un utilisateur seul, vous pouvez commencer par bloquer la réception de cookies des sites verisign.com et 2o7.net.

Vous pouvez mettre le site sitefinder.verisign.com dans votre fichier HOSTS (C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS) pointant sur 127.0.0.1, afin que votre navigateur n'aille pas de lui-même sur le site Verisign, mais soit plutôt redirigé vers votre machine elle même: 127.0.0.1 sitefinder.verisign.com

Si vous avez un relais HTTP sortant par lequel transitent vos utilisateurs, vous pouvez bloquer l'adresse 64.94.110.11 dans les sites autorisés. Il faut consulter la documentation de votre relais. Dans le relais squid, la séquence à utiliser est de type: acl verisign dst 64.94.110.11/255.255.255.255 http_access deny verisign http_access allow

Vous pouvez également bloquer l'adresse via un filtrage IP en sortie, ou router la machine vers Null0 sur Cisco IOS: ip route 64.94.110.11 255.255.255.255 Null0. À noter que cela bloquera les messages e-mails sortants, qui resteront en attente sur votre serveur de messagerie. Ce n'est donc pas forcément une solution idéale.

Selon le type de votre serveur de messagerie, il peut exister des méthodes pour bloquer une adresse IP en sortie. Ce type de filtrage n'est malheureusement pas très répandu.

Des "correctifs" sont en préparation pour le serveur DNS bind, qui rejettera toute réponse contenant 64.94.110.11 comme résultat.

Vous pouvez écrire poliment à Verisign en leur expliquant que leur politique et leurs "Terms of Use" (http://sitefinder.verisign.com/terms.jsp) ne vous conviennent pas, et donc que vous ne pouvez pas utiliser leur système. Il faut donc que ce dernier ne vous permette pas d'utiliser leur moteur de recherche. C'est ce qu'ont commencé à faire de nombreuses personnes.

Il faut écrire à:

VeriSign, Inc.
Attention: Legal Department
21355 Ridgetop Circle
Dulles, VA 20166
États-Unis

* Alain Thivillon est consultant senior au sein du cabinet HSC, spécialisé dans la sécurité informatique. Il a travaillé sur de nombreux sujets, notamment sur les infrastructures réseau, la messagerie SMTP, les annuaires LDAP et les serveurs web sécurisés.

Alain Thivillon*