Préliminaires

Comme le papier de Erik et Martin a été mis en ligne hier après-midi et que les première véritables analyses commencent à paraître ou à s'étoffer, je me suis permis d'avancer un peu la date de publication de ce billet. Je ne saurais trop vous conseiller de lire l'article original, dans la mesure où il vous apportera plus de détails que ce que je vais écrire maintenant, qui se veut plus un résumé qu'une explication complète.

De plus, avant de vous lancer dans la lecture complète de ce billet, je vous invite chaudement à lire, si vous ne l'avez pas déjà fait, le billet que j'ai mis en ligne avant-hier sur le fonctionnement de TKIP pour ne pas rester perplexe face aux acronymes et autres notations que je vais utiliser par la suite. Pour les références au fonctionnement de WEP proprement dit, je vous renvoie à un autre billet encore plus ancien.

Les grandes lignes

Cette attaque repose sur trois faiblesses différentes qui, combinées correctement, permettent d'aboutir au résultat annoncé :

  • l'adaptation de l'attaque Chopchop à TKIP ;
  • l'exploitation de la faiblesse de Michael ;
  • l'utilisation des files de priorité pour faire de la réutilisation de keystream.

Adaptation de Chopchop

Chopchop est une attaque relativement méconnue, comme à peu près toutes les attaques en récupération de keystream montées contre WEP d'ailleurs, tout occultées qu'elles sont par des choses jugées plus impressionnantes comme la FMS ou PTW. Cependant, son principe, que j'ai déjà décrit auparavant, est particulièrement brillant.

Soient deux payloads en clair C1 et C2. On peut toujours exprimer le passage de C1 à C2 par une fonction simple. L'idée, c'est qu'on puisse, par exemple, dire que :

C2 = f(C1)

Où f est une modification simple dont l'application permet de transformer C1 en C2. Il se trouve que XOR, opération utilisée dans le chiffrement WEP, et le CRC32, méthode de contrôle d'intégrité utilisée dans WEP, présentent des particularités communes qui font que si on appelle P1 et P2 les chiffrés respectifs de C1 et C2, on peut exprimer P2 en fonction de P1 et f seulement. Cette particularité est intéressante, parce qu'elle ne fait pas intervenir la clé WEP utilisée pour générer les chiffrés. Ce qui implique que si un attaquant est en possession d'un couple clair/chiffré comme C1/P1 et qu'il est capable de caractériser f, il peut alors calculer P2 sans connaître la clé WEP.

Et surtout, elle est exploitée pour déchiffrer de paquets de manière itérative. La première attaque de ce type a été publiée en 2001 par William A. Arbaugh, mais sans implémentation pratique efficace. En 2004, KoreK va publier un outil appelé chopchop qui implémente une attaque très similaire à celle de Arbaugh. L'idée commune à ces deux attaques est, à partir du paquet qu'on veut déchiffrer, de générer des modifications et d'essayer de les compenser en émettant des hypothèses sur la valeur des octets en clair modifiés par la technique évoquée précédemment. En gros, ce qu'on entend par compenser, c'est trouver la fonction f qui permettra d'obtenir un CRC32 valide pour les modifications qu'on va apporter au payload chiffré, fonction f qui va être différente selon la valeur des octets modifiés. Ces nouveaux paquets ne seront valides que si les hypothèses sont justes, ce qui, après vérification, permettra à l'attaquant de deviner les octets du payload en clair les uns après les autres. Cette attaque est implémentée dans aireplay-ng.

TKIP, comme nous l'avons vu, utilise lui aussi le moteur de chiffrement WEP. Donc cette attaque est à priori applicable, à un détail près : la valeur du TSC. En effet, si vous prenez une trame au hasard sur le réseau, la valeur du TSC correspondant ne pourra plus être rejouée par la suite, parce que déjà utilisée. Donc votre tentative de chopchop va échouer tout simplement parce qu'on va détecter que c'est une tentative de rejeu. Sauf à considérer 802.11e... Ce standard portant sur la qualité de service définit en effet différentes queues pour des trafics de priorité différente, qu'ils appellent des canaux de priorité[1]. Et quand on chiffre, chacun des ces canaux de priorité possède son propre TSC. Et c'est ce qui va nous permettre de lancer l'attaque, en la jouant sur un canal de priorité différent.

