Le premier est la publication par Andrea Bittau, Mark Handley et Joshua Lackey d'un article intitulé "The Final Nail in WEP's Coffin" décrivant l'attaque contre WEP utilisant la fragmentation dans 802.11, déjà présentée par A. Bittau à ToorCon[1] l'an dernier et que j'ai mentionnée dans un billet précédent (rapidement) et quelques conférences.

Il s'agit d'une méthode permettant à un attaquant de déclencher la génération du trafic nécessaire pour cracker la clé WEP du réseau cible. Elle s'appuie sur la bonne vieille ré-utilisation des keystreams RC4 découverts par exploitation des clairs connus combinée à la possibilité de fragmenter les trames 802.11 jusqu'à 16 morceaux. Tout part de la constatation que les 8 premiers octets de le charge chiffrée d'une trame sont connus[2] donnant ainsi 8 octets de keystream RC4 à partir de n'importe quel paquet (ou presque) échangé, permettant ainsi à l'attaquant de chiffrer d'une part 4 octets de données et d'autre part les 4 octets de CRC32 qui vont avec. Comme on ne va pas très loin avec 4 octets, il fallait trouver autre chose pour pouvoir chiffrer plus de données. C'est là qu'intervient la fragmentation : on va utiliser le même keystream pour chiffrer tous les fragments d'une même trame d'une taille maximale de 64 octets de données (4*16).

Pour bien comprendre l'intérêt de l'attaque, il faut se pencher sur la gestion par un point d'accès des fragments chiffrés. Lorsque ce dernier reçoit un fragment[3], il le met de côté avec tous ses compères[4]. Une fois qu'il les a tous, il les déchiffre un par un et réassemble la trame initiale pour la traiter. Et si celle-ci est à destination du réseau sans-fil, il la chiffre et l'envoie, entière. L'AP défragmente donc la trame . So what ? L'attaquant se trouve face à un nouveau clair connu ! Il connaît en effet le contenu de cette trame puisqu'il l'a lui-même fabriquée et décomposée en fragments, ce qui lui permet de récupérer un keystream de 68 octets (64 de données et 4 de CRC32) avec lequel il va pouvoir rejouer la même attaque une seconde fois pour parvenir à 1028 octets et enfin une troisième pour atteindre la MTU. À ce stade là, l'attaquant est capable d'injecter n'importe quelle trame sur le réseau.

Ensuite, les applications coulent de source. Deux techniques sont décrites dans l'article et implémentées dans l'outil proposé pour forcer une génération massive de trafic sur le réseau. La première consiste à découvrir l'adresse IP d'une machine sur le réseau pour, dans le même esprit qu'aireplay, l'inonder de requêtes ARP. La seconde consiste à découvrir l'adresse MAC de la passerelle du réseau afin de communiquer avec un hôte extérieur, contrôlé de préférence. On lancera alors tranquillement aircrack sur le trafic généré pour finalement casser la clé WEP.

Comme l'écrivent les auteurs en conclusion, il s'agit d'une technique, terriblement ingénieuse, exploitant une vieille faille bien connue, la ré-utilisation des keystream RC4, mais qui se montre d'une excellente efficacité. Elle jouit en particulier de conditions nécessaires à son lancement assez favorables, n'importe quel paquet IP pouvant faire l'affaire. Il ne faut cependant pas sombrer dans le sensationnalisme en annonçant comme ça a été fait que l'attaque rend le WEP inutile, puisqu'on le savait déjà depuis pas mal de temps, ou que la clé va tomber en quelques secondes, ce qui n'est pas vrai comme le montre une lecture attentive de l'article[5].


Le second évènement marquant est la démonstration controversée pendant la BlackHat US de l'exploitation sur un Macbook Pro d'une faille dans un driver WiFi. Pourquoi controversée ? Parce que toujours en quête de sensationnel, certains se sont surtout focalisés sur le facteur Apple de l'équation. La plate-forme du constructeur de Cupertino réputée si sécurisée, malgré son dernier lot de 125Mo de patches de sécurité, apparaissait donc vulnérable au premier attaquant venu. Dur... Sauf que les auteurs, David Maynor et Johnny Cache, n'ont pas utilisé la configuration matérielle native et ont exploité le pilote d'un adaptateur WiFi USB tierce partie, fait d'abord éludé par les commentateurs qui n'a pas manqué de déclencher des réactions du côté du fabricant et une vague d'articles, de billets et autres posts à droite et à gauche. Ceci étant, David Maynor, pas vraiment aidé par son pêtard mouillé de Cansecwest/core05[6], aurait confié avoir trouvé une faille similaire dans le driver de la carte embarquée, mais personne n'aurait encore reçu quoi que ce soit du côté d'Apple ou Atheros. On n'en sait donc pas vraiment plus sur ce sujet...

Mais est-ce réellement important ? D'autant que la vidéo de la démonstration est claire sur ce point. Est-ce l'essentiel ? Non, bien évidemment. Le point important que toute cette polémique stérile occulte, c'est la faiblesse de certains drivers qui se révèlent exploitables, soit à cause de mauvaises spécifications comme cela a été montré sur le Firewire à Pacsec/core04, soit à cause de bugs. Des travaux concluants ont d'ailleurs été mené avec succès sur le PCMCIA et l'USB, tant au niveau code que fonctionnalités, prouvant que se méfier du matériel inconnu était de mise. Mais tout cela nécessite néanmoins un accès physique à la machine. Alors que face à un driver WiFi actif, associé ou non, le méchant accède directement au mode noyau en remote. Et boom headshot, comme dirait Doug.

Au dela de la stérile polémique autour de configuration vulnérable, il s'agit donc bien de repasser un certain nombre de drivers en revue. Déjà, en début d'année, une faille avait été annoncée sur le driver Atheros sous BSD et Linux, mais apparemment pas exploitée, tirant une première fois la sonnette d'alarme. Maintenant, messieurs les sceptiques, c'est officiel, ça marche.


Dans les derniers points à signaler, on notera, toujours dans la section WiFi, une nouvelle présentation de David "H1kari" Hulton et Dan Moniz sur le cassage de clés WEP et WPA sur des clusters de FPGA,. Autre point, la publication des slides de la présentation de Joanna Rutkowska dont je vous parlais précédemment. Ils permettront à tous les curieux d'avoir plus de détails sa backdoor Blue Pill.

Notes

[1] Voir les archives de l'édition 2005.

[2] 0xAAAA030000000800 pour IP et 0xAAAA030000000806 pour ARP.

[3] Flag MF positionné à 1.

[4] Même FrameID dans le numéro de séquence.

[5] Voir la page 13 en particulier.

[6] Absence totale de code ou démonstration pour appuyer ses dires.