• # Ça fait longtemps qu'on sait que WEP est inutile...

    Posté par . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 10.

    Concernant cette attaque, il s'agit d'une méthode simple pour récupérer 1504 octets de keystream RC4 de manière à pouvoir commencer à injecter des paquets sur le réseau. Andreas Bittau a déjà présenté ça à la dernière Toorcon, et j'en parle dans mes dernières confs, comme celle-ci (cf. slide 19) :

    http://sid.rstack.org/pres/0602_Securecon_WirelessInjection.(...)

    L'idée, c'est que le payload chiffré d'une trame 802.11 commence par un entête LLC/SNAP sont les 6 premiers octets sont fixes et les deux suivants sont un ethertype simple à deviner. En effet, les communications sont essentiellement de l'IP (0x800) avec quelques paquets ARP (0x806) simples à détecter. Ce qui veut dire que sur un paquet IP lambda, on a un clair connu sur les 8 premiers octets (ou plus sur un paquet ARP vu la forme de son entête) qui permet donc de resortir 8 octets de keystream RC4, qu'on va pouvoir réutiliser pour chiffrer 4 octets de données et leur CRC.

    À partir de là, il va exploiter le fonctionnement de la fragmentation disponible dans 802.11. Lorsqu'un AP reçoit des fragments chiffrés, il les déchiffre, les vérifie et reassemble la trame originale avant de la chiffrer entière pour la renvoyer sur le réseau (si elle doit y revenir). De fait, si on prend un payload de 64 octets d'une trame destinée au réseau WiFi, on peut le découper en 16 fragments de 4 octets et chiffrer chaque fragment avec notre petit morceau de keystream découvert précédemment. L'AP va donc recevoir les fragments, reconstituer la trame et la rejouer entière. On obtient alors un nouveau clair connu, mais cette fois sur 68 octets (64 data + CRC), puisqu'on connait le contenu clair de cette trame.

    On peut alors rejouer l'attaque avec des fragments plus gros pour obtenir 64*16+4 = 1028 octets au tour suivant et finallement atteindre la MTU au 3e tour, ce qui est faisable dans les deux premières secondes. Ensuite, l'outil va essayer soit de sortir sur Internet, soit de déchiffrer une adresse IP présente sur le réseau (environ 30 secondes) de manière à faire générer du trafic, soit en communicant avec un hôte contrôlé à l'extérieur, soit en floodant l'adresse locale découverte de requêtes ARP pour générer du trafic qui sera filé à aircrack pour récupérer la clé WEP.

    En définitive, l'essentiel de papier porte sur une attaque permettant d'injecter de générer du trafic pour alimenter Aircrack. À la différence de aireplay, elle ne nécessite pas de trafic (ARP en particulier) ou de situation particulière. C'est une exploitation brillante d'une fonctionnalité assez peu connue de 802.11.

    Maintenant, quand on lit les articles, on a l'impression que c'est une révolution., ce qui n'est pas le cas comme le mentionnent les auteurs dans leur conclusion :


    Walker's and Simon's attack on keystream re-use were never considered as a threat. A year later, Arbaugh, and Borisov et al. resurrected thoses attacks bu noting the vulnerability in Shared Key authentication. [...] Today, we resurrect the 2000 keystream re-use attacks once more.


    Mais bon, le WEP, comme tu le dis, a un remplaçant qui tient la route depuis 3 ans et est connu pour être définitivement trop faible depuis 2001 avec les travaux d'Arbaugh, Borisov et al., et Fluhrer et al., et plus tard de Ikari, Korek, etc. (2004). Ce n'est qu'une technique, très ingénieuse et efficace, et un outil de plus parmi pleins d'autres pour lui faire la peau. Mais bon, si c'est celle qui fait bouger les gens, alors tant mieux. Parce que même la pléthore de démos et vidéos de crack de WEP en moins de 15 minutes ne semblaient pas émouvoir grand monde...