Man in the Middle sur WPA ?

J

'apprenais hier via Brico-wifi que WPA aurait pris une nouvelle claque. Dragos en remet une couche sur Full-Disclosure en annonçant un Man in the Middle en moins d'une minute. Il se trouve en effet qu'un papier présenté par deux chercheurs japonais en début de mois au Joint Workshop on Information Security à Taiwan vient d'être mis en ligne. Il s'intitule "A Practical Message Falsification Attack on WPA".

Évidemment, et comme on pouvait s'y attendre, le titre de l'article fait le raccourci entre WPA et TKIP. Détail malheureux à garder à l'esprit, mais qui n'empêche pas l'article d'être intéressant. Il décrit une amélioration de l'attaque que Beck et Tews ont publiée l'an dernier pour Pacsec, avec méthode annoncée comme générique et plus rapide. Par contre, désolé de tuer le suspens dès le début, mais ce n'est carrément pas un MITM sur TKIP....

Pour le principe détaillé de TKIP et le fonctionnement complet l'attaque de Beck et Tews, je vous renvoie aux deux billets que j'ai écrits sur la question l'an dernier. Je vais juste rappeler les grands principes de l'attaque de Beck et Tews, qui se fait en trois étapes :

• réalisation d'un chopchop sur un paquet capturé en utilisant les extensions 802.11e ;
• attaque du MIC TKIP ainsi déchiffré pour récupérer la clé de MIC associée au sens AP vers station ;
• génération de paquets chiffrés valides et injection vers la station ciblée en utilisant les extensions 802.11e.

L'utilisation des extensions 802.11e sert à contourner le compteur anti-rejeu, dit TSC. Ce compteur, incrémenté à chaque trame et vérifié par le destinataire avant déchiffrement, permet en effet de détecter le rejeu d'une trame puisque ce dernier fera apparaître une valeur du TSC déjà utilisée, ce qui entraînera la destruction pure et simple de la trame sans autre forme de jugement. Les extensions 802.11e proposent huit queues distinctes, appelées canaux de priorité, pour la gestion de la QoS. Disposant chacun de sa propre valeur de TSC, les canaux les moins utilisées permettent en effet de réinjecter des paquets capturés sur le canal par défaut qui transporte plus de trafic, les valeurs de TSC associés aux trames rejouées étant en effet beaucoup plus grandes que la valeur courante de TSC pour le canal visé. L'exploitation dépend donc alors du support de 802.11e par la machine ciblée.

La méthode proposée par Toshihiro Ohigashi et Masakatu Morii permet de se libérer de l'utilisation de 802.11e, ce qui est un pas en avant puisque certaines piles Wi-Fi du marché ne le supportent pas, et que le support est désactivable sur d'autres. C'est ce que les deux chercheurs entendent par la généralisation de la méthode, à savoir son application à toutes les implémentations. Et globalement, ça s'arrête là. Point de MITM sur le chiffrement en vue. En fait, s'il y a bien MITM entre l'AP et la station ciblée, ce n'est nullement une conséquence, mais un pré-requis pour l'attaque. Cependant, l'article n'explique pas comment le réaliser, mais je vais revenir sur ce point de détail.

Une fois placé entre l'AP et la station, l'attaquant peut intercepter tous les paquets au niveau du support physique. Il se comporte alors grosso modo comme un bridge entre les deux parties jusqu'au moment où il va recevoir un paquet, envoyé par l'AP vers la station, qu'il aimerait bien déchiffrer. Il va alors bloquer ce paquet ainsi que toutes les trames suivantes venant de l'AP pendant qu'il réalise l'attaque chopchop sur le client. C'est ce qui lui permet de bloquer complètement l'évolution du TSC, donc de contourner la protection anti-rejeu. CQFD. Le papier propose également quelques optimisation permettant d'accélérer le déroulement de l'attaque pour réduire la durée du black-out entre l'AP et le client légitimes. Outre que la fin de l'attaque pose un petit problème non évoquée de resynchronisation du TSC entre l'AP et le client légitimes^[1], ce gain de temps semble un peu anecdotique puisque pour autant que j'ai pu comprendre, il ne porte que sur l'injection des trames et non sur le chopchop initial qui reste à mon sens le facteur limitant.

Pas de quoi sauter au plafond donc, mais un pas en avant tout de même.

Ceci étant, la méthode proposée dans ce papier pose tout de même un problème de taille dont la résolution n'est pas décrite : la réalisation pratique du MITM entre l'AP et la station. Il se trouve en effet que l'authentification WPA/WPA2 est mutuelle aussi bien en 802.1x qu'en PSK. Ce qui veut dire en pratique que si vous n'avez pas connaissance de la PMK, vous ne pourrez pas vous insérer entre l'AP et la station. Et si vous avez connaissance de la PMK, vous n'avez pas besoin de perdre du temps avec ce genre d'attaque... C'est heureux puisque la phase d'authentification a été justement conçue pour empêcher l'insertion d'un attaquant. Ce qui veut dire que vous ne pouvez pas interférer avec la négociation des clés, point qui a son importance pour la suite.

