Une vulnérabilité (Réf. Lexsi 10364) touchant les principaux serveurs DNS a été publiée aujourd'hui de manière coordonnée, les correctifs pour les produits Microsoft DNS et ISC Bind étant disponibles. Cette faille peut permettre à un attaquant de mener à bien des attaques de DNS Cache Poisoning, et donc de pratiquer du Pharming.

Concrètement le principe de l'attaque est connu depuis longtemps, des publications sur le sujet sont d'ailleurs datées de plus de deux ans. Le scénario mis en œuvre repose sur le fait que pour pouvoir forger une réponse DNS en lieu et place du serveur DNS légitime, il faut pouvoir connaitre l'adresse IP de ce serveur, la nature de la demande, le numéro de transaction DNS et enfin le port source utilisé par le serveur victime (celui qui effectue la demande). Avantage pour l'attaquant, pas de problème de session à gérer en couche 4, puisque le tout s'effectue en UDP.

S'il est facile de prévoir les deux premiers paramètres, le numéro de transaction DNS et le port source utilisés devraient être suffisamment imprévisibles pour empêcher l'usurpation. Et c'est semble-t-il la raison pour laquelle cette attaque est revenue sur le devant de la scène, car il s'avère qu'il pourrait être plus simple que prévu de deviner le numéro de port source utilisé par le serveur victime, ce dernier ayant tendance à ne pas utiliser tout l'espace des choix possibles, ou à avoir, en pratique, un espace restreint.

Ainsi, les serveurs DNS Bind choisissent par exemple un port source UDP au démarrage, puis le conservent pour toutes les requêtes à venir. Combiné au problème connu de l'espace restreint du choix du numéro de transaction DNS (codé sur 16 Bits, soit en théorie 65536 possibilités, mais incrémental sur certaines implémentations ...), cela réunit des conditions favorables pour tenter l'attaque.

D'après l'ISC, Dan Kaminsky, qui est à l'origine de la réaction des éditeurs, devrait publier tous les détails de l'attaque et de la vulnérabilité lors de la conférence Black Hat le 7 Aout. Prudence est mère de sureté, il y a donc peut-être des éléments importants qui n'ont pas encore été révélés.

C'est pourquoi dans l'attente il est important de corriger le problème sur les serveurs concernés, c'est à dire ceux qui effectuent des résolutions pour des domaines sur lesquels ils n'ont pas autorité, et en sachant que la correction joue plutôt sur l'augmentation de l'imprévisibilité du port UDP source utilisé.

Mise à jour

Toujours aussi peu d'informations sur cette vulnérabilité, mais ceux (ici et là) qui ont pu voir les détails confirment le caractère critique de la faille : il va falloir patcher !