Comme aiment à le faire nos amis anglophones, je vais commencer directement par la conclusion. Cette attaque est une méthode permettant de d'injecter des trames arbitraires sur un réseau protégé par WEP. Point à la ligne. Son utilisation pour casser une clé WEP est possible, le temps total nécessaire à sa récupération étant alors annoncé à 15 minutes pour un clé de 40 bits et une heure ou deux pour 104 bits.

Maintenant, repartons du début et voyons pourquoi. L'attaque utilise la fragmentation à deux fins :

  • soit pour la transmission directe d'information comme expliqué en "2.3.3, Summary of Fragmentation-only Attack", principalement à destination d'Internet où les paquets transitent en clair ;
  • soit pour récupérer des keystreams RC4 comme décrit en "2.4.3, Summary of Keystream Attacks" qu'on pourra utiliser pour générer des requêtes sur le réseau.

Ces deux techniques pouvant être utilisées pour injecter du trafic arbitraire dans le réseau et déclencher la génération de trafic, les auteurs construisent un scénario dans lequel on les utilise pour obtenir la quantité de données nécessaire au cassage de la protection. C'est ce qui est décrit en "2.5, IV Dictionary and Weak IV Attacks", avec la constatation que que la constitution d'un dictionnaire associant chaque valeur d'IV au keystream RC4 correspondant est nettement plus longue et lourde que l'attaque de Fluhrer, Mantin et Shamir, dite "Weak IV Attack". On notera en particulier ce petit paragraphe :

"The weak IV attack may only be performed after a large number (~500,000-3,000,000) of data packets have been eavesdropped. A widespread optimization to the weak IV attack is replaying data in the hope of generating more traffic. We found that the ability to send arbitrary data can help achieve better results."

En français : cette attaque nécessite un grand nombre de paquets[1] mais que la possibilité offerte par leur attaque d'injecter des données arbitraires, au lieu de simplement rejouer des paquets bien particuliers comme le fait aireplay, rend leur approche plus générique.

Le scénario est décrit au paragraphe "2.6, Summary of all Attacks". Il se présente de la manière suivante :

  1. on récupère une trame de données par écoute du réseau ;
  2. on récupère les 8 premiers octets du keystream RC4 ayant servi au chiffrement de cette trame, ce qui nous autorise immédiatement l'envoi de 64 octets de données arbitraires en utilisant la fragmentation 802.11 (ou plus, si on fabrique des paquets IP eux-même fragmentés) ;
  3. on récupère 1500 octets de keystream RC4 en exploitant la défragmentation 802.11 opérée par l'AP par itération ;
  4. en faisant l'hypothèse que l'AP est aussi le routeur, son adresse MAC (BSSID du réseau) étant alors l'adresse MAC de la passerelle, on essaie d'envoyer des paquets à destination d'un serveur contrôlé sur Internet pour que ce dernier les réexpédie sur le réseau ;
  5. si ce n'est pas le cas, on essaie de découvrir le plan d'adressage du réseau ;
  6. si l'AP n'est pas la passerelle, on cherche à découvrir l'adresse IP du routeur, et donc son adresse MAC pour communiquer avec Internet si c'est possible ;
  7. à partir de là, on a des pistes pour déchiffrer des trames jugées intéressantes ;
  8. enfin, comme on est capable d'injecter du données, on peut générer du trafic pour casser la clé WEP.

C'est grosso modo ce scénario qui est utilisé par l'outil wesside décrit au paragraphe "3. Implementation" avec comme but ultime la récupération de la clé WEP. Les mesures d'efficacité de l'outil sont décrites au paragraphe suivant, "4. Evaluation". Ces mesures portent sur les deux étapes principales du scénario d'attaque :

  • d'abord la phase dite de "bootstrap" qui consiste à récupérer le keystream et les paramètres réseau nécessaires à l'injection efficace de trafic, c'est à dire parvenir à l'étape 6 ;
  • ensuite, l'inondation du réseau visant à forcer la génération de trafic et la récupération de la clé, à savoir l'étape 8.

Le "bootstrap" prend moins d'une minute selon "4.1, Bootstrap speed", sans aucune connaissance ni hyptohèse sur la valeur de la clé WEP. Ici réside probablement une partie de la confusion. Oui, cette nouvelle attaque prend quelques secondes, mais non, sa finalité n'est pas de casser la clé. C'est après que ça vient, sous forme d'application pratique, en utilisant aircrack. "4.3, Cracking time" explique la méthode utilisée pour casser la clé et les temps associés. Et c'est ici qu'on va trouver l'autre partie de la confusion. Wesside lance aircrack pour déterminer la clé WEP, mais pas une seule fois. Il le lance pendant une minute tous les 100000 nouveaux paquets et ce jusqu'à 3 millions de paquets capturés. Cette limite passée, aircrack sera lancé tous les millions de paquets pendant 10 minutes, principalement pour lui laisser le temps de charger la capture. Et donc oui, aircrack va probablement, à un moment donné, trouver la clé en moins d'une minute, mais non, cette durée ne tient pas compte du temps passé préalablement pour parvenir à cet état. Et ce temps est largement supérieur à la minute, comme on peut le lire plus loin :

"The attack time (top axis) is estimated by dividing the number of packets required by the 1200 p/s flood rate figure. The key cracking time is also included in this value - ten minutes when more than three million packets are needed, one minute otherwise. According to the simulator, 50% of the 40-bit keys are obtained in under 15 minutes, and half of the 104-bit keys are recovered in less than 80 minutes."

Ce qui est important dans ce paragraphe n'est pas le "cracking time" qui décrit le temps pendant lequel on laisse tourner aircrack. C'est le "attack time" qui décrit le temps total d'exécution de l'outil pour parvenir au résultat escompté. Et comme on le voit, on n'est pas du tout dans les quelques secondes annoncées encore çà et . En commentaire à ce dernier billet, on peut d'ailleurs lire à la question de la comparaison avec la fameuse vidéo de aircrack la réponse suivant de l'auteur du blog :

"yes it is different. the video is not in realtime, and he captures huge amount of traffic. the method described in the paper requires just one packet of data, and the time to break the key (even a strong one) is an order of magnitude smaller."

Ben non, dommage. L'attaque n'est pas très différente, demande également une grosse quantité de trafic et la durée est du même ordre en pratique. La seule chose qui change, c'est la méthode de stimulation du réseau visé.

En "6. Conlusions", on pourra encore enfin lire :

"If the ability to receive traffic via the network is also needed, active attacks bootstrapped using the fragmentation attack will recover 40-bit WEP keys in perhaps fifteen minutes and 104-bit WEP keys in an hour or two."

CQFD...

On pourra certes me rétorquer que "briser la protection WEP" ne veut pas forcément dire casser la clé. C'est vrai, mais c'est comme ça que les gens que le comprenne, comme le montre le commentaire de Alex Holy cité précédemment.

Notes

[1] Forcément difficile, pour ne pas dire impossible, à obtenir en quelques secondes