Le billet d'Halvar fait suite à un joli troll qu'il a lui-même lancé sur la liste DailyDave. Dan Kaminsky, soutenu par le cercle des initiés, avait en effet tenté de dissuader la communauté d'émettre des hypothèses quant au contenu de sa découverte. C'est évidemment une mauvaise idée. Surtout quand elle s'accompagnait d'un sympathique challenge : "trouvez et je vous fait monter sur scène à Black Hat". Contradictoire ? Hummm...

D'abord parce que vouloir freiner la curiosité des gens ne fait que l'encourager. Depuis le temps, il devrait le savoir. Et ensuite parce qu'une fois qu'on a ouvert la boîte, il est trop tard. Si ces messieurs ne voulaient pas que des gens s'intéressent de près à leur trouvaille, il fallait juste la fermer. Mais forcément, entre le buzzz généré, la couverture médiatique, la perspective d'une salle pleine à craquer à Black Hat et les différentes interventions données à droit et à gauche, c'était peut-être un peu trop en demander à certains...


Essayons maintenant de comprendre de quoi il retourne. Je ne vais pas vous copier là la description complète en anglais, elle est disponible ailleurs, chez Halvar, donc, et sur les miroir du billet de Ptacek. Je ne vais pas non plus comme le fait ce dernier vous réexpliquer comment marche DNS. Lisez-le chez lui, ou ailleurs, comme vous le sentez. Il y a cependant trois trucs importants à retenir. D'abord, le concept de transaction, et en particulier le fait que chaque transaction est distinguée par un identifiant unique et idéalement aléatoire, le TXID[1]. Ensuite, ce qu'est un Additional RR et à quoi ça sert. Enfin, le concept de cache sur les serveurs récursifs et la notion de TTL, pour comprendre le but de l'attaque : la corruption de cache DNS. Donc, pour tuer une partie du suspens, oui, il s'agit bien d'une technique permettant d'augmenter considérablement les chances de spoofer une réponse avec le bon TXID, et d'utiliser cette technique pour mener à bien une corruption de cache DNS via un champ RR additionnel. Maintenant, reste à comprendre comment ça marche exactement.

Le principe est en fait relativement simple. Je vais reprendre le fameux trio Alice, Bob et Eve. Alice met en ligne sa page web sur www.victime.com, à l'IP 1.2.3.4, et invite Bob à allez dessus. Le but pour Eve est de parvenir à corrompre le cache du serveur DNS de Bob pour lui faire croire que www.victime.com est ailleurs. L'attaque classique, bête et méchante, en brute-force de TXID, consiste à faire émettre une requête pour www.victime.com par le serveur DNS de Bob. C'est là qu'il est important qu'il soit ouvertement récursif, parce qu'ainsi, Eve peut déclencher cette requête elle-même. Sauf que maintenant, elle doit fournir en aveugle une fausse réponse à ce serveur, fausse réponse qui suppose de deviner le bon TXID. Et généralement, ça foire. D'abord parce qu'il faut que vous répondiez avant le vrai serveur, disons 1.2.3.4, celui d'Alice, et ensuite parce que même si 16 bits, c'est peu, vous n'avez qu'un essai. Et ça, c'est encore moins que peu.

Comment il fait Kaminsky pour faire mieux que Eve ? Il sort la mitrailleuse. Au lieu de demander un enregistrement qui existe déjà, il demande au serveur de Bob un nom aléatoire. Genre aaaaaaaa.victime.com. Un truc qui manifestement n'existe pas. Et il forge une réponse qui doit faire mieux que le NXDOMAIN qu'Alice va retourner. Sauf que l'attaque ne consiste plus ici à spoofer directement une entrée, mais à faire passer une réponse spoofée dans le domaine victime.com et d'y ajouter un RR additionnel fournissant une adresse dans le domaine victime.com. Typiquement www.victime.com, à l'adresse 9.8.7.6.

