Cet article est une revue de l’attaque KRACK - Key Reinstallation Attack présentée par Mathy Vanhoef dans son papier. Avec cette attaque, il est possible de casser le protocole WPA2 en interceptant et décryptant des communications sans être authentifié sur le réseau. Ici, je tente de détailler le plus clairement possible le fonctionnement de cette attaque en rappelant quelques notions autour desquelles gravite l’attaque, comme le problème cryptographique qui entre en jeu, ou le 4 way handshake utilisé dans le protocole WPA2.

J’ai commencé un PoC de l’attaque sur Github qui marche de temps en temps mais qui reste très instable. Si vous vous sentez de le regarder, le comprendre, et l’améliorer, n’hésitez pas !

Problème cryptographique

Cette attaque profite d’une erreur d’implémentation dans un protocole afin de résinstaller une clé cryptographique déjà utilisée tout en réinitialisant des paramètres censés être uniques. Cela permet d’obtenir des messages chiffrés avec cette clé, et avec des paramètres constants, cassant la robustesse du système cryptographique.

Exemple schématique représentant le chiffrement CCMP:

message_chiffre_1 = message_clair_1 XOR F(Clé, paramètre_1)
message_chiffre_2 = message_clair_2 XOR F(Clé, paramètre_2)

Dans cet exemple, F est une fonction complexe (AES pour CCMP), et si paramètre_1 et paramètre_2 sont différents, nous ne pourrons pas retrouver le message clair facilement. En revanche, s’ils sont similaires, alors nous aurons :

message_chiffre_1 = message_clair_1 XOR F(Clé, paramètre)
message_chiffre_2 = message_clair_2 XOR F(Clé, paramètre)

donc

message_chiffre_1 = message_clair_1 XOR constante
message_chiffre_2 = message_clair_2 XOR constante

Ce qui permet de supprimer la clé de l’équation, pour arriver à :

message_chiffre_1 XOR message_chiffre_2 = message_clair_1 XOR message_clair_2

Si nous connaissons l’un des messages, par exemple si le client envoie un GET à un site (GET / HTTP/1.1), alors nous aurons accès à message_clair_2.

4 way handshake

Vulgarisation

Lorsqu’un client se connecte à un point d’accès protégé par le protocole WPA2, il y a un échange de 4 messages qui est effectué afin de pouvoir ensuite échanger des informations en les chiffrant dans le but de les rendre illisibles pour toute personne aux oreilles un peu trop pendues n’appartenant pas au réseau.

Pour pouvoir construire une clé qui chiffrera tout, chaque partie aura besoin du SSID, de la clé du point d’accès, des adresses MAC des deux parties, ainsi qu’un nombre aléatoire généré par chacun.

Si nous françisons ce handshake, ça ressemble à ça :

[Message 1] Point d’accès - Je t’envoie un numéro aléatoire (Anonce) et mon adresse MAC. Moi j’ai déjà mon SSID et la clé du réseau, me permettant de calculer une clé commune à tous (PMK)

[Message 2] Client - Reçus ! J’ai fait une tambouille avec ton numéro (Anonce), un numéro que j’ai généré (Snonce), ton adresse MAC, mon adresse MAC, ton SSID et la clé (qui me donnent aussi la PMK), ça m’a donné la clé de chiffrement (PTK). Et du coup, je t’envoie mon numéro généré (Snonce) et mon adresse MAC pour que tu fasses la même tambouille.

[Message 3] Point d’accès - Reçus aussi. J’ai fait la même tambouille, donnant la clé de chiffrement (PTK). Thanks !

[Message 4] Client - Parfait ! Allez, discutons.

Une fois ce handshake effectué, une clé est partagée entre le client et le point d’accès sans jamais être passée sur le réseau, clé qui permettra de chiffrer le reste de la communication. Si jamais le client n’avait pas la bonne clé pour se connecter au point d’accès, alors la PMK était différente, ce qui entraine que la clé de chiffrement (PTK) n’est pas la même, et le client ne pourra pas communiquer avec le point d’accès.

Voici un schéma qui résume cette communication

Détails

Maintenant que nous avons compris le principe global, nous allons entrer un peu plus dans les détails.

Lorsque des clients sont connectés au point d’accès, ils produisent une PMK (Pairwise Master Key) qui se base sur le SSID, et sur la clé du point d’accès.

PMK = hash(SSID + Clé_AP)

Pour qu’un client communique avec le point d’accès, ils vont devoir se mettre d’accord sur une clé de chiffrement. Pour cela, la clé de chiffrement va se baser sur différents éléments

