a semaine dernière, Martin Beck a annoncé des améliorations à l'attaque sur TKIP qu'il avait publiée avec Éric Tews fin 2008. Dans son papier intitulé "Enhanced TKIP Michael Attacks", il décrit d'abord une méthode permettant de récupérer des keystreams plus longs puis une attaque sur le MIC Michael permettant de modifier le début d'une trame chiffrée.
Du travail qui fournit manifestement de bons résultats, scénarios d'exploitation à la clé, mais sous des conditions qui risquent fort de rendre ces attaques fort difficiles à réaliser puisqu'elles sont encore plus drastiques que celles nécessaires à la bonne réalisation de l'attaque originale...
Comme je l'ai déjà expliqué, les attaques en récupération de keystream sont relativement efficaces dans la mesure où le keystream récupéré est suffisamment long pour l'utilisation que vous comptez en faire d'une part, et que vous pouvez le ré-utiliser d'autre part. Dans le cas de l'attaque de Beck et Tews, si la possibilité de rejouer le keystream est bien maîtrisée, obtenir une longueur décente augmente considérablement le temps nécessaire à la réalisation de l'attaque[1], mais également les chances de la voir échouer. D'où l'intérêt de trouver des méthodes permettant de récupérer des keystreams plus longs, plus vite.
Pour ce faire, Martin Beck propose de jouer avec la fragmentation et la prédicitibilité des entêtes IP. En effet, la valeur des trois premiers champs de l'entête IP est prédictible : les champs Version, Longeur et Diffserv donnent en général 0x4500. Sachant que les huit octets d'entête LLC/SNAP sont également connus, ça nous permet de récupérer douze octets de keystream par paquet IP observé. On peut alors les utiliser pour chiffrer des fragments d'un datagramme plus long, jusqu'à 120 octets de payload[2]. On peut également jouer avec des paquets ARP qui fournissent nettement plus d'information puisque dans ce cas, ce sont les 28 premiers octets du payload qui sont connus[3], ce qui repousse à 568 octets après application de la fragmentation.
À partir de là, on peut commencer à injecter du trafic à destination de la station cible. Dans l'exemple proposé, on lui envoie un TCP SYN[4] dont l'adresse source correspond à un système contrôlé sur Internet. Si le succès est au rendez-vous, on va se retrouver avec une double situation de clair connu : d'abord parce qu'on va récupérer le TCP SYN/ACK envoyé par la station à destination de l'AP en clair sur notre serveur, ensuite parce qu'on va retrouver le TCP ACK correspondant chiffré sur le réseau Wi-Fi.
Encore faut-il que la station attaquée réponde au SYN...
La seconde partie décrit une attaque permettant de préfixer un payload chiffré par un contenu arbitraire, tout en conservant la validité du MIC. En gros, on génère une collision de MIC, ce qui est loin d'être inintéressant comme on va le voir plus loin. Si on sait faire ceci, on peut l'exploiter de la manière suivante. D'abord, on capture un paquet dont on utilisera la charge comme deuxième fragment d'une trame plus grande. Le premier fragment sera notre payload, chiffré avec un keystream connu. Ainsi, on obtient deux trames qui, une fois défragmentées, vont délivrer un paquet dont le début est maîtrisé par l'attaquant et dont la fin contient la charge du paquet capturé.
Beck propose assez naturellement d'ajouter à notre payload chiffré un ente de requête banale, à savoir un ping. Le premier fragment créé par l'attaquant contiendra donc les entêtes IP et ICMP de l'Echo Request, avec une adresse IP source correspondant, encore une fois, à une machine contrôlée sur Internet. Pour peu qu'elle réponde, la cible renverra un Echo Reply à destination de cette adresse. Mais au-delà de la réponse, ce qui est hautement intéressant dans cette méthode, c'est que le payload de ce nouveau paquet sera précisément le contenu chiffré capturé précédemment. Lequel se retrouvera en clair dans le paquet qu'on récupèrera sur Internet. Ce qui nous fournit une méthode de déchiffrement de paquet relativement puissante.
Si j'écris relativement, c'est parce qu'elle ne permet de pas de déchiffrer n'importe quelle trame. En effet, le MIC prenant en compte les adresses MAC source et destination de la trame originale, celles-ci doivent être réutilisées pour créer la nouvelle trame avec la méthode proposée. Du coup, quand on attaque une station, on ne peut appliquer cette technique qu'au trafic émis par le point d'accès à destination de cette même station. Mais c'est déjà pas mal...
En conclusion, on pourra apprécier les astuces mises en œuvre ici pour étendre un peu plus loin l'impact des attaques contre TKIP. L'attaque en collision sur le MIC est également remarquable. Cependant, si on considère les conditions nécessaires à leur exploitation, on s'aperçoit qu'elles deviennent encore plus restrictives, ne serait-ce que parce qu'on attend que la machine visée réponde à un TCP SYN ou un ping.
En tout cas, ce seront, s'il en était encore besoin, des arguments de plus pour ne plus utiliser TKIP...
Notes
[1] Un octet par minute.
[2] 16x8 pour le payload total, auxquels il faut retirer le MIC et le CRC32.
[3] 8 octets de LLC/SNAP, 8 octets d'entête ARP puis deux fois 6 octets pour les adresses MAC
[4] Après déchiffrement d'un paquet ARP pour récupérer l'adresse de la machine, forcément).