Qu'est-ce qui fait que cette attaque marcherait mieux que d'autres ? Et bien tout simplement le fait que vous pouvez lancer autant de requêtes aléatoires que vous voulez vers ce serveur récursif. Genre des milliers. Qu'en plus vous pouvez les envoyer groupées, par paquets. Et générer les réponses qui vont avec, mais avec un TXID fixe. Vu que vous n'avez que 65536 possibilités, il y en aura bien une ou deux de vos réponses qui vont tomber dans le mille. Pour les autres ? Vu que la réponse sera un NXDOMAIN, sans RR additionnel, et vu que cette réponse porte sur un donnée sans importance, ce n'est pas grave. Alors que pour les spoofs qui seront passés, il aura réussi à cacher des noms aléatoires, la belle affaire, mais aura surtout fait passer son RR expliquant au DNS de Bob que www.victime.com était ailleurs. Et bien sûr, il aura collé un TTL monstrueux sur cette entrée.

Effectivement, ça a l'air efficace. Avec un peu de bande passante, vous devriez pouvoir mener cette attaque en quelques secondes, au pire quelques minutes. Cette technique permet de passer le caractère aléatoire du TXID d'une part, mais aussi les mesures de vérification des RR additionnels, le fameux "in-bailiwick", qui fait que les informations additionnelles que vous donnez doivent appartient effectivement au domaine demandé[2]. En fait, ce brute-force de TXID est à rapprocher d'une technique classique de brute-force de compte, dans une situation où vous ne seriez pas intéressé par l'accès à un compte en particulier, mais juste n'importe lequel. Dès lors, au lieu de tester un compte avec pleins de mots de passe différents, vous allez prendre un mot de passe, de préférence faible, et tester tous les comptes avec. Vous brute-forcez donc l'identifiant du compte, et non plus le password. Ce qui a l'avantage de ne pas lever l'alerte classique du nombre important d'échec sur un identifiant. Là, c'est pareil. Ce qui vous intéresse, ce n'est pas de corrompre un enregistrement particulier, mais juste un parmi la foule d'autres que vous aurez essayés. Parce qu'ils portent tous l'information que vous voulez faire passer en RR additionnel. Et pour y arriver, vous pouvez fixer le TXID et attendre patiemment que le serveur vous ponde une requête qui y correspondra.

Force est de constater que ça pourrait plutôt bien marcher... À quelques interrogation près. Et vous aurez remarqué quelques changement à ce que j'ai écris avant, qui découlent directement de ces questions. En effet, en discutant avec Julien Tinnes, il n'est pas évident du tout que passer directement le NS de la zone qu'on veut spoofer soit possible aussi simplement... En fait, vous remarquerez que les descriptions de Halvar et de Ptacek diffèrent. Celle que j'ai mise plus haut est celle de Ptacek. Dans la mesure où il était au courant, il y a je pense plus de chance que ce soit la version exacte :)

La différence entre les deux, c'est que là où Ptacek se contente de spoofer le serveur gérant la zone cible pour corrompre un seul enregistrement, Halvar veut spoofer directement un serveur racine pour obtenir le contrôle de la zone cible. Il propose d'émettre des requêtes sur une multitude de domaines inexistants et renvoyer des réponses spoofant un serveur racine et plaçant le nom du serveur autoritaire pour la zone attaquée, ici ns.victime.com pour victime.com, comme NS de ces domaines, puis faire pointer ce nom vers une IP de son choix, genre 9.8.7.6 par exemple. Le tout en additional RR. Une technique plus large que celle de Ptacek en ce qu'elle donne le contrôle de la zone, et pas juste un enregistrement. Par contre, la technique de Halvar pose un problème : nous ne savez a priori quel serveur .com va aller interroger le serveur DNS dont vous voulez corrompre le cache. Ce qui réduit d'autant vos chances de succès. Pas de manière drastique, mais quand même.