• PMK (Pairwise Master Key)
• Adresse MAC du point d’accès
• Adresse MAC du client
• Un numéro aléatoire généré par le point d’accès (Anonce - Authenticator Number used Once)
• Un numéro aléatoire généré par le client (Snonce - Supplicant Number used Once)

Cette clé est temporaire, et s’appelle PTK (Pairwise Temporal Key). Elle ne dure pas dans le temps, c’est son intérêt.

Afin de se mettre d’accord sur cette clé PTK, voici le 4 way handshake, vu d’une manière plus technique, mais pas encore complète

Il faut enfin ajouter un dernier élément, le compteur (Key Replay Counter). Celui-ci est généré au début du 4 way handshake et s’incrémente au fur et à mesure du handshake ainsi que dans toutes les communications qui suivront. Lorsque le premier message est envoyé, le point d’accès envoie une première valeur KRC. Le client répondra avec la même valeur, permettant au point d’accès de savoir à quel message 1 le client répond (plusieurs clients peuvent se connecter en même temps). Puis lors de l’envoi du deuxième message, le point d’accès l’incrémente, et le client répond avec cette nouvelle valeur.

Ensuite, pour les autres communications, ce compteur sera incrémenté à chaque message envoyé au point d’accès, on l’appelle d’ailleurs le PN (Packet Number) et ce compteur sera utilisé dans le chiffrement en tant que Nonce, ou IV (Initialization Vector), en garantissant une unicité pour chaque message. Si jamais deux messages sont chiffrés en utilisant le même Nonce, alors la solidité cryptographique tombe.

Voilà donc un schéma plus complet

Pour la culture, la fonction G qui permet de dériver la PMK afin de donner la PTK est une fonction pseudo aléatoire (Pseudo Random Function - PRF) basée sur HMAC utilisant SHA1 comme méthode de hachage.

Attaque : Key Reinstallation

Contexte et normes

Nous avons donc une vision assez claire de ce qu’il se passe lorsqu’un client tente de communiquer avec un point d’accès protégé via le protocole WPA2. Il y a un 4 way handshake qui permet aux deux entités de se mettre d’accord sur une clé de chiffrement temporaire qui a deux buts: Le premier est d’assurer au point d’accès que le client possède son mot de passe. En effet, si ce n’est pas le cas, les deux clés de chiffrement seront différentes et les deux entités ne pourront pas communiquer. Deuxièmement, cette clé de chiffrement temporaire permet aux deux entités de communiquer de manière chiffrée afin qu’un attaquant qui écoute sur le réseau ne puisse pas déchiffrer ou décrypter les communications.

Différents protocoles existent pour le chiffrement et la vérification d’intégrité des données une fois que la clé partagée a été calculée, par exemple TKIP (Temporal Key Integrity Protocol), qui est déprécié aujourd’hui, (AES-)CCMP (Counter-mode/CBC-Mac Protocol), largement utilisé de nos jours, ou encore GCMP (Galios/Counter Mode Protocol) également très utilisé.

Les deux derniers (CCMP et GCMP) sont deux protocoles très robustes tant que les règles sont suivies, notamment le fait de ne jamais réutiliser un même Nonce pour chiffrer deux messages.

C’est cette condition qui entre en jeu dans l’attaque KRACK.

Dans la partie précédente, nous avons vu que le Nonce utilisé pour chiffrer les communications est le PN (Packet Number), qui est incrémenté à chaque message. Jusqu’ici, pas de problème puisque cela garanti son unicité pour chacun des messages. Si un message se perd et que le client doit le renvoyer, il le renverra avec un PN incrémenté afin de continuer de garantir l’unicité du Nonce dans le protocole de chiffrement.

Il y a cependant un point un peu gris dans la norme IEEE 802.11 (avec l’amandement 802.11i - WPA2) sur la gestion des messages retransmis dans le 4 way handshake. Heureusement l’amandement 802.11r (FT - Fast Basic Service State Transition, qui précise et améliore la bascule de point d’accès quand une personne se déplace) a donné un schéma d’états précisant tout cela. Les deux points importants sont les suivants :

• Le point d’accès doit retransmettre les messages 1 et 3 s’il n’a pas reçu de réponse de la part du client, impliquant que le client doit gérer ces retransmissions.
• Le client doit installer la PTK suite à la réception du message 3, ce qui a pour effet de mettre à jour le compteur, égal à celui reçu dans ce 3ème message

Là où ça coince

Grâce aux deux idées du paragraphe précédent :

