Comprendre les attaques KRACK

Nous sommes fin octobre 2017, la rumeur court que le WPA2 est menacé par une attaque inédite. En effet, on peut voir apparaître au programme de la conférence CCS, un papier [1] intitulé « Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 » écrit par Mathy Vanhoef. Cette contribution attire rapidement l'attention de la communauté. À juste titre, car mis à part quelques faiblesses mineures, WPA2 n'a jamais été sérieusement attaqué et est considéré comme robuste. De plus Mathy n'en est pas à son coup d'essai et a déjà publié plusieurs attaques sérieuses contre le protocole Wi-Fi. L'excitation autour de ce papier est amplifiée par le fait qu'un embargo sur les détails de l'attaque a été mis en place : ceux-ci ne seront divulgués que le mercredi 1er novembre, date de la présentation du papier. Lors de cette présentation, on apprend que WPA2 et WPA sont affectés par des faiblesses que l'on peut qualifier de sérieuses : il serait possible, entre autres, de compromettre la confidentialité des données transmises.

Avant d'aller plus loin, il est important de noter que ces attaques ne permettent pas de retrouver le mot de passe d'un réseau, contrairement à des attaques telles que le FTW sur le WEP ou le bruteforce de clef à partir d'un handshake WPA. Si vous cherchez à retrouver le mot de passe d'un réseau Wi-Fi pour vous y connecter, passez votre chemin, ce n'est pas l'attaque que vous recherchez.

1. Quelques rappels sur la protection WPA/WPA2

Avant de nous lancer dans la description de l'attaque, il convient de rappeler certains éléments du mécanisme de protection WPA [2]. En particulier, comment les données transmises au sein des trames sont chiffrées.

1.1 Chiffrement des données

Que ce soit dans le mode de protection TKIP ou CCMP, le chiffrement des données implique toujours la combinaison du message clair (les données à protéger) avec un keystream. Un keystream étant une séquence de bits pseudo aléatoire que l'on génère avec un algorithme et une clef. La combinaison du message clair et du keystream se fait à l'aide d'une opération logique XOR bit à bit : chaque bit du message est XORé avec le bit correspondant du keystream. Le keystream est donc une série de bits de la même longueur que le message.

Pour chiffrer un message, on effectue donc le XOR avec un keystream. Pour le déchiffrer, c'est la même chose : on effectue un XOR du texte chiffré avec le même keystream. En effet, le XOR est associatif et chaque élément est son propre opposé. Ainsi les deux keystreams vont s'annuler : (m XOR k) XOR k = m XOR k XOR k = m XOR 0 = m.  

Si l'on dispose du message chiffré et du keystream, on est en mesure de calculer le message clair. Mais l'inverse est également vrai. Si on dispose du message clair et du message chiffré, on peut en déduire le keystream. Cette dernière propriété joue un rôle central dans l'attaque KRACK.

Pour garantir la confidentialité du message, ce keystream doit posséder plusieurs propriétés, dont celle d'être imprédictible si on ne connaît pas la clef ayant servi à le générer. Cette contrainte implique donc qu'un keystream ne pourra être utilisé qu'une seule fois. En effet, si le même keystream est utilisé deux fois, on pourrait déduire de l'information sur les messages correspondants. En particulier si un des deux messages est prédictible par l'attaquant, celui-ci connaissant le message dans sa version claire et chiffrée sera en mesure de déduire le keystream et de l'utiliser pour déchiffrer l'autre message.  

1.2 Utilisation de nonces

Nous avons vu qu'il était essentiel que les keystreams ne soient utilisés qu'une seule fois. En pratique cela est effectué grâce à l'utilisation de nonces (number used once) qui sont utilisés à la manière d'une graine lors de la génération du keystream. La génération d'un keystream dépend donc de la clef et du nonce.

Pour chaque trame transmise chiffrée, il est nécessaire que le nonce utilisé par l'émetteur soit également connu du récepteur ; autrement, il serait dans l'impossibilité de générer le bon keystream et de déchiffrer la trame. Pour assurer cette propriété, on utilise une technique simple : on utilise un compteur qui est incrémenté à chaque trame. Ainsi, chaque trame sera chiffrée avec un nonce différent.

Comme nous le verrons plus tard, l'initialisation de cette séquence de nonce se fait lors d'une étape correspondant à l'installation de la clef.