Tout ceci ne me semble donc pas très clair. En tout cas, les tests ne sont pas concluants. Il doit me manquer quelque chose que je pense avoir finalement trouvé.


Supposons que ça marche... Côté protection, qu'est-ce qu'il nous reste ? Le TXID aléatoire ? Ça va vous aider un peu, mais comme on vient de le voir, ce n'est pas très utile. Le "in-bailiwick" ? Inutile. Le port source aléatoire ? Ça ne corrigera pas le problème, mais ça va aider un peu. En effet, si Kaminsky n'est pas capable de prédire le port source depuis lequel seront émises les requêtes du serveur de Bob, il devra aussi deviner cette valeur. Ce qui lui colle 16 bits de plus. Comme le TXID, il pourrait fixer le port source, et attendre patiemment une requête qui matcherait ces deux valeurs en même temps. Ce qui augmentera considérablement l'effort nécessaire à la réalisation de l'attaque.

Ce qui va surtout vous protéger, c'est l'application des bonnes pratiques. Comme d'habitude. Les serveurs autoritaires, ceux que les autres consultent chez vous, ne doivent pas être récursifs également parce que vous prêtez le flan à la corruption de cache DNS. Vos serveurs récursifs ne doivent l'être que pour vos clients, pas pour les autres. Pour la même raison. Des principes de base en fait. Maintenant, si vous êtes un ISP ou plus largement que vous fournissez un service de DNS récursif à pleins de gens, vous avez clairement un problème. Parce que vos clients, ça représente du monde, et que parmi ce monde, vous n'avez pas que des gens bien intentionnés...

La dernière chose qui pourra vous aider, mais pas forcément vous protéger, c'est le monitoring de votre trafic DNS. Une telle attaque ne va en effet pas vraiment passer inaperçue. Ce n'est certes pas une méthode protection efficace[3] en tant que telle, mais quelque chose qui vous aidera à détecter l'attaque et prendre les mesures qui s'imposent. Typiquement flusher vos caches. D'aucuns diront que ceci peut être automatisé. Ce à quoi je répondrai que DNS est un protocole sensible, et qu'automatiser des contre-mesures sur ce genre de choses, c'est un peu chercher les baffes.


Alors finalement, overhyped ou pas cette faille ? Oui, clairement. Sévère ou pas ? Assez oui, et relativement conforme aux premiers dires de Kaminsky. Sévère, mais pas la fin du monde pour autant. Est-ce que ça valait tout ce tapage ? J'en doute toujours.

Maintenant, je pense qu'il y a deux choses à retenir de cette histoire. D'abord, cette histoire de ports sources aléatoires montre bien que ce qui peut aider est souvent loin d'être inutile. C'est d'ailleurs rigolo de voir l'attitude de Vixie aujourd'hui, comparée à celle qu'il avait il y a quelques années sur cette question précise. Bref, les techniques évoluent, les gens réfléchissent, et ce qui ne paraît pas forcément utile aujourd'hui sera peut-être ce qui vous sauvera demain. Ensuite, que quand vous remontez un problème, il est extrêmement présomptueux de penser que personne d'autre ne comprendra ce qu'il y a derrière. Et donc qu'en cacher les détails est globalement assez vain, parce qu'il y aura forcément quelqu'un sur Terre de plus futé que vous pour découvrir ce que vous voulez cacher à tout prix. Donc si vous voulez publier, faites le complètement. Sinon, fermez la. Tout simplement.

À moins que tout ceci ne soit qu'une autre tentative de la Cabale pour nous éloigner de la vérité... Qui est ailleurs... C'est bien connu...



Personal notice to Halvar... Do you remember the discussion we had last year in Singapore ? About the ten reasons ? You're definitely one of them :)

Notes

[1] Ou QID, ou DNSID, ou... Bref un *ID...

[2] Un pas vers l'obsolescence des RR additionnels ? ;)

[3] Ben oui, si les IDS ça protégeait de quoi que ce soit, depuis le temps, ça aurait fini par se savoir...