Passons rapidement sur cette fameuse faille TCP. Le talk à la conférence T2 n'a rien apporté de nouveau, sinon démentir les hypothèses fumeuses dont on savait déjà qu'elles n'étaient pas le fond du problème, genre les Syncookies côté client, ou proposer de nouvelles démos. Bref, messieurs Lee & Louis, aussi louable que puisse avoir été votre contribution technique, la manière dont vous nous la servez se fait de plus en plus lamentable...


Les histoires d'Elcomsoft maintenant...

Annonce sur leur site et ailleurs, utilisée ensuite chez SC Magazine dans la section Advertise[1] par une obscure société de service qui va se permettre le même raccourci pour le moins rapide, lequel va être repris en cœur par toute la presse, spécialisée ou non :

With the latest version of Elcomsoft Distributed Password
Recovery, it is now possible to crack WPA and WPA2 protection
on Wi-Fi networks up to 100 times quicker with the use of
massively parallel computational power of the newest NVIDIA
chips. Elcomsoft Distributed Password Recovery only needs a
few packets intercepted (with any network sniffer that can
export data in tcpdump format) in order to perform the
attack.

Update et léger aparté pour nuancer mon enthousiasme maladif à chanter les louanges de la profession journalistique : tous les journalistes n'ont pas repris la news, certains n'étaient pas au courant, d'autres ont flairé le lièvre, d'autres ont d'emblé critiqué l'annonce, comme, me souffle-t-on à l'oreillette, CNIS Mag' dont le ton général mérite qu'on aille y faire un tour.

Sortons les mots clé : WPA, WPA2, 100 times, few packets, distributed. Commençons par le "few packets" si vous le voulez bien. Annoncé comme cela, on dirait presque que l'attaque elle-même est nouvelle. Mais non. Si effectivement le cassage des clés WEP a toujours nécessité une quantité appréciable de trafic mais très peu de puissance de calcul pour fonctionner, il n'en va pas de même pour le cassage de clés partagées WPA. En fait, c'est exactement le contraire. Vous avez besoin d'une authentification réussie pour commencer le calcul, c'est à dire un 4-Way Handshake[2]. Par contre, après, vous allez avoir besoin d'une quantité de calculs impressionnante, comme nous allons le voir plus loin. Donc casser du WPA-PSK en peu de paquets ? Rien de neuf sous le soleil, c'est comme cela qu'on l'a toujours fait.

Maintenant, sortons les chiffres, juste pour voir quel est l'amplitude de ce bouleversement. Ah mince alors, il n'y a pas de chiffre... Car vous pouvez retourner leur site web autant que vous voulez, les seules données factuelles que vous y trouverez ne concernent que les hashes MD5, NTLM et LM, ou encore les mots de passe Office 2007. Et c'est bien là que le bât blesse. Annoncer un gain en vitesse d'un facteur 100 par rapport à ce que fait un CPU, c'est peut-être bien, mais si on ne peut pas le vérifier, c'est un peu dommage. En particulier quand on propose un système distribué. Je ne sais pas ce qu'il en est pour vous, mais la première question que je me pose, c'est de savoir quels sont les poids de l'optimisation et de la distribution là-dedans. En effet, si vous gagnez tout ça, juste parce que vous avez une centaine de machines avec deux GPU chacunes qui tournent, je ne trouve pas ça impressionnant du tout. Et même plutôt le contraire. En tout cas rien qui justifie ce genre de buzzz.

Essayons donc de rationnaliser un peu. D'abord, exactement comme une annonce faite plus discrètement il y a quelques mois sur le cassage WPA/WPA2 par utilisation d'un cluster de PS3, il s'agit bel et bien de casser des clés partagées, donc de s'attaquer à la variante PSK de ces protocoles. Autant dire qu'encore une fois, la variante à base d'EAP n'est pas ciblée. Et aussi que tout ça tombe particulièrement bien, puisque cette annonce intervient quelques jours après une présentation que Simon et moi avons donnée à BA-Con sur les authentifications WPA/WPA2. Présentation dont la première moitié est justement consacrée au mode PSK et au cassage des clés partagées. De quoi remettre un peu les pieds sur Terre.

