e-Construction : Mon cyber-journal perso

"L'intelligence c'est d'apprendre de ses erreurs, la sagesse c'est d'apprendre de celles des autres..."


Dans le billet précédent, j'ai terminé par remarquer que des requêtes DNS me semblaient bizarres parce qu'elles répétaient la même question au serveur en changeant la casse des lettres constituant le nom de domaine.

Dans ce genre de cas, c'est un des deux :
1- On est devant un truc vraiment intéressant et original
2- C'est quelque chose de banal et de trivial, et c'est nous qui avons raté une info basique

Inutile de dire que dans le plupart des cas, c'est plutôt le 2 :)

Revenons quand même à notre intrique. A ma connaissance, et selon même les RFC 1034 et 1035, la casse n'a pas d'importance dans un nom de domaine donné (voir section Preferred name syntax).
Par exemple : machin.truc = MaChin.TRUC

Alors, pourquoi certains clients (10 exactement) émettent des requêtes en variant la casse de certaines lettres ?!!

J'avoue que j'ai cherché à déceler la combinaison selon laquelle se font les variations, à voir de plus près qui sont ces clients bizarres pour moi ... en construisant plein d'hypothèses, des plus anodines au plus invraisemblables.

Mais après cette dose de paranoïa, une voix de lucidité est venue me souffler qu'il fallait peut-être voir du côté de l'ami Google s'il n'y avait pas quelque chose du même genre.

Après quelques minutes, je trouve l'explication qui me convient (pour le moment :) )

Toute cette histoire est liée aux techniques de lutte contre le cache poisoning des resolveurs DNS.

Les méchants essayent d'induire en erreur les clients DNS en leur fournissant de fausses-vraies réponses en se substituant au serveur DNS demandé.

Pour lutter contre ce type d'attaque, l'idée est d'avoir le plus possible de valeurs non (ou difficilement) déduisables par l'attaquant.

Deux éléments d'une transaction DNS sont largement connu et implémentés, surtout suite aux travaux de Dan Kaminsky de l'année passée. Ce sont le port UDP source et l'IDentifiant de la transaction. Il s'agit de les rendre le plus aléatoires possibles....mais ça reste jouable pour un attaquant s'il a le temps et les ressources suffisantes.

L'idée alors est de compliquer encore plus la vie de l'attaquant, en ajoutant un autre élément aléatoire ... vous avez deviné, c'est la casse des lettres constituant la question à résoudre. Le concept a été proposé par Paul Vixie et David Dagon sous forme d'un INTERNET-DRAFT de l'IETF en Mars 2008 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity".

En gros, ils proposent que le resolveur envoi une requête en variant la casse de la question. Les serveurs DNS en leur majorité, bien que les RFC ne le disent pas, copient bit à bit la question pour l'utiliser dans leur réponse.

Exemple, je demande à un serveur DNS de résoudre le nom www.SitE.Dz . Dans ses enregistrements, le serveur a l'@IP correspondante à www.site.dz, mais il va me répondre "www.SitE.dZ = 10.10.1.1" en respectant la casse comme il l'a reçu.... et là, le client en vérifiant la réponse, va savoir si c'est le vrai serveur qu'il a interrogé et c'est un autre qui veut l'induire en erreur.
Pour faire passer son coup, l'attaquant doit prédire la bonne combinaison en minuscule et en majuscule...en plus du bon port UDP...en plus du bon TXID .

Cette idée est petit à petit implémentée dans plusieurs resolveurs DNS (celui utilisé par tor par exemple) .

Enfin, ça explique (pour le moment) mes requêtes suspectées à tord .... désolé d'avoir douté de vous cher resolveurs 0x20 :)


.

0 commentaires

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)