Partant de l'hypothèse que les stations obtiennent leur configuration IP par le biais de DHCP sur la plupart des réseaux, ils proposent une modification de tkiptun-ng visant à travailler sur les DHCP ACK renvoyés par le routeur plutôt que sur le trafic ARP. Un tel paquet est intéressant à double titre pour l'attaquant. D'une part, à l'instar d'un paquet ARP, son contenu est hautement prévisible. D'autre part, ce contenu est long, entre 330 et 584 octets. Partant des mêmes hyptohèses de travail que Beck et Tews, il apparaît qu'il ne reste que 16 octets à découvrir sur un tel payload. De même que l'émission d'un paquet ARP, la négociation DHCP pourra être déclenchée en désassociation la station ciblée.

Le temps théoriquement nécessaire à une attaque réussie est estimé à 18 minutes environ. Dans la pratique, les auteurs avancent une fourchette de 25 à 40 minutes, ce qui reste tout de même assez long. Le résultat est la récupération de 596 octets de keystream, contre 48 pour Beck et Tews. Un joli facteur 12 qui permet d'élargir singulièrement la taille des paquets pouvant être injecté par la suite. Une belle amélioration donc, mais dont les applications restent les mêmes : envoyer des paquets à une station précise. Les limitations sont donc également les mêmes, et ces applications restent affreusement pauvres. En plus d'une corruption de cache ARP assez inutile mentionnée dans le papier original, les auteurs proposent deux nouvelles applications. La première est un un déni de service évident qui consiste à déclencher des "MIC failures" à gogo visant à garder les stations visées désassociées, ce qui se fait aujourd'hui plus simplement avec aireplay-ng à grands coups de trames de management. Les esprits taquins avanceront l'utilité de l'attaque dans la perspective de 802.11w, sauf que ce dernier est censé mettre TKIP au placard...

La seconde, plus intéressante peut-être, est une technique de "firewall piercing" visant à faire émettre par un client interne un paquet à destination d'une machine contrôlée sur Internet et obtenir de ce fait une autorisation temporaire de retour au niveau de pare-feu. Ça va certainement fonctionner pour de l'UDP, mais il faudra un moteur d'états un peu niais pour que ça colle avec TCP. Quant aux applications, c'est encore fois assez maigre. Il y a cependant moyen d'établir un canal de communication avec l'extérieur qui pourrait être mis à profit pour achever une attaque nécessitant des situations de clair connu, voire choisi. Pas de quoi sauter au plafond cependant...

Si la modification décrite est intellectuellement intéressante, le sont peut-être encore plus les pistes de travail proposées à la fin de l'article. Elles permettent en effet de bien cibler les limitations de ces attaques sur TKIP, qu'il s'agisse de l'originale par Beck et Tews, ou de l'amélioration indûment médiatisée proposées par les japonais d'une part ou encore celle que je vous décris ici. Pour la petite histoire, ils proposent d'essayer d'étendre l'attaque en utilisant la fragmentation[1], ce que je mentionnais déjà l'an dernier. Ceci dit, les maigres expérimentations que j'ai pu mener jusqu'à présent ne se sont pas montrées très fructueuses...

En définitive, un papier modeste qui fait avancer doucement le schmiblick sans pour autant chambouler l'état de l'art. Les attaques sur TKIP restent difficiles à mettre en œuvre et peu exploitables en pratique. Mais il est évidemment chaudement recommandé de passer en AES-CCMP pour se mettre à l'abri d'une amélioration majeure dans le domaine. D'autant que ce n'est pas compliqué, et que ça ne coûte rien[2]...

Notes

[1] Voir les attaques par fragmentation sur WEP de Bittau et al. publiées en 2005 et 2006.

[2] Dans l'immense majorité des cas...