• Les deux protocoles CCMP et GCMP sont très robustes tant que les règles sont suivies, notamment le fait de ne jamais réutiliser un même Nonce pour chiffrer deux messages;
• Le client doit installer la PTK suite à la réception du message 3, ce qui a pour effet de mettre à jour le compteur, égal à celui reçu dans ce message;

nous pouvons maintenant bien comprendre comment peut se dérouler une attaque. Si l’attaquant se place entre le client et le point d’accès, et laisse passer les 3 premiers messages, mais qu’il bloque le 4ème message, c’est à dire l’acquittement du client envoyé au point d’accès, on se trouve dans la situation suivante :

Le client a envoyé son acquittement, donc de son point de vue, le 4 way handshake est terminé, et il peut commencer à communiquer en envoyant différents messages chiffrés avec la PTK, et avec le compteur qui s’incrémente, compteur qui joue le rôle de Nonce.

Le point d’accès quant à lui n’a pas reçu l’acquittement. Ainsi, pour lui, le 4 way handshake n’est pas complet. Après un certain timeout, il va donc renvoyer le 3ème message au client. Comme le client doit réinstaller la PTK suite à la réception du message 3, même s’il a terminé le 4 way handshake, il va recevoir une nouvelle fois ce 3ème message, et il va réinstaller la PTK (qui n’a pas changé) puis renvoyer un acquittement, pour enfin continuer de communiquer avec le point d’accès, en recommençant avec le compteur égal à celui du 3ème message, qu’il incrémente à nouveau pour la suite.

C’est ici que nous avons le soucis. De nouveaux messages vont être chiffrés et envoyés par le client, mais ils vont être chiffrés avec un Nonce qu’il a déjà utilisé. Et là, c’est le drame, toute la force cryptographique tombe, comme nous avons pu le voir rapidement dans le premier paragraphe. Il devient possible de décrypter des messages reçus par le client alors que nous n’avons pas la clé permettant de nous connecter au réseau, ce qui est exactement l’inverse du principe de WPA2.

Voici un petit schéma qui résume ce principe

Nous avons donc les clair_1, clair_2, clair_3 qui ont été chiffrés avec les Nonces r+2, r+3, r+4, puis suite à la réinstallation de la PTK, les clair_4, clair_5 ont été à nouveau chiffrés avec les Nonce r+3, r+4. Il ne faut alors plus longtemps pour casser le protocole cryptographique qui doit protéger les messages, comme vu dans le début de cet article.

En effet, dans cet exemple nous avons

msg_chiffré_2 = clair_2 XOR F(PTK, r+3)
msg_chiffré_4 = clair_4 XOR F(PTK, r+3)

Le même Nonce r+3 est utilisé pour chiffrer deux messages différents. Si nous connaissons clair_2 par exemple, nous pouvons réduire ces deux égalités à la suivante :

msg_chiffre_2 XOR clair_2 XOR msg_chiffré_4 = clair_4

Ainsi, sans connaissance de la clé PTK, nous pouvons déduire le clair_4.

Comment s’en protéger

Si vous avez bien compris le principe de l’attaque, vous devriez alors déjà imaginer différentes solutions pour se protéger de celle-ci. Il est possible de se protéger à deux niveaux.

Protection au niveau du point d’accès

[Edit 22/10/2017] Ce paragraphe explique une manière de protéger les clients en configurant le point d’accès, cependant l’attaquant peut rejouer manuellement le message 3 en incrémentant le compteur, ce qui aura tout de même pour effet de réinstaller la PTK et réinitialiser le compteur chez le client. Ainsi, je ne pense pas que la solution que j’avais proposée soit fonctionnelle. Par ailleurs, il existe plusieurs variantes de l’attaque, visant parfois les points d’accès, parfois les clients. Il convient alors de mettre à jour les deux acteurs.[/edit]

C’est la partie qui semble la plus efficace à protéger puisque si nous y arrivons, alors l’ensemble des clients qui se connecteront à ce point d’accès ne sont plus vulnérables. Cependant c’est également celle qui a le plus gros impact. L’attaque reposant sur le fait que le client ne réponde pas suite au message 3, et que le point d’accès renvoie ce message, il est possible de corriger le problème en décidant que si le point d’accès ne reçoit pas de réponse, alors celui-ci déconnecte le client. Le client devra alors recommencer un 4 way handshake afin de se connecter. C’est cependant un changement assez radical dans l’implémentation du protocole.

Protection au niveau du client