Cependant, ça ne semble pas empêcher pour autant une insertion sans toucher au chiffrement, ce qui est tout à fait possible avec WEP^[2] par exemple. Mais ce n'est pas aussi simple. Quand on veut faire un MITM simple sans soucier du chiffrement, on implémente généralement une attaque de type Rogue AP : on se fait passer pour l'AP légitime auprès du client qui nous envoie des paquets qu'on va renvoyer à l'AP en se faisant passer pour le client. Attaque qu'on qualifiera de "Piece of cacke". Dans ce cas, le client s'associe à votre adresse MAC, adresse que vous associez également auprès de l'AP. Le problème avec l'authentification WPA/WPA2, c'est que la dérivation de la PTK fait intervenir les adresses MAC de l'AP et de la station. De fait, si vous essayez de vous coller au milieu de cette manière, vous allez vous faire détecter parce que vous perturberez la négociation des clés. Vous devez donc spoofer les vraies adresses de l'AP auprès du client et inversement. Vous devez donc spoofer les adresses MAC légitimes.

Mettre en place un tel MITM n'est pas impossible, mais ce n'est pas vraiment ce qu'on peut qualifier de simple non plus. Parce que quand bien même vous spooferiez les vraies adresses MAC, le médium étant multicast par nature, ça n'empêchera pas le destinataire légitime d'une trame de la recevoir et de la traiter s'il est à portée, ce qui est généralement le cas. De fait, en essayant de vous insérer ainsi, vous n'interrompez pas le canal de comminucation directe entre vos cibles. Sauf à réaliser un MITM physique, c'est à dire interrompre physiquement la transmission hertzienne entre l'AP et la station qui lui seul permettra de bloquer l'évolution du TSC. Et ça suppose un peu de travail. Car à moins que l'attaquant se place physiquement au milieu, ce qui revient à être physiquement présent sur place^[3], il va falloir ruser et déballer un peu de matos. Parce que bon, le scénario présenté dans lequel la station et l'AP sont hors de portée l'un de l'autre n'est globalement pas super courant dans la vraie vie...

On peut effectivement se prendre à imaginer un brouillage un peu subtil, utilisant savamment quelques antennes directionnelles, qui parviendrait à faire passer les communications légitimes de nos participants en-dessous du seuil du bruit, mais pas celles de l'attaquant, boostées pour l'occasion. Ou un DoS, genre flood par réservation de bande passante, limité à une portion d'espace contenant l'AP mais pas le client, en utilisant une antenne directionnelle encore une fois. Car à bien y réfléchir, l'essentiel est bien d'interrompre la communication entre l'AP et la station le temps du déroulement de l'attaque. Et on n'a pas vraiment besoin de réaliser un MITM pour cela, juste de perturber localement les transmissions. Bref, c'est possible, mais pas immédiat, surtout avec du matériel standard...

On pourrait également penser à l'exploitation d'une possible faiblesse dans les mécanismes de roaming, éventuellement propriétaires^[4], mais il faudrait que ces derniers autorisent un client à changer d'AP sans renouveler aucune clé de session, alors qu'en général, si on conserve bien la PMK, il faut tout de même renouveler la PTK lors du handover. Il faudrait tout de même que je me vérifie, histoire de voir si c'est possible. Toujours est-il que même si ça marchait, l'attaque supposerait alors le support d'une fonctionnalité bien particulière, ce qui voudrait dire réduire de façon assez pénalisante le nombre d'installations potentiellement vulnérables. Et probablement bien plus que l'utilisation de 802.11e puisque les mécanismes de "PMK caching" sont assez spécifiques en terme de déploiement.

Bref, il est un peu dommage que cette histoire de MITM semble considérée comme acquise dans l'article parce que c'est un problème qui n'est pas complètement trivial à résoudre. Ceci dit, le papier précise que la prochaine étape va justement consister à implémenter l'attaque. J'imagine qu'on en apprendra alors plus sur la manière dont ils réalisent cette étape, par exemple la prochaine fois qu'ils le présenteront.

Dernière petite remarque. Dans leurs bibliographie figure un article qu'ils ont co-écrits intitulé "Breaking WEP with Any 104-bit Keys - All WEP keys Can Be Recovered Using IP Packets Only" qu'ils ont publié dans les proceedings payants d'un symposium de cryptographie. Évidemment, impossible de mettre la main sur le papier en ligne^[5]. Si quelqu'un parvenait à mettre le grapin dessus et se montrait assez généreux pour le partager avec moi...

Notes

[1] Problème pas forcément très compliqué à gérer.

[2] Mais bon... WEP voilà quoi...

[3] Situation possible, mais pas forcément courante.

[4] En parlant de choses propriétaires, OTAP de Cisco semble un poil exploitable...

[5] Même si je n'ai pas cherché longtemps.