Faille WPA2 : intuitions...

A

près avoir lu les deux articles qui parlent le mieux de l'affaire et creusé un tantinet la question, j'ai quand même quelques doutes sur cette annonce. Et comme le premier talk est pour demain, je m'en vais les partager avec vous.

Si effectivement l'idée de réutiliser la clé de groupe d'un réseau Wi-Fi est une idée dont les applications peuvent se montrer intéressantes, ces dernières ne semblent cependant pas d'un impact digne de révolutionner la sécurité Wi-Fi. En outre, cette histoire de récupération de PTK me semble pour le moins obscure...

Commençons par ces histoires de PTK. Je viens de parcourir à nouveau les parties concernées du standard 802.11 version 2007^[1], certes pas de manière assidue, mais globalement, je n'ai pas trouvé une seule mention d'un possible envoi de PTK sur le réseau comme suggéré dans l'article de Network World. J'ai pu louper un truc, évidemment, mais ça me paraît gros tout de même.

Ça surprend d'autant plus quand on considère que la PTK est une clé dérivée entre l'AP et la station, et qu'il existe un mécanisme pour le renouveler. Ce qui implique qu'il n'y a a priori pas de raison pour un AP de demander à une station de transmettre sa PTK : d'abord parce qu'il la connaît, ensuite parce que si pour une raison ou une autre il venait à la perdre, il peut en demander le renouvellement. On pourrait certes imaginer que l'attaque porte sur ce ce renouvellement, mais on n'a pas besoin d'aller chercher la GTK pour le déclencher, une simple dé-authentification fera très bien l'affaire, on le sait depuis longtemps. De plus, aucune donnée sensible de ce handskahe n'est chiffrée avec la GTK...

Enfin, si la récupération de la PTK permet effectivement de déchiffrer tout le trafic de la station, l'injection de données dans le réseau n'est pas une opération triviale comme l'ont montré Beck et Tews, et d'autres par la suite.

Côté utilisation de la GTK pour le trafic de données, le client va donc pouvoir envoyer du trafic multicast/broadcast sur le réseau, directement aux stations, en se faisant passer pour l'AP. Ce qui va lui permettre au passage d'utiliser une MAC source arbitraire, et donc de faire ça à la ninja. Ce type d'attaque est assez simple à coder, je l'ai fait par le passé avec Wifitap, on a maintenant airtun-ng qui fait la même chose, mais en mieux. Vous reprenez le même principe en ajoutant le chiffrement avec la GTK qui va bien, et vous êtes bon. Encore fallait-il le voir... et le faire...

Récupérer la GTK nécessite d'être un utilisateur légitime du réseau. La manière la plus simple et générique de l'obtenir est de s'associer : l'AP vous l'envoie en fin de 4-Way Handshake, chiffrée par la PTK. Dans le cas d'une authentification par PSK, la connaissance de cette dernière pour permet d'extraire la GTK simplement en observant le handshake. C'est là une vulnérabilité connue des réseaux utilisant ce type d'authentification.

Pour le points technique, voilà ce qu'on peut retenir pour l'instant. D'abord, l'attaque n'est valable que pour point d'accès donné et les clients qui y sont associés. Ensuite, la fenêtre d'attaque tient au renouvellement de la GTK. Un des critères de renouvellement est la désassocation d'une station. En effet, dès qu'un station quitte le réseau, on renouvelle la GTK. Ce qui implique qu'un client associé voulant mettre en œuvre cette attaque doit rester associé durant l'attaque. Enfin, côté conséquences, toute attaque basée sur du trafic multicast ou broadcast pourra être mise à profit par cette technique. Je citais la corruption de cache ARP, c'est un candidat parfait pour l'exploitation.

Pour conclure, je ne vois pour l'instant rien là-dedans qui ne puisse déjà être fait par une station légitime associée. La différence, qui peut être de taille cependant dans certains environnements, c'est que la station attaquante tient là une excellent technique de dissimulation.

Notes

[1] À noter que le page 196 qui donne son nom à l'attaque ne vous apprendra de ce côté là...