Il est également possible de faire en sorte que la procédure du client lors du 4 way handshake soit à états, c’est à dire que le client se souvienne des actions précédentes. Ainsi, s’il a déjà installé une clé, et que le point d’accès lui renvoie le message 3, alors le client peut tout à fait décider que sa clé est déjà installée, et que par conséquent il ne la réinstallera pas, et ne réinitialisera pas son compteur, utilisé comme Nonce pour le principe cryptographique. C’est la manière la plus propre de se protéger du problème, cependant cela implique qu’il faut changer le comportement de tous les clients.

Conclusion

J’espère que cet article vous permettra de mieux comprendre cette attaque, vraiment intéressante, qui m’a obligé à replonger dans beaucoup de domaines un peu flous pour moi, et de lire les normes associées afin d’éviter de dire trop de bêtises. Si vous avez des remarques ou des questions, n’hésitez surtout pas à me les poser en commentaires.

Je tenais également à dire merci à the_lsd pour ses explications sur plusieurs points et pour son approche du sujet.

Questionnements

[Edit 22/10/2017] J’ai finalement trouvé la réponse à ma question : Il faut utiliser la technique dite du channel-based Man-in-the-Middle décrite dans Advanced Wi-Fi Attacks Using Commodity Hardware [/edit]

Après avoir passé du temps sur la mise en place d’une preuve de concept, je ne vois pas comment procéder pour un maillon de la chaine d’attaque.

Afin que cette attaque fonctionne, il faut en théorie être l’intermédiaire entre le client et le point d’accès. Cependant, d’après ma compréhension, il n’est pas possible d’avoir ce rôle lors de l’authentification/association d’un client à un point d’accès.

En effet, la procédure complète pour pouvoir communiquer avec le point d’accès est la suivante

1. Probe Request de la part du client pour trouver des points d’accès compatibles (Destination ff:ff:ff:ff:ff:ff qui est l’adresse de broadcast);
2. Probe Response de la part de l’ensemble des points d’accès alentours qui sont compatibles avec les contraintes données par le client;
3. Authentification Request de la part du client vers un point d’accès (en utilisant son SSID et son adresse MAC pour qu’il se reconnaisse. SEQ 0x1);
4. Authentification Response de la part du point d’accès, en lui disant que c’est fait avec succès (SEQ 0x2);
5. Association Request de la part du client pour s’associer avec le point d’accès;
6. Association Response de la part du point d’accès pour valider l’association;
7. 4 way handshake pour du WPA2.

Si nous écoutons le réseau, nous voyons donc passer la Probe Request du client, la Probe Response, l’authentification et l’association. Nous savons donc avec quel point d’accès le client va communiquer. Nous avons les adresses MAC du client et du point d’accès.

Je ne vois pas en revanche comment nous pouvons “bloquer” des messages du client vers le point d’accès.

J’avais pensé à faire un rogue AP avec le même SSID mais une autre MAC. Ainsi, on ferait croire à l’AP que nous sommes le client, et au client que nous somme l’AP. Cependant, pour le calcul de la PTK, le client et l’AP n’aurons pas la même paire d’adresse MAC, donc leur PTK respectives ne seront pas les mêmes. Ce n’est donc pas une technique envisageable.

Pour cette raison, lorsque le client va communiquer avec le point d’accès, il enverra ses paquets à la bonne adresse MAC, et comme cela passe par le wifi, le point d’accès les prendra en compte quoiqu’on fasse. Je ne vois pas comment nous pouvons intercepter le message 4 du client pour que le point d’accès légitime ne le reçoive pas.

Une autre solution est de faire du Jamming, c’est à dire envoyer tout un tas de paquets inutiles en masse au point d’accès pour qu’il ne soit plus en mesure de répondre à qui que ce soit, y compris le client. Cela nous permet de prendre la place du point d’accès, mais pas d’être en MiTM. L’idée étant de laisser passer certains paquets pour que le point d’accès réponde, si nous faisons du jamming, il ne répondra tout simplement pas. Donc ce n’est pas non plus une solution possible, me semble-t-il.

Si vous avez compris cette partie de l’attaque, je serais ravi que vous m’expliquiez ce passage, par exemple dans les commentaires. :)

Plus de lecture

Pour se rapprocher de la vraie vie, je vous invite à consulter le mega thread reddit consacré à cette attaque pour avoir les patchs disponibles pour les différentes plate-formes.

Pour aller plus loin

J’ai fait ici une description un peu technique de l’attaque de résinstallation de clé lors du 3ème et 4ème message du 4 way handshake. Cependant, l’auteur du papier de l’attaque parle d’autres manières (similaires) d’attaquer un client, en se concentrant sur différents handhaskes. Je vous invite à lire son papier extrêmement intéressant pour avoir plus de détails, et les variantes de l’attaque décrites dans cet article.