1.3 Handshake

Un mécanisme important de WPA est l'utilisation d'une étape de handshake qui est effectué lors de l'établissement de la connexion d'une station à un point d'accès : juste après la phase d'authentication et  d'association et juste avant l'échange des premières données chiffrées.

Ce handhsake permet, entre autres, de dériver le matériel cryptographique qui permettra de protéger la suite des échanges. En particulier, le handshake permet de dériver la clef de session PTK (Pairwise Transient Key) qui servira à générer les keystreams pour protéger les échanges entre la station et le point d'accès. De plus, le handshake permet aux deux parties de se prouver mutuellement qu'elles possèdent bien la même clef secrète (PMK) grâce à l'utilisation de défis.

Le protocole de handshake est constitué de 4 étapes qui vont permettre à chacune des parties de générer la PTK et au point d'accès de communiquer à la station la clef de groupe GTK. Ce protocole est présenté sur la figure 1.

• Message 1 : le point d'accès initialise le handshake en envoyant un défi à la station sous la forme de Anonce ;
• Message 2 : la station répond à ce défi et envoie son défi au point d'accès sous la forme de Snonce ;
• Message 3 : le point d'accès répond au défi et transmet la clef de groupe GTK à la station ;
• Message 4 : pour conclure le handshake, la station envoie un dernier message de confirmation au point d'accès.

La clef de session PTK étant dérivée à partir des nonces ANonce et SNonce, la station peut la calculer juste avant l'envoi du message 2 tandis que le point d'accès pourra la calculer à la réception du message 2. À l'issue du handshake, le point d'accès et la station possèdent le matériel cryptographique PTK et GTK et peuvent donc procéder à leur installation.  

1.4 Installation des clefs

L'étape d'installation des clefs est la dernière étape nécessaire avant de pouvoir échanger des messages chiffrés entre le point d'accès et la station. Comme nous l'avons vu plus tôt, le chiffrement des données utilise des nonces pour chiffrer chaque trame avec un keystream différent.

L'étape d'installation des clefs va donc consister à :

• affecter aux clefs de chiffrement PTK et GTK les valeurs qui viennent d'être dérivées par le handshake ;
• initialiser le compteur qui sera utilisé comme nonce.

Cette étape d'installation des clefs ne devrait avoir lieu qu'une seule fois par session (période d'utilisation d'une PTK) afin d'éviter la réutilisation de nonce. Ainsi, on peut lire dans la spécification [2] que, du côté de la station, cette installation doit avoir lieu après la réception d'un message 3 valide.

2. Description de l'attaque

Maintenant que nous avons les éléments importants de WPA en tête, nous pouvons passer à la présentation de l'attaque, ou plutôt à la présentation d'une attaque. Car il existe plusieurs variantes de KRACK qui affectent différents aspects de WPA/WPA2, et il serait trop long de toutes les présenter ici. Nous nous focaliserons sur une variante relativement  facile à comprendre.

2.1 Rejeux du message 3

Retour sur le handshake. Nous avons vu que c'est la réception du message 3 qui déclenche l'installation des clefs et donc la réinitialisation du nonce. Nous allons voir comment il est possible d'exploiter ce comportement pour réinstaller une clef et donc réinitialiser les nonces.

Comme dans tout système de communication et encore plus dans un système sans fil, il est possible que certains messages soient perdus. Le standard [2] prévoit cette éventualité au sein du handshake. Ainsi, si le  point d'accès n'a pas reçu le message 4, il retransmettra le message 3.  