Le principe coule alors de source, si j'ose dire. On récupère une trame chiffrée sur le canal par défaut, et on lance chopchop dessus, mais sur le canal de priorité d'à côté. Sauf que le problème, c'est que si passer l'étape du CRC32 suffit à trouer WEP, dans le cas de TKIP, il reste à passer Michael, ce qui s'annonce difficile. Ce que nous savons, c'est que si on arrive à passer la vérification du CRC32 de WEP mais que la vérification du MIC de TKIP échoue, on va avoir droit au déclenchement d'une contre-mesure. En particulier, lorsque cela se produit du côté station, une trame de type MIC Failure va être générée.

Et c'est déjà plus qu'il nous en faut ! Supposons un payload chiffré en TKIP, envoyé à une station. Je fais un tour de chopchop sur un de ses octets. Je vais donc générer 256 trames différentes, parmi lesquelles 255 ne passeront pas le CRC32 de WEP. Celle qui reste va passer, mais échouer sur le MIC et provoquer l'émission du MIC Failure. C'est le signal que ma fonction f était la bonne, et donc que l'hypothèse faite sur la valeur de l'octet en question pour la construire était bonne. Ce qui me donne sa valeur. Il ne me reste plus qu'à recommencer pour l'octet suivant, mais en prenant bien soin d'attendre 60 secondes pour ne pas entraîner la désassociation de la station ciblée, et donc le renouvellement de toutes ses clés de session.

Au stade où nous en sommes, nous pouvons déchiffrer une trame arbitraire dans le sens AP vers station, au rythme relativement lent de un octet par minute. Les 900 secondes, donc 15 minutes, annoncées par le papier s'appliquent à un paquet ARP, avec quelques hypothèses sur la valeur des adresses IP contenues dans le payload qui ne laissent que 15 octets à découvrir. Et comme nous avons la trame en clair et sa version chiffrée, nous sommes également en position de récupérer le keystream correspondant au TSC utilisé pour chiffrer la trame sur laquelle on travaille.

Il est bon de noter que comme la génération des PPK fait intervenir la TEK, ce keystream est spécifique au canal de communication établi entre l'AP et la station visée. En outre, comme elle fait également intervenir l'adresse MAC de l'AP en tant qu'émetteur, il n'est également valable que pour le sens AP vers station. Il n'est donc pas possible de réutiliser ce keystream dans l'autre sens ou pour une autre station du même réseau, quand bien même on pourrait utiliser le même TSC.

Exploitation de Michael

Comme je vous le disais dans mon billet précédent, Michael brille surtout par sa faiblesse. On évalue en effet sa force entre 12 et 20 bits. Autant dire que si vous possédez un payload en clair et son MIC, ça ne va pas vous prendre la journée pour en sortir la clé. Et c'est justement la deuxième étape de l'attaque.

En effet, le déchiffrement complet d'une trame à l'aide du Chopchop modifié décrit plus haut vous donne le clair correspond au payload fourni à WEP lors du chiffrement. Or, en TKIP, ce payload est la concaténation des données utiles d'une part et du MIC d'autre part. Vous vous retrouvez donc avec vos données et leur MIC, en clair. Vous pouvez donc casser la MK utilisée dans le sens AP vers station, pour la station ciblée évidemment.

Au stade où nous en sommes, nous possédons un keystream, qui pourrait nous permettre de chiffrer des données si nous pouvions le réutiliser, et la MK, la clé de MIC, qui nous permettrait de générer des MIC valides pour le sens considéré, à savoir AP vers station.

Réutilisation de keystream

On voit bien qu'il ne nous manque pas grand chose pour être en position d'injecter des données arbitraires. Et ce pas grand chose, c'est encore 802.11e qui va nous le fournir. En effet, le TSC devrait vous empêcher de réutiliser le keystream obtenu par chopchop. La possession de la MK ne vous serait alors pas d'une grande utilité. Sauf à utiliser les canaux de priorité de 802.11e que j'évoquais plus haut...

Grâce au keystream et à la MK, on va pouvoir générer des trames valides, et on va utiliser les autres canaux de priorité, pour lequel la valeur de TSC à laquelle nous sommes liées n'est pas encore utilisée, pour les injecter. Ce qui nous ouvre la voie à l'injection de quelques trames au contenu arbitraire vers la station attaquée. Ça peut paraître peu, en particulier si le keystream récupéré est court, typiquement dans le cas du déchiffrement d'un paquet ARP, mais ça suffit largement à, par exemple, pousser la station à établir des flux vers un serveur contrôlé par l'attaquant quelque part sur Internet, et se servir de ça pour obtenir plus de situation de clair connu[2] qui elles-même nous donneront de nouveau keystreams. Et dans le bon sens en plus :)