Quelles sont les règles du jeu ? D'abord, la clé partagée est une chaîne ASCII[3] de 8 à 63 caractères comme indiqué dans l'annexe F8 du draft 3.0 de 802.11i[4] qui sert de base à WPA[5]. Ce qui nous donne une idée précise de la taille de l'espace de clés à parcourir pour une attaque en force brute. Vous remarquerez également que ce document vous explique pourquoi il faudrait utiliser des PSK de plus de vingts caractères[6] :

A pass-phrase typically has about 2.5 bits of security per 
character, so the pass-phrase mapping converts an n byte
password into a key with about 2.5n + 12 bits of security. 
Hence, it provides a relatively low level of security, with 
keys generated from short passwords subject to dictionary 
attack. Use of the key hash is recommended only for IT-less 
environments. A key generated from a pass-phrase of less than 
about 20 characters is unlikely to deter attacks against 
small businesses and enterprises.

Ensuite, pour produire la clé maîtresse qui sera utilisée lors du 4-Way Handshake, la PMK, il est nécessaire de faire passer cette PSK par une fonction PBKDF2 qui va nécessiter pas moins de 4096 tours, chacun nécessitant la calcul de deux sommes HMAC-SHA1[7]. Rien que ça.

Alors question performances, qu'est-ce que ça donne ? C'est très simple. Nous avons fourni quelques chiffres, ça commence au slide 27 avec ce qui nous intéresse en particulier, à savoir la vitesse de calcul d'un CPU seul. En utilisant Aircrack, vous allez plafonnez à environ 650 psk/s. Ce qui, vous en conviendrez, est assez ridicule comparé à ce que vous sort un John ou un Bob sur du NTLM ou du MD5. Partons de là et appliquons le fameux facteur 100. On arrive à 65000 psk/s. Encore une fois, c'est ridicule. Une implémentation de MD5 dépassera allègrement le million de test par secondes, en particulier si on trouve une optimisation de la mort[8]. Mais ce n'est que cinq fois plus que ce qu'obtiennent sur un seul GPU Simon[9] ou les gars de Pyrit, dont le commentaire sur Elcomsoft vaut le détour. Alors question : ce facteur 5, il vient de l'algorithme ou de la distribution ?...

Enfin, une fois les chiffres en main, posons nous la question de savoir si tout ça est réaliste. C'est ce qu'a fait Bruno Cormier sur PCInpact. Ce type de test s'est montré suffisamment rare pour le mettre en avant, surtout quand c'est un site comme PCInpact qui le publie. Je vous conseille d'ailleurs la lecture des nombreux commentaires éclairés si vous avez du temps à perdre, c'est à se rouler par terre[10]. Comme d'habitude me répondront les esprits taquins... Bref, qu'est-ce que nous dis ce test ? D'abord que les implémentations utilisées par l'auteur ne sont pas conformes au standard, puisqu'elles lui permettent d'utiliser une PSK de cinq caractères. À moins qu'il n'ait pas vraiment fait un véritable test, mais juste regardé le temps annoncé par le logiciel... Ensuite que le logiciel, pour casser cette PSK ridiculement courte, va demander un jour et dix-huit heures. Et que si la clé passe à 10 caractères, il lui en faudrait un milliard. De jours...

Nouvelle update : Puissance PC s'est également livré à un test dont les conclusions ne sont pas inintéressantes. Par contre, il faudra vraiment que quelqu'un pense à expliquer à ces gens qu'une clé partagée WPA ça fait au minimum 8 caractères, ce qui leur aurait économisé cinq tests sur six...

Essayons quand même de nous montrer un peu plus pragmatiques. Évaluons le temps nécessaire pour casser une clé de huit caractères en force brute. Comme nous avons 95 possibilités par caractère, et une vitesse de calcul de 100k psk/s que nous allons leur accorder dans notre grande mansuétude, nous devrons attendre un nombre d'années pour le moins impressionnant :