Du côté de la station, le standard spécifie qu'à la réception du message 3, la station doit répondre avec un message 4 et procéder à l'installation de la clef (et donc à l'initialisation des nonces) ; et ceci même si le handshake avait déjà été préalablement correctement terminé.

Ainsi, si l'on est en mesure de transmettre à la station un message 3, celle-ci va systématiquement réinstaller  la clef PTK, ce qui aura pour effet de réinitialiser le nonce et de forcer la réutilisation d'un ou de plusieurs keystream. Cette réutilisation du keystream étant justement quelque chose qui devait être évité.

2.2 Homme au milieu basée sur les canaux

Un point de difficulté de cette attaque réside dans le blocage et la retransmission de certains messages lors du hanshake. Ces opérations se font classiquement suivant un modèle d'homme au milieu : un attaquant s'interpose entre les deux parties et obtient un contrôle total sur les messages transmis entre celles-ci. Dans le cas d'un réseau sans fil, il est compliqué de se placer dans cette position. En effet, les ondes se propageant dans toutes les directions et traversant la plupart des obstacles, il est difficile d'empêcher une partie de recevoir un signal émis par l'autre partie.

Pour pallier à cette difficulté, une technique d'interposition reposant sur l'utilisation de plusieurs canaux a été proposée. L'idée est de cloner le point d'accès sur un canal différent et de communiquer d'autre part avec le point d'accès sur son canal d'origine. Cette configuration est présentée sur la figure 2.

2.3 Exploiter la réutilisation du keystream

Suite à la réinstallation de la clef, le même keystream est potentiellement utilisé pour chiffrer plusieurs paquets. Très bien, mais les données sont toujours inaccessibles, car le keystream est a priori inconnu. Comme nous l'avons précisé plus tôt, il est possible de prédire le contenu de certaines trames et donc de déduire le keystream à partir du chiffré. Nous allons maintenant expliquer un tel exemple.

L'article original [1] présente un scénario simple qui met en jeu l'exploitation d'un keystream réutilisé. Dans ce cas précis, le keystream en question est celui utilisé pour protéger le message 4 envoyé par la station à la suite de la réception du second message 3. En effet, si lors de la phase initiale les messages du handshake sont transmis en clair, à partir du moment où la clef est installée, les messages (handshake ou autre) sont systématiquement chiffrés.

À partir de ce second message 4 chiffré, on est donc en mesure de déduire le keystream, car le contenu de ce message est identique à celui du premier message 4. Ce premier message ayant été envoyé non chiffré, en combinant son contenu avec le message chiffré, on obtient le keystream (propriété de l'opérateur XOR).

On a maintenant en notre possession un keystream qui sera réutilisé pour protéger un autre message. En choisissant judicieusement les moments où les messages sont transmis ou retransmis, on peut faire en sorte que ce keystream soit utilisé pour chiffrer un paquet de données. Voici par exemple ce qui peut être mis en œuvre afin de déchiffrer un paquet de données.

Lors du handshake, l'attaquant placé en position d'homme au milieu (voir figure 3) va bloquer le message 4 envoyé par la station à destination du point d'accès. En réaction, le point d'accès va retransmettre un nouveau message 3, que l'attaquant va faire suivre à la station. Cette dernière va alors suivre le protocole en envoyant la réponse à ce dernier message 3 sous la forme d'un message 4 chiffré. Puis, conformément aux spécifications, celle-ci va installer à nouveau les clefs. La station va ensuite envoyer des données au sein d'une trame qui sera chiffrée avec le même keystream que celui utilisé par le message 4 envoyé juste avant. En effet, ces deux messages sont tous deux envoyés juste après l'installation des clefs du côté de la station, ils partagent donc le même nonce (qui correspond à son numéro dans la séquence) et donc le même keystream.

Il devient alors trivial de déchiffrer ce message : connaissant le contenu du message 4 chiffré, on en déduit le keystream que l'on XORe au message chiffré pour en déduire le contenu en clair.

3. Réaction des acteurs concernés

Les attaques KRACK ont le potentiel de compromettre sérieusement la sécurité des systèmes. Il est donc important pour les développeurs et fabricants concernés de corriger rapidement cette vulnérabilité au sein de leurs logiciels et produits. Quels sont les acteurs concernés et comment ont-ils réagi face à cette menace ?

3.1 Identification et information des acteurs concernés

Pour ce qui est de l'identification des acteurs concernés, la tâche est relativement simple : tous les logiciels et appareils utilisant le Wi-Fi sont probablement affectés, comme l'indique Mathy sur son site (https://www.krackattacks.com/#amivulnerable). En effet, la vulnérabilité ayant son origine dans les spécifications du standard, toutes les implémentations de WPA et WPA2 sont potentiellement affectées par le problème.

Mathy explique sur le site [3] comment s'est déroulée l'information des acteurs. Il a tout d'abord cru avoir identifié un bug d'implémentation dans OpenBSD, et il a directement contacté les développeurs pour les informer du problème. Il a ensuite réalisé que le problème était plus large et pouvait affecter l'ensemble des implémentations de WPA/WPA2. Le centre de coordination du CERT (Computer Emergency Response Team) a alors été contacté afin qu'il mette en place une réponse concertée avec les acteurs concernés. Ceci a en particulier mené à la création de plusieurs CVE (Common Vulnerabilities and Exposures) [4], chacune correspondant à une des variantes de l'attaque KRACK. Tous les acteurs n'ont pas été informés au même moment du problème : certains ont été prévenus rapidement par le CERT, d'autres ont appris la nouvelle le jour de la publication de l'attaque.

3.2 Correction de la faiblesse

Après la publication de l'attaque, tous les acteurs concernés étaient donc au courant du problème et se devaient donc de préparer et diffuser un correctif. Comme l'atteste la page de Kristopher Tate [5], qui maintient une liste des réponses des acteurs pour la menace des attaques KRACK, beaucoup n'ont pas été informés par le CERT. Pour ce qui est de la correction du problème, on peut observer différentes situations. Pour certains acteurs (LineageOS, GNU/Linux, Samsung...), le problème a été corrigé rapidement ; pour d'autres, le problème a été identifié et il est indiqué que des travaux sont entrepris pour apporter une solution ; et pour les acteurs restants, aucune communication n'est disponible sur le sujet, comme si le problème n'existait pas.

Avoir un correctif disponible est une très bonne chose, mais le déployer est encore mieux. Si nombre de nos appareils disposent de mécanismes de mise à jour automatique, d'autres nécessitent une procédure manuelle de la part de l'utilisateur ou de l'administrateur. Autant dire qu'un bon nombre d'appareils ne bénéficieront pas de ce correctif et resteront vulnérables aux attaques KRACK.

3.3 La question de l'embargo

La découverte de cette attaque a été l'occasion de voir un cas d'école sur la gestion de la publication de l'attaque en vue d'une correction de la faille. Le problème qui se pose est le suivant : un chercheur découvre une faille affectant certains appareils ou services. Il a deux possibilités : rendre l'information publique le plus rapidement possible afin de permettre une correction rapide de la faille ; ou bien alerter discrètement les acteurs concernés et leur laisser un délai suffisant pour qu'ils préparent un correctif qui sera diffusé en même temps que la faille sera rendue publique.

L'avantage de la première option est qu'il donne la possibilité à tout le monde de corriger la faille. Cependant, cette information bénéficiera aussi à des acteurs malveillants. Les systèmes affectés seront donc exposés tant qu'ils n'auront pas bénéficié du correctif. La durée de cette fenêtre de vulnérabilité peut varier d'un acteur à l'autre en fonction des ressources disponibles et de la complexité de la correction de la faille.

La seconde option (l'embargo), quant à elle permet de limiter la diffusion de la vulnérabilité pendant que les acteurs ayant été informés préparent des correctifs. Si de loin, cette option peut paraître plus raisonnable, elle pose un certain nombre de problèmes. Premièrement, seuls les acteurs qui auront été avertis seront en mesure de préparer un correctif ; les autres découvriront la faille au moment de sa publication. On aurait donc envie d’informer le plus grand nombre d'acteurs possible ; cependant à chaque acteur supplémentaire, on augmente le risque d'une fuite d'information vers des acteurs malveillants. Deuxièmement, pendant la période d'embargo, aucun appareil ne recevra de correctif alors que des personnes seront au courant de la faiblesse. Un acteur malveillant ayant eu vent de cette faille pourra l'exploiter pleinement pendant toute la durée de l'embargo…

Dans le cas des attaques KRACK, l'option qui a été choisie est la seconde : sous la coordination du CERT/CC un groupe d'acteurs (environ une centaine) ont été avertis de la vulnérabilité. Ils ont ainsi bénéficié d'une période de deux mois pour préparer des mises à jour correctives qui ont pu être diffusées et déployées le jour de la publication de la faille.

Cependant, il y a eu un problème avec OpenBSD. Les développeurs d'OpenBSD avaient été avertis du problème par Mathy avant que celui-ci ne réalise l'ampleur de cette vulnérabilité et que le CERT soit impliqué. OpenBSD a alors refusé de se soumettre à l'embargo arguant que cette pratique n'était pas acceptable dans le monde de l'open source. Mathy a alors accepté un compromis : que ce patch soit diffusé silencieusement, c'est-à-dire qu'il n'y soit pas fait référence dans le changelog. C'est ainsi que ce patch fut intégré à la fin du mois d’août 2017 dans OpenBSD. Même silencieux, ce patch a pu mettre la puce à l'oreille de certaines personnes menant potentiellement  à une redécouverte de la faille par des acteurs malveillants. Suite à cet épisode, Mathy a annoncé qu'à l'avenir, OpenBSD recevrait les notifications à un moment plus proche de la fin de l'embargo.

4. Le cas de wpa_supplicant

Notre OS préféré n'a pas été épargné par cette attaque. Pire cette attaque a un effet « dévastateur » sur wpa_supplicant : au lieu de réinstaller la clef, c'est une clef égale à zéro qui est installée à la place ! Avec une clef nulle, il est possible de déchiffrer l'ensemble du trafic sans avoir à effectuer de manipulations pour retrouver le keystream.

Les versions 2.4 et 2.5 étaient affectées par cette faille, et on a découvert plus tard qu'une variante de l'attaque affectait également la version 2.6. Un certain nombre de machines tournant sous GNU/Linux était donc vulnérable à cette attaque.

Mais wpa_supplicant est également intégré à Android, sous une forme dérivée. La conséquence est que les versions 6.0 et supérieures d'Android étaient vulnérables à au moins une des attaques KRACK. Au moment de la découverte de l'attaque, cela représentait plus de 50 % des appareils Android utilisés dans le monde.

En réponse aux vulnérabilités KRACK dans wpa_supplicant, plusieurs patchs ont été proposés : https://w1.fi/security/2017-1.

4.1 Détails du Bug de l'installation d'une clef nulle

Nous allons nous intéresser  à la vulnérabilité qui permettait l'installation d'une clef nulle et qui a été corrigé par le patch du commit ad00d64e7d8827b3cebd665a0ceb08adabf15e1e dont les détails sont disponibles à l'adresse suivante : https://w1.fi/cgit/hostap/commit/?id=ad00d64e7d8827b3cebd665a0ceb08adabf15e1e.

Ce commit concerne principalement le fichier src/rsn_supp/wpa.c dont nous allons détailler certaines parties afin de comprendre le problème. Nous allons en particulier nous intéresser à l'évolution de la variable  sm->ptk.tk qui va recevoir la valeur de la clef PTK calculée lors du handshake et qui sera utilisée pour être installée.

4.1.1 Calcul de la clef PTK

On trouve dans wpa.c, au sein de la fonction wpa_supplicant_process_1_of_4 l'étape de calcul de la clef PTK à partir des différents éléments échangés durant le handshake. Ainsi à la ligne 490, on trouve l'appel à la fonction wpa_derive_ptk qui effectue ce calcul :

4.1.2 Installation de la clef PTK

On  trouve dans wpa.c, la fonction wpa_supplicant_install_ptk qui est en charge d'installer la PTK. À la ligne 635, on trouve la portion de code qui installe la PTK représentée par sm->ptk.tk. Cette installation se fait via l'appel à la fonction wpa_sm_set_key :

4.1.3 Mise à zéro de la variable contenant la clef PTK

Un peu plus loin, toujours dans la fonction wpa_supplicant_install_ptk, la variable contenant la clef PTK est mise à zéro. Si elle est mise à zéro c'est qu'on considère qu'elle n'est plus utile (on vient de l'installer), et que pour des raisons de sécurité, on évite de laisser traîner des clefs en mémoire. On peut voir la mise à zéro de sm->ptk.tk à  la ligne  644 :  

4.1.4 Conséquence du rejeu du message 3

Le problème est que maintenant, la clef PTK représentée par sm->ptk.tkest à zéro, et si jamais la fonction wpa_supplicant_install_ptk est appelée à nouveau (par exemple à la suite de la réception d'un message 3), c'est cette valeur nulle qui sera installée (voir figure 4). D'où le bug de l'installation d'une clef nulle lorsque le message 3 est rejoué. Si le protocole se déroule « normalement » (enchaînement des messages 1,2,3,4) ce problème ne se présente pas puisque l'on passe nécessairement par l'étape de dérivation de la clef PTK avant son installation.

4.1.5 Solution : vérifier si la clef a déjà été installée

La solution qui a été proposée pour corriger ce bug, est d'utiliser un flag sm->tk_to_set pour se souvenir si la clef PTK a déjà été installée et donc de ne pas la réinstaller si cela n'est pas nécessaire. Ainsi, on peut lire cette vérification au début de la fonction wpa_supplicant_install_ptk, dans la version patchée de wpa.c à la ligne 609 :

5. Tester la vulnérabilité de nos appareils

Quand une telle menace fait son apparition, la première chose qui nous vient à l'esprit est de vérifier si nos appareils sont vulnérables. Mathy a mis à disposition des outils permettant de vérifier si un appareil est vulnérable aux attaques KRACK. Ces outils permettent de tester la vulnérabilité des stations et des points d'accès. Dans cet article, nous nous contenterons de décrire les outils de test pour les stations.

5.1 Installation et préparation de l'environnement de test

Les outils de test développés par Mathy sont disponibles à l'adresse suivante : https://github.com/vanhoefm/krackattacks-scripts. Pour pouvoir les utiliser il nous faut :

• une interface Wi-Fi (nous avons utilisé une TP-Link TL-WN722N v1 équipée d'un chipset AR9271) ;
• une machine (éventuellement virtuelle) avec un OS Linux installé (Kali est conseillée) ;
• un appareil Wi-Fi à tester.

5.1.1 Récupération du dépôt et installation de paquets

On commence par récupérer les outils de test en clonant le dépôt :

Puis on installe quelques paquets :

5.1.2 Désactivation du chiffrement matériel

Mathy conseille de désactiver le chiffrement matériel qui risque de perturber les outils de test. Celui-ci permet de déporter les opérations de chiffrement sur un élément matériel dédié intégré à la carte Wi-Fi. Lorsqu'il est utilisé, on perd l'accès direct aux trames dès leur réception.

On désactive le chiffrement matériel via le script disable-hwcrypto.sh :

Comme suggéré par le script, il faut redémarrer la machine pour s'assurer que ce changement est bien pris en compte. On peut ensuite vérifier que ce changement est bien effectif en s'assurant que le flag nohwcrypt est bien activé dans le module associé au driver de notre carte Wi-Fi (ici ath9k_htc) :

5.1.3 Compilation et configuration de hostapd

Les outils de test des stations reposent sur une version modifiée de hostapd qu'il faut tout d'abord compiler :

il faut ensuite modifier le fichier de configuration krackattack/hostapd.conf afin que hostapd utilise l'interface Wi-Fi sélectionnée pour l'occasion ; dans notre cas, il s'agit de wlan18 :

5.1.4 Préparation de l'interface Wi-Fi

Afin d'éviter toute interférence avec nos tests, il convient de désactiver la gestion du Wi-Fi par le network manager :

Puis il faut s'assurer de libérer l'interface Wi-Fi à l'aide de :

5.2 Exécution et interprétation des tests

Dans le répertoire krackattack, on trouve plusieurs scripts qui servent à tester la vulnérabilité des appareils. Nous allons nous intéresser au script krack-test-client.py qui permet de tester la vulnérabilité des stations Wi-Fi (clients). Le lancement de cet outil va normalement créer un point d'accès ayant pour SSID testnetwork et comme mot de passe abcdefgh (ces paramètres sont modifiables dans le fichier hostapd.conf). Pour tester un appareil, il faudra bien évidemment connecter celui-ci à ce point d'accès en s'assurant qu'il est configuré pour obtenir une adresse en DHCP.

Dans la suite, nous allons utiliser l'outil de test dans sa version de base : celle qui permet de tester la vulnérabilité d'une station au rejeu du message 3. Ce test s'effectue en lançant le script krack-test-client.py sans option.

5.2.1 Rejeu du message 3 avec Android   

Nous avons dans un premier temps testé la vulnérabilité d'un smartphone Galaxy A5 2017 tournant sous Android 7.0. On lance l'outil krack-test-client.py et l'on connecte notre appareil au point d'accès correspondant.

On voit que dès qu'une station se connecte, le point d'accès commence à effectuer des tests qui consistent à envoyer des messages 3 à la station. En fonction de la réaction de la station, le point d'accès est capable de déterminer si la station est vulnérable à l'attaque. Pour ce faire, le point d'accès inspecte les messages reçus après cet échange à la recherche d'indications d'une réinstallation de la clef.

Dans le cas de notre Android, l'attaque ne fonctionne pas : Client DOESN'T reinstall the group key in the 4-way handshake (this is good). En effet, même si notre appareil était a priori vulnérable (version d'Android supérieure à 6.0) il a bénéficié de la mise à jour de sécurité qui corrigeait la vulnérabilité aux attaques KRACK (https://source.android.com/security/bulletin/2017-11-01).

5.2.2 Rejeu du message 3 wpa_supplicant 2.4

Dans un second temps, nous avons testé  wpa_supplicant 2.4 que nous savons vulnérable à l'attaque (voir section 4). Nous lançons donc une deuxième fois notre test en utilisant cette fois-ci une machine Linux avec wpa_supplicant 2.4 en guise de station.

Comme nous l'attendions, les nouvelles sont mauvaises : Client reinstalls the pairwise key in the 4-way handshake (this is bad) ; notre client est donc vulnérable à l'attaque qui vise à réinstaller la clef. En effet, à la suite de la retransmission d'un message 3, le point d'accès constate une réutilisation de nonce (IV pour Initialisation Vector).

Nous allons maintenant étudier le déroulement du test en analysant le trafic entre la station et le point d'accès. Pour cela, nous allons capturer le trafic sur l'interface du point d'accès. À l'aide de Wireshark, on peut observer (voir figure 5) le déroulement normal du handshake, puis l'initialisation du test qui consiste à la transmission d'un message 3 auquel répond un message 4.

Pour déterminer si la réinstallation de clef a fonctionné, il faut aller regarder si les nonces utilisés ont été réinitialisés après le rejeu du message 3. Les nonces sont ici appelés IV (Initialisation Vector). Nous allons utiliser tshark pour afficher les informations pertinentes pour vérifier la réinstallation. En plus des adresses source et destination (wlan.sa et wlan.da), nous allons afficher la présence du champ eapol qui caractérise les messages du hanshake. De plus, nous allons également afficher l'IV quand celui-ci est présent (wlan.ccmp.extiv). Nous allons également appliquer un filtre afin de n'afficher que les trames qui concernent notre station (wlan.addr == 64:80:99:8c:bb:6c) et qui sont soit des trames chiffrées (présence de wlan.ccmp.extiv), soit des trames concernant le handshake (présence d'un élément eapol). On obtient alors la sortie suivante :

On constate qu'après le handshake, les trames chiffrées sont transmises avec un IV qui s'incrémente progressivement en partant de la valeur 0x000000000001. Puis à la trame 1260, le message 3 est rejoué. On observe qu'après cette étape, la séquence d'IV repart de la valeur 0x000000000001 ; la clef a bien été réinstallée. En pratique, cela implique que le même keystream a été utilisé pour chiffrer la trame 1216 et la trame 1376.

5.2.3 Autres tests disponibles

L'outil krack-test-client.py supporte plusieurs modes de fonctionnement que l'on sélectionne via des options. Le mode par défaut, que nous venons de tester permet de tester la vulnérabilité aux rejeux du message 3. En utilisant l'option --tptk, on peut tester une variante de cette attaque qui affecte, entre autres, la version 2.6 de wpa_supplicant (voir section  4). Cette variante implique la transmission d'un message 1 avant la transmission du message 3. D'autres modes sont disponibles et permettent de vérifier la vulnérabilité aux attaques sur la clef de groupe GTK, que nous n'avons pas couvert dans cet article.

Il existe également un script pour vérifier la vulnérabilité à une variante de l'attaque KRACK pouvant affecter les points d'accès. Ces attaques reposent sur l'exploitation du FT Handshake et n'ont pas été abordées dans cet article. Les lecteurs curieux pourront essayer ce script, krack-ft-test.py, qui repose sur l'utilisation d'une version modifiée de wpa_supplicant et dont le fonctionnement est détaillé sur le site https://github.com/vanhoefm/krackattacks-scripts.

Conclusion

Comme nous venons de le voir, les attaques par réinstallation de clef peuvent avoir un impact dramatique sur la sécurité des communications via Wi-Fi. Ces attaques affectent l'ensemble des protections WPA, quels que soient les modes utilisés TKIP, CCMP, PSK, EAP… Personne ne pouvait donc se prétendre à l’abri.

Une caractéristique de cette attaque est qu'il ne s'agit pas d'un simple bug d'implémentation, puisque le comportement fautif est défini dans le standard. Ceci explique qu'un grand nombre d'implémentations soient  vulnérables, puisque celle-ci se sont basées sur les spécifications du standard.

Mais comment une telle faille a-t-elle pu être intégrée dans un standard aussi utilisé ; et surtout comment a-t-elle pu passer inaperçue pendant plus de 10 ans ? Certains, comme le chercheur Matthew Green [6], expliquent ça par le fait que les organismes de standardisation comme l'IEEE ne sont pas assez ouverts. En effet, il est difficile d'obtenir les versions préliminaires des standards pendant leur période d’élaboration. Celles-ci ne peuvent donc pas être étudiées et critiquées par l'ensemble de la communauté.

De plus, certaines personnes critiquent la clarté des documents de spécifications. Dans le cas qui nous intéresse, la machine d'état, censée décrire le processus de handshake et l'installation des clefs, était seulement partiellement décrite dans le document original. De manière générale, les standards de protocoles aussi complexes que le Wi-Fi (IEEE802.11) sont très longs (plus de 2700 pages pour la version 2012 de IEEE802.11 [2]), et sont écrits dans un langage technique parfois difficile à comprendre par des personnes extérieures au monde de la standardisation.  Ainsi, peu de personnes sont en mesure de comprendre toutes les subtilités et d'identifier d'éventuels problèmes.

Les problèmes associés à KRACK ont été identifiés et des correctifs préparés. Mais combien d'appareils vont réellement recevoir ces correctifs ? Il y a fort à parier que parmi tous nos smartphones, tablettes, et autres gadgets connectés via le Wi-Fi, un certain nombre ne seront pas patchés et resteront vulnérables à cette attaque jusqu'à la fin de leur vie.

Tournons-nous vers l'avenir maintenant. Une nouvelle certification nommée WPA3 va faire son apparition et intègrera la correction de ces vulnérabilités. Il est fort probable que de nouvelles faiblesses seront trouvées, mais il est raisonnable d'espérer que leur criticité sera moins importante. En effet, les premières attaques sur WEP permettaient à un attaquant passif de récupérer la clef du réseau ; cette dernière attaque sur WPA ne permet que de déchiffrer certains messages et nécessite la mise en place d'un processus élaboré (homme au milieu par canaux, rejeux de trames...). Cette tendance suggère que nous allons dans la bonne direction : des attaques de plus en plus difficiles à mettre en œuvre et avec un impact de moins en moins important. Mais peut-être pourrions-nous y aller plus vite si les instances de standardisations s'ouvraient un peu plus à la communauté.     

Références

[1] M. VANHOEF et F. PIESSENS, « Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2 »,  ACM CCS, 2017, p. 1313 à 1328.

[2] « IEEE Std 802.11-2012 », 2012, p 76, 1232 à 1233.

[3] M. VANHOEF, « Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2» : https://www.krackattacks.com/

[4] CERT/CC, « Wi-Fi Protected Access (WPA) handshake traffic can be manipulated to induce nonce and session key reuse », Vulnerability Note VU#228519, 16 octobre 2017 : https://www.kb.cert.org/vuls/id/228519

[5] K. TATE, « Vendor Response Matrix for KRACK WPA2 (Key Reinstallation Attack) » : https://github.com/kristate/krackinfo

[6] Matthew Green, « Falling through the KRACKs », 16 octobre 2017 : https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks

Pour aller plus loin

Dans cet article, nous nous sommes contentés de présenter un aperçu d'un sujet hautement technique et très vaste. Si vous souhaitez approfondir le sujet, les références suivantes constituent un bon point de départ :

• la vidéo de Mathy Vanhoef présentant la démonstration de l'attaque : https://www.youtube.com/watch?v=Oh4WURZoR98 ;
• la vidéo de la présentation à la conférence 34C3 : https://ftp.darmstadt.ccc.de/congress/2017/h264-hd/34c3-9273-eng-deu-spa-KRACKing_WPA2_by_Forcing_Nonce_Reuse_hd.mp4 ;
• le site dédié à l'attaque qui est une mine d'informations : https://www.krackattacks.com/ ;
• les slides de la présentation à la NullCon 2018 : https://papers.mathyvanhoef.com/nullcon2018-slides.pdf ;
• un post du blog Mojo Network : https://blog.mojonetworks.com/wpa2-vulnerability.