Et oui, c'est encore de ces faux poissons d'avril, une vraie nouvelle publiée un 1er avril. Si on n'en attendait pas moins de la part de cryptographes, il ne faudrait pas que ça devienne une mode non plus...


Préliminaires : Shameless Plug...

Le concept essentiel à comprendre pour saisir ce qui suit est la notion de keystream. Si vous ne savez pas ce qu'est un keystream, vous pouvez vous référer au premier billet d'une série de trois que j'ai déjà écrits sur le WEP. Ce billet pose les bases du chiffrement WEP et pointe diverses failles dans sa conception. Il aborde donc la notion de keystream et ses implications.

Le second billet traite de l'exploitation de ces failles et le troisième des mécanismes de sécurité qui marchent. J'ai également consacré un billet à la récente attaque par fragmentation qui a fait quelque bruit l'été dernier, ainsi qu'un article dans le dernier MISC. Elle est intéressante en ce que c'est également une remarquable exploitation de la récupération des keystreams. Enfin, vous pouvez consulter les quelques présentations que j'ai faites çà et là sur le sujet.

Ceci étant dit, on peut passer à cette nouvelle attaque.


Commençons par la pratique : test de l'outil

Rien ne valant une bonne vieille expérimentation, je me suis armé d'un Linksys WRT54GC et de mon Zaurus SL-C3000 sous OpenZaurus pour monter un réseau WEP, avec une troisième machine sur le réseau filaire derrière le routeur. Le principe est simple : je génère depuis le Zaurus une requête ARP à destination de la machine sur le réseau filaire, laquelle sera capturé par mon laptop figurant l'attaquant. Il ne reste plus qu'à attendre d'avoir suffisament de trames en stock et lancer l'outil régulièrement jusqu'à ce que la clé tombe.

Montage

L'attaque se déroule comme une attaque classique avec aircrack-ng :

  • association d'une d'une adresse MAC arbitraire avec aireplay-ng
~# aireplay-ng --fakeauth 0 -a 00:16:B0:3D:E4:32 \
        -h 00:01:02:03:04:05 -e test ath1
10:01:48  Sending Authentication Request
10:01:48  Authentication successful
10:01:48  Sending Association Request
10:01:48  Association successful :-)
  • lancement d'une capture de requête ARP pour rejeu
~# aireplay-ng --arpreplay -b 00:16:B0:3D:E4:32 \
        -h 00:01:02:03:04:05 ath1
Saving ARP requests in replay_arp-0404-100153.cap
You should also start airodump-ng to capture replies.
[...]
  • désauthentification du client associé pour le forcer à flusher leur cache ARP
~# aireplay-ng --deauth -0 -a 00:16:B0:3D:E4:32 \
        -c 00:0E:67:4B:23:DC ath1
10:02:39  Sending DeAuth to station
        -- STMAC: [00:0E:67:4B:23:DC]
10:02:40  Sending DeAuth to station
        -- STMAC: [00:0E:67:4B:23:DC]
10:02:40  Sending DeAuth to station
        -- STMAC: [00:0E:67:4B:23:DC]

À ce stade, si le client essaye de joindre quelqu'un, il devra faire une requête ARP qui sera capturée, puis rejouée par aireplay-ng, permettant de stimuler la génération de trafic. En parallèle, on aura lancé un sniffer, typiquement airodump-ng sur le channel adéquat pour constituer une capture sur laquelle on travaillera pour casser la clé.