Conclusions sur l'attaque

En définitive, cette attaque permet :

  • de déchiffrer des trames arbitraires émise par un AP à destination d'une station ;
  • d'injecter du trafic arbitraire à destination de la station considérée.

Les limitations sont les suivantes :

  • on ne peut déchiffrer que dans le sens AP vers station ;
  • le déchiffrement se fait au rythme de un octet par minute ;
  • l'exploitation doit se faire en live : si la station est désassociée, tout est perdu ;
  • l'injection de données est limitée à une poignée de paquets seulement.

D'aucuns considèreront les conséquences de cette attaques comme mineures. On voit bien que son champ d'application et ses conséquences sont limitées. Cependant, comme toutes les attaques malheureusement mésestimées sur WEP en rejeu de keystream, il ne faut pas la prendre à la légère. Pour des besoins simples, elle est amplement suffisante. Par exemple, si votre but est de faire passer une corruption de cache ARP, ça suffit largement.

En outre, et c'est ce que je trouve le plus important, c'est une attaque qui ouvre la porte à pleins d'autres travaux qui porteront très certainement d'autres coups à TKIP. Je réfléchissais par exemple à la possibilité d'adapter l'attaque par fragmentation publiée en 2007 par Bittau, Handley et Lackey à ce contexte, en étalant les fragments sur les différents canaux de priorité disponibles. À vérifier... Ensuite, on pourra se demander comment atteindre le trafic de groupe, ou adapter cette attaque pour des client n'implémentant pas 802.11e ou encore à toucher le sens station vers AP, qui ne génére malheureusement pas de MIC Failure...

Bref, indépendamment de l'impact de cette attaque, sa seule faisabilité devrait suffire à faire reconsidérer l'usage de TKIP. En particulier si on se rappelle que TKIP n'a été créé que comme un protocole transitoire, le temps que CCMP/AES dispose d'une base matérielle installée compatible suffisante, ce qui est le cas aujourd'hui. D'ailleurs, le futur standard 802.11w qui porte essentiellement sur la protection du management traffic, ne s'appliquera pas à TKIP, qui devrait donc rapidement se retrouver obsolète. Comme WEP répondront les esprits taquins ;)

Recommandations

Je n'aurais qu'une recommandation à destination des utilisateurs : désactivez TKIP.

Pour y parvenir, c'est au niveau de vos AP que ça se passe. De nombreux modèles, comme ma Freebox et le Linksys sur lequel je suis associé, permettent de choisir le type de chiffrement, soit en TKIP, soit en CCMP/AES, soit les deux. Ne laissez que CCMP/AES. En effet, si vous laissez les deux cohabiter, vous allez certes exposer les clients qui utiliseront TKIP comme protocole de chiffrement, mais également l'intégralité de votre trafic de groupe. Ce dernier sera en effet chiffré en TKIP, parce que plus petit dénominateur commun à toutes les stations.

Côté station, il est également possible de restreindre le chiffrement à CCMP/AES, mais le degré de facilité, voire de faisabilité, va dépendre de votre OS et de vos drivers. Ce n'est pas pour autant compliqué, mais faut creuser un peu, ce qui fait que ça prend plus de temps que reconfigurer votre AP. En outre, cela ne concernera que la station considérée, alors que la reconfiguration de l'AP s'appliquera immédiatement à toutes vos stations, en même temps.


Notes pour les lecteurs distraits :

  • cette attaque s'applique bien à WPA et WPA2, donc le seul fait de passer à cette dernière version, même si c'est conseillé, ne suffit pas à résoudre le problème ;
  • cette attaque n'a rien à voir avec les histoires de crackage de passphrase à la Elcomsoft, qui concernent la phase d'authentification, donc avoir des PSK de pleins de caractères aléatoires et bizaroïdes, ce qui est conseillé aussi, ne vous aidera pas non plus contre cette attaque.

Notes

[1] Qu'on ne confondra pas par la suite avec les canaux de transmission physique...

[2] Une situation dans laquelle vous avez un paquet chiffré et son contenu en clair.