ARP cache poisoning by dummies...

D

e retour du SSTIC, Kevin Denis constatait avec un certain dépit que la sécurité TCP/IP semblait ne plus intéresser personne. C'est en effet un domaine où beaucoup croient que tout a été dit, qu'il ne reste plus rien à trouver, bref que l'étudier est une perte de temps. Je suis loin de partager cet avis.

Et je le partage d'autant moins que ce désintérêt s'exprime souvent chez des gens dont l'approche on ne plus surfacique du sujet en font soupirer plus d'un. Pour illustrer ce que j'entends par là, je vais vous parler d'un truc on ne peut plus Old School et parfaitement maîtrisé : la corruption de cache ARP. Et vous montrer combien certains devraient revoir leur classiques avant de se faire mousser à BlackHat...

La corruption de cache ARP, c'est une attaque qui pourrait figurer dans un musée. La RFC décrivant ARP date de 1982, et on trouve ce qui est probablement la première référence à l'attaque dans le numéro 34 de Phrack qui nous ramène en 1991. Depuis le problème a été largement documenté et outillé.

Aussi quand, après une discussion sur fr.comp.securite, Pappy, Valgasu et moi avons décidé d'approfondir la question pour notre article sur le sujet dans le numéro 3 de MISC. C'était en 2002, c'était déjà vieux et il ne s'agissait déjà pour nous que de proposer un panorama des techniques de corruption de cache ARP. Des petites choses comme la corruption de cache avec des requêtes, possiblement dirigées, la mise à jour d'entrées statiques sous Windows et Solaris 8, l'usurpation d'IP étaient peu documentées à l'époque, et un outil complet de génération de trafic ARP restait à écrire.

Rien de révolutionnaire n'est sorti de ce travail, mais le fait de se plonger là-dedans nous a donné l'opportunité, je pense, de faire le tour du sujet et de partager l'expérience. Ça nous a aussi permis de nous en servir efficacement quand le besoin a pu se faire sentir...

Mais revenons à nos moutons. Le problème avec les techniques antédiluviennes de ce genre, c'est qu'au bout d'un moment, certains semblent considérer qu'elles font partie du paysage et que comprendre comment ça marche ne sert à rien. Que c'est chiant. Dans la mesure où il y a des outils pour les exécuter, autant regarder vaguement ce qu'ils font et s'en contenter. J'ai l'impression que c'est exactement le panneau dans lequel sont tombés les gens d'AirTight avec leur histoire de Hole196. Prenez les slides qu'ils ont présentés à Defcon et rendez-vous d'abord à la planche 8. On nous y explique qu'une tentative de corruption de cache ARP par requête en broadcast va se trouver répétée sur le réseau filaire où elle pourra être détectée par un éventuel IDS. L'idée est reprise sur la planche 18 qui compare la corruption dite "Old Style", manifestement détectable, avec leur méthode, forcément furtive et donc plus intéressante.

Sauf que ce n'est pas la réalité du terrain. En 2002, quand nous avons travaillé sur l'ARP cache poisoning, l'outil "Old Style" de l'époque était le célèbre arpspoof du package dsniff. La technique qu'il implémente consiste à envoyer des réponses ARP non sollicitées en unicast vers la machine à corrompre. Technique qui ne correspond donc en rien au scénario proposé dans la présentation et qui, surtout, n'entraîne pas de diffusion sur le réseau filaire quand il est dirigé vers une station Wi-Fi . L'attaque n'a donc aucune raison d'y être détectée par un IDS classique.

On peut aussi corrompre un cache ARP avec des requêtes. Et bien que ce type de paquets soit destiné à être envoyé en broadcast, on préférera de loin émettre des requêtes ARP en unicast. D'aucuns peuvent trouver ça étrange, mais c'est complètement supporté dans la mesure où la couche ARP se contrefiche de savoir comment le paquet est arrivé jusqu'à elle... Là encore, on a un exemple de corruption de cache ARP Old Style qui va passer à travers l'IDS filaire...

En fait, faire de la corruption de cache ARP est broadcast est une approche inutilement bruyante du problème. Approche qu'on ne devrait utiliser que s'il fallait toucher l'ensemble du subnet d'un coup... Exécuter l'attaque en unicast est bien plus efficace, ne serait-ce que du point de vue de la furtivité. Dans le contexte décrit par AirTight, le trafic unicast ainsi produit sera protégé par la PTK et ne génèrera pas la superbe alerte montrée sur la slide 23 du Webinar Hole196.

De manière générale, on peut conclure que le discours soutenant l'intérêt de Hole196 pour faire de la corruption de cache ARP n'est appuyé que par un use case un peu foireux. D'autres méthodes permettent d'arriver au même résultat sans déclencher les alertes annoncées et sans avoir à s'embarrasser de ces histoires de GTK. Les auteurs ignoraient-ils donc l'existence de ces dernières^[1] ? Je ne sais pas, mais ce ne serait pas la première fois que ce genre d'erreur serait faite.

Pas mal de gens ont en effet essayé de produire des techniques de détection, voire même de prévention, de corruption de cache ARP. Et pas mal d'entre elles échouent parce qu'elles ne ciblent que certains scénarios d'exploitation. Or l'expérience montre que ce genre d'approche est vouée à l'échec. Dans notre cas, l'erreur la plus courante consiste à ne surveiller que les réponses ARP, puisque c'est ce que met en œuvre l'outil d'attaque le plus connu. Or c'est l'intégralité du trafic ARP qu'il faut inspecter, comme le fait arpwatch quand on lui envoie l'intégralité du trafic. Ou alors, il faut durcir l'implémentation de la couche ARP, ce que fait ArpOn sous Unix.

Si vous voulez lire quelque chose d'intéressant sur la sécurité Wi-Fi publié à BlackHat et Defcon, je vous conseille de vous tourner vers les travaux de Leandro Meiners et Diego Sor sur le "WPA Migration Mode" de Cisco. Ce mode, qui permet d'accepter des clients ne supportant que WEP ou LEAP sur des réseaux WPA/WPA2 acceptant TKIP, se fait donc démonter dans les grandes largeurs. Le code implémentant l'attaque est disponible et en passe d'être inclus dans Aircrack-ng et probablement dans Kismet.

On sent bien le fail qui s'apparente à équiper un coffre-fort d'une porte en contre-plaqué. Ou une serrure biométrique dernier cri d'un barillet de secours trivial à crocheter^[2]. Bref, quelque chose qui ne viendrait pas à l'esprit d'une personne sensée...

Notes

[1] J'en doute un peu, mais bon, soyons bon public...

[2] ""the problem with this lock design is so elementary, frankly it defies belief", Marc Weber Tobias...