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és 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 sur la machine destinatrice, 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], le gain de temps annoncé d'une minute semble un peu anecdotique puisqu'il ne porte que sur la récupération de paquets ARP une fois le MIC connu, 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 communication 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.

Update (27 août 2009) : Mike Kershaw (Kismet) propose une excellente technique pour réaliser ce MITM. Il s'agit de monter une sorte de répéteur avec deux radios, la première sur la fréquence du réseau attaqué, la seconde sur un autre canal[5]. En modifiant le numéro de canal à la volée dans les beacons et les probes[6], tout en balançant des déauth./désassoc. vers le canal légitime, il devrait être possible d'amener le client à délaisser leur AP pour notre installation. Il s'agira donc juste de forwarder les trames entre les deux modules radio et modifier le champ canal lorsque nécessaire. Ce qui demande un peu de développement, mais a priori rien de bien méchant, et une carte Wi-Fi supplémentaire.

Update 2 (27 août 2009) : ça y est, la nouvelle a fini par toucher la presse en ligne[7], et c'est reparti comme en 40 avec les conneries. The Inquirer titre par exemple "WPA data is gone in 60 seconds ". Lotfree reprend avec un joli "WPA is dead" le "New attack cracks common Wi-Fi encryption in a minute" de Computer World sans se poser la moindre question. Et les sites français ne sont évidemment pas en reste. Le pire, c'est que la plupart des articles pointent vers le papier complet, qu'aucun n'a manifestement pris le temps de lire. Ni les discussions qui l'entouraient d'ailleurs... C'est bien triste...


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[8]. 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] Voire même une autre bande, en 802.11a.

[6] Les trames de management ne sont pas protégées !

[7] Oui, oui, je sais déjà ce que tu vas me dire, cher Marc... Je corrige donc : pas toute la presse en ligne... Puisque si CNIS Mag' n'a toujours pas fini ses vacances, de rares articles se montrent nettement plus mesurés :)

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