~# airodump-ng -w test --channel 1 ath1
 CH  1 ][ Elapsed: 7 mins ][ 2007-04-04 10:08

 BSSID              PWR  Beacons   # Data  CH  MB  ENC  ESSID

 00:16:B0:3D:E4:32   50     4284    40968   1  54  WEP  test

 BSSID              STATION            PWR  Packets  Probes

 00:16:B0:3D:E4:32  00:0E:67:4B:23:DC   62    19732  test
 00:16:B0:3D:E4:32  00:01:02:03:04:05   51    22361  test

Et finalement, on lance régulièrement l'outil sur la capture jusqu'à ce que ça claque :

~$ aircrack-ptw test-01.cap
This is aircrack-ptw 1.0.0
For more informations see
    http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
allocating a new table
bssid = 00:16:B0:3D:E4:32  keyindex=0
stats for bssid 00:16:B0:3D:E4:32  keyindex=0 packets=40297
Found key with len 13: 7A 52 C3 A0 EB DA 0E D3 00 02 24 4D 40

CQFD, ça marche. Maintenant, intéressons-nous de plus près à la théorie.


Le dessous des cartes : l'article

L'article a été publié dimanche 1er avril, puis mis à jour hier, sur l'ePrint Archive. Il est signé Erik Tews, Ralf-Philipp Weinmann et Andrei Pyshkin, tous les trois du département informatique de l'université de Darmstadt, laboratoire de Cryptographie et d'Algèbre Informatique. Leurs résultats découlent d'une publication par d'Andreas Klein intitulée "Attacks on the RC4 stream cipher" qui améliore sensiblement l'attaque de Fluhrer, Mantin et Shamir par la mise en exergue d'une nouvelle corrélation dans le générateur pseudo-aléatoire de RC4. Cette méthode permet de découvrir itérativement la valeur des octets de la clé, donc les uns après les autres. Dans leur papier, les trois auteurs étendent son travail de manière à pouvoir découvrir les octets de clé indépendamment les uns des autres, ce qui rend l'attaque plus efficace.

Le côté intéressant de l'attaque est la nécessité d'extraire et de conserver un maximum de keystreams RC4 pour travailler. De fait, l'outil développé ne marche pour le moment que sur des réponses ARP dont la valeur des seize premiers octets est connue. Les huit premiers octets de la trame représentent l'entête LLC/SNAP d'un paquet ARP :

AA AA 03 00 00 00 08 06

Les huit suivants sont le début de l'entête d'une réponse ARP :

00 01 08 00 06 04 00 02

Il est donc trivial d'extraire les seize premiers octets du keystream correspondant à un tel paquet. L'outil prend donc la capture et essaye de calculer chaque octet de la clé à l'aide de tous les keystream récoltés durant la phase de capture.

Leurs expérimentations montrent qu'on dépasse les 50% de probabilité de réussite après avoir récolté 40000 keystreams différents. On dépasse les 90% à 65000, les 95% à 85000. Il leur a fallu environ 50 secondes pour récupérer leurs 40000 keystreams en utilisant deux cartes, une pour l'injection et l'autre pour l'écoute. Si on compte les phases préliminaires et le calcul en lui même qui prend une à cinq secondes, il apparait que dans ces conditions, une seule minute d'attaque donne plus d'une chance sur deux de casser la clé. Et c'est ce que je constate dans mon expérience, sauf que n'utilisant qu'une seule carte Wi-Fi, je mets plus longtemps à récolter la quatité adéquat de trafic[1].

Si on extrapole leurs résultats, et en particulier le rythme auquel ils génèrent les keystreams, il leur faudra un peu plus de deux minutes pour dépasser les 90% de réussite. En fait, la forme légèrement hyperbolique de la courbe associant la probabilité de réussite au nombre de keystreams récolté montre qu'on atteint très rapidement des probabilités raisonnable : 50% à 39000, 65% à 450000, 75% à 50000. Ensuite, ça se tasse. Bref, en moins de deux minutes, on a déjà une forte probabilité de réussite, et on voit qu'y passer plus de temps n'apporte en définitive pas grand chose. Il est clair que si ça ne tombe pas sur une capture de deux minutes, il sera probablement plus efficace de recommencer une capture pendant deux autres minutes que de continuer la capture courante.

Et si vous en voulez encore, vous pouvez lire l'interview de Ralf-Philipp Weinmann sur The Register.


Conclusion : comme dirait un collègue mais néanmoins ami, ça poutre grave...

Avec une clé de 104 bits cassée en capturant à peine plus de 40000 trames, ces résultats explosent littéralement l'état de l'art. Ces chiffres sont à mettre en parallèle avec les résulats obtenus à l'aide de aircrack-ng, pour lequel dix minutes supposent des conditions vraiment idéales, avec des résultats in the wild de l'ordre de trente minutes, voire une heure. Ici, sept minutes sur un montage pas idéal du tout, limite à l'arrache produisent le même résultat. À titre de comparaison, aircrack-ng tournant en parallèle sur la même expérience rendra la clé en 59 minutes...

Comme quoi, on a beau planter des clous, le cadavre a encore du mal à refroidir...


Et pendant ce temps...

Le TGV n'est pas en reste dans la série des records de vitesse puisqu'il a atteint hier après-midi les 575 km/h battant ainsi son propre record.

Et concernant le WiFi, j'espère bien pouvoir dégager un peu de temps pour bricoler ces petites bestioles qui font du 802.11s ;)

OLPC

Notes

[1] Environ sept minutes.