95^8 / (100000*86400*365) = 2103

Oui, vous avez bien lu, 2103 ans pour casser 8 caractères sur la plage autorisée. Si on se limite aux seuls lettres et chiffres, on tombe nettement plus bas, mais c'est encore loin si vous avez autre chose à faire de votre vie :

62^8 / (100000*86400*365) = 69

Tout cela pour une raison très simple : PBKDF2 est une fonction très lente. En inversant le calcul, on peut se faire une idée des performances de leur logiciel. L'auteur nous dit que sa clé fait cinq caractères et n'utilise que des lettres et des chiffres, soit soixante-deux possibilités par caractère. Sachant qu'il lui faut quelques quarante-deux heures pour parcourir cet espace, cela veut dire qu'il tourne à 6000 psk/s. Ce qui est tout à fait conforme à ce que nous avons obtenu et aux benchs publiés chez Pyrit. Et on nous parle de performances révolutionnaires...

On pourra ressortir le super argument des rainbow tables WPA-PSK. Sauf que ce ne sont pas des rainbow tables au sens calcul systématique. Tout simplement parce que ce n'est pas possible. En effet, le SSID entre en ligne de compte dès le début du calcul et fait office de germe. De fait, une table, pour peu qu'on puisse la calculer, deviendrait alors dépendante du SSID. De plus, comme on l'a vu, la couverture par force brute de l'espace de clés est impossible. Au mieux on pariera sur des couvertures partielles. Eux ont donc recours à des dictionnaires. De fait, les fameuses tables, que j'aurais plus tendance à qualifier de simples lookup tables[11], sont un ensemble de données qui va couvrir les mille SSID les plus courants et un dictionnaire d'un million de PSK. Petit exercice laissé à la patience du lecteur : calculer le temps nécessaire au calcul d'une rainbow table, une vraie, pour les Livebox, sachant que le SSID est de la forme "Livebox-AABB" ou AA et BB sont des caractères hexadécimaux et que la clé fournie par défaut est une chaîne apparemment aléatoire de treize caractères hexadécimaux[12]. Good luck Jim...

Alors en conclusion, qu'est-ce qu'on peut retenir ? Que cette annonce, c'est du vent. D'abord parce qu'ils ne vont pas plus vite que les autres. On l'a vu, Pyrit et le PoC codé par Simon cet été obtiennent des chiffres équivalents. Ensuite, parce que la conclusion selon laquelle on peut attaquer du WPA/WPA2 PSK en force brute est tout simplement fausse. Il faut en effet plus de 2000 ans pour couvrir l'espace correspondant aux clés de longueur minimum, je vous laisse faire le calcul pour tout l'espace de clé. Et surtout que ce n'est pas ça qui va mettre à bas les mécanismes de sécurité Wi-Fi. Enfin, et encore une fois, qu'il faut réfléchir avant de relayer des conneries de ce genre.

Je laisserai donc la mot de la fin à Bruce Schneier : "Why exactly is this news? Yes, weak passwords are weak -- we already know that".


Ce qui ne veut pas dire qu'une véritable avancée ne sera jamais faite pour casser WPA ou WPA2. C'est juste qu'on l'attend encore...

Notes

[1] Ce qui en dit long au passage sur le magazine qui vous publie une pub avec exactement la même mise en page qu'un article, et de la boîte qui propose le texte...

[2] Quatre paquets, et vous pourriez même vous satisfaire de moins que ça...

[3] Caractères imprimables dont le code va de 32 à 126.

[4] C'est page 186 pour les gens pressés.

[5] Cf. slide 10.

[6] Read the source, Luke. Read the source...

[7] Cf. slide 12.

[8] Optimisation qui enterre Elcomsoft...

[9] Cf. slide 30

[10] Ou à pleurer, ça dépendra...

[11] Citation de la page web : "actually they are lookup tables but I just like the term 'rainbow tables' alot"...

[12] Pour pouvoir aussi servir de clé WEP...