La faille wifi KRACK pour les nuls

La faille KRACK (Key Reinstallation AttaCK) a été présentée au CSS en novembre 2017 à Dallas, par le binôme de chercheurs belges Frank Piessens et Mathy Vanhoef, de l’université de Louvain.

Cette faille a fait grand bruit dans le monde de la cybersécurité car elle entraîne une vulnérabilité concernant les liaisons wifi sécurisées en WPA2, qui non seulement étaient jusque là utilisées depuis une quinzaine d’années sans qu’aucune attaque ne soit connue, mais dont la sécurité avait été en plus prouvée formellement inviolable.

Cette faille est assez élaborée, ce qui explique peut-être pourquoi il est très difficile de trouver un article de vulgarisation, qui ne soit pas de trop haut niveau (type dépêche AFP), ni de trop bas niveau (il n’y a que les spécialistes qui comprennent). Je vais tenter de combler cette faille (si j’ose dire).

Avant d’expliquer comment fonctionne l’attaque, il est tout d’abord nécessaire de regarder comment se passe une connexion à un réseau wifi en dehors de toute attaque.

La connexion au wifi

Nous excluons ici les réseaux wifi ouverts (non sécurisés, comme ceux des gares ou des aéroports) ou réseaux d’entreprise. Nous nous intéressons uniquement aux réseaux dits “de particuliers” (comme celui que vous avez quand vous partagez en wifi la connexion 4G de votre téléphone, ou celui de votre livebox à la maison), sécurisés en WPA2.

Lorsqu’un “client” se connecte à un réseau wifi WPA2 offert par un “point d’accès”, il y a deux phases d’échanges : la phase d’association et la phase d’authentification. La phase qui nous intéresse est la phase d’authentification.

La phase d’authentification a pour but de faire en sorte que le client et le point d’accès se prouvent mutuellement qu’ils connaissent bien la clé du réseau wifi, sans jamais s’échanger cette clé, d’une part, et d’autre part de négocier une clé de session commune qui sera utilisée pour chiffrer tous les échanges ultérieurs à la phase d’authentification. Pour cela, le client et le point d’accès utilisent le 4 way-handshake, ou poignée de main en 4 temps en français.

La poignée de main en 4 temps (4 way handshake)

Le principe est le suivant. Sachant que le client et le point d’accès connaissent la clé du réseau (le mot de passe que vous mettez pour partager en wifi votre connexion Android) qu’on appelle PMK (Paiwise Master Key), et qu’ils doivent chacun prouver à l’autre qu’il connait cette clé sans jamais l’échanger :

1er temps : Le point d’accès envoie au client une série de chiffre (qu’on va appeler “nonce”) tirés au hasard. On nomme cette série de chiffres ANonce.

A la réception de ANonce, le client va lui aussi tirer au hasard une série de chiffres (qu’on va appeler SNonce) et va calculer une nouvelle clé, PTK (Pairwise Transcient Key) en dérivant la clé PMK, selon la formule PTK = PRF (PMK, ANonce, SNonce, Adresse MAC du client, Adresse MAC du point d’accès).

Rappelons que chaque équipement réseau possède une adresse physique, appelée adresse MAC (6 octets notés généralement XX:XX:XX:XX:XX:XX, dont les 3 premiers identifient le fabricant, et les 3 derniers sont uniques pour chaque fabricant), censée être unique au monde (censée car il est très facile avec des logiciels comme macchanger de prendre l’adresse MAC qu’on veut)

La formule exacte de PRF (Pseudo Random Function) a peu d’intérêt dans un article de vulgarisation. Sachez juste qu’elle produit un résultat de 384 ou 512 bits selon le protocole sélectionné (384 bits en WPA2/AES256, 512 bits en WPA/TKIP mais ce protocole n’est presque plus utilisé)

Ce qui est intéressant, c’est que le résultat de ce calcul (PTK donc) est ensuite coupé en plusieurs clés :

  • Les bits 0 à 127 vont être utilisés en tant que clé dite MIC ou MK (Master Key) de 128 bits
  • Les bits 128 à 255 vont être utilisés en tant que clé dite EK (Encryption Key) de 128 bits
  • Les bits 256 à 383 représentent la clé temporaire 1, ou TK1 (Transcient Key 1)
  • Et enfin, les bits 384 à 511, s’ils sont présents, représentent la clé temporaire 2 (TK2)

2ème temps : Le client envoie au point d’accès un message contenant SNonce, ce message est signé par la clé MIC (MK)

A la réception de ce message, le point d’accès a maintenant lui aussi tout ce qu’il faut pour calculer de son côté PTK = PRF (PMK, ANonce, SNonce, Adresse MAC du client, Adresse MAC du point d’accès), ainsi que les clés dérivées à savoir MIC/MK, EK, TK1 et TK2 si elle existe. Les résultats des calculs du point d’accès sont évidemment les mêmes que ceux du client. A ce stade, le point d’accès n’installe pas encore la PTK.

3ème temps : Le point d’accès envoie au client la GTK (Group Temporal Key), chiffrée par la clé EK et signée par la clé MIC (MK)

A la réception de ce message, le client déchiffre et authentifie la clé GTK et installe PTK et GTK.

4ème temps : Le client accuse réception auprès du point d’accès de la bonne réception de GTK

A la réception de ce message, le point d’accès installe PTK (GTK étant installée au démarrage du point d’accès) et à partir de là tous les échanges ultérieurs sont chiffrés.

Le 4 way handshake est terminé, les deux parties ont chacune prouvé qu’elles connaissaient PMK sans jamais l’échanger, et se sont mises d’accord sur un certain nombre de clés de chiffrement.

Figure 1 – Poignée de main à 4 temps, la partie basse montre ce qui se passe lorsque le point d’accès fait une mise à jour de la GTK et communique la nouvelle aux clients

La sécurité du système

Violer un tel système de sécurité n’est pas trivial, c’est le moins qu’on puisse dire. La sécurité de ce système a été, rappelons le, démontrée formellement.

Deux mesures de sécurité, dont nous n’avons pas encore parlé, sont intégrées au dispositif.

Premièrement, il est très difficile de monter une attaque de type man in the middle (avec un faux point d’accès situé au milieu et qui intercepterait/transmettrait les paquets entre le client et le point d’accès) car du fait de l’adresse MAC différente de ce faux point d’accès, il ne dériverait pas correctement la PTK

Deuxièmement, comme on peut le voir sur la figure 1, un “replay counter” (appelé r) est systématiquement intégré aux messages, empêchant un attaquant de rejouer des échanges passés. Si le point d’accès met r comme replay counter dans son message, la réponse du client contiendra aussi r, puis le point d’accès passe à r+1 pour son prochain message auquel le client répondra par un compteur lui aussi à r+1 et ainsi de suite.

Voyons concrètement ce qui se passe via une capture faite par Wireshark (un logiciel permettant de capturer les échanges réseaux) lorsque mon iPad se connecte au réseau WIfi partagé par mon smartphone Android.

Figure 2

On voit dans la partie haute que 4 paquets EAPOL sont échangés. Le premier paquet, figure 2, comporte bien ANonce (32 octets), un replay counter à 1, et aucune signature MIC.

Figure 3

Figure 3 : Le deuxième message, qui va de l’iPad vers le point d’accès, a lui aussi un replay counter à 1, comporte le SNonce de 32 octets et a une signature MIC. Dans la partie Data, le client informe le point d’accès des protocoles de chiffrement qu’il supporte.

Figure 4

Figure 4 : Le troisième paquet, qui va du point d’accès au client a un replay counter à 2, une signature MIC et une partie Data comportant la clé GTK chiffrée par la clés EK.

Figure 5

Figure 5 : le 4è message a un replay counter à 2, et ne comporte qu’une signature MIC. C’est un message ACK.

L’attaque KRACK

Comme je le disais au début, elle est assez compliquée et peut concerner soit la partie 4 way handshake, soit la partie Group Key handshake (voir figure 1). Pour être concis, on ne regardera que la partie 4 way handshake.

L’idée générale est de forcer la réinstallation de clés en se mettant en man in the middle et en empêchant le point d’accès de recevoir le message 4 du client.

Figure 6 – L’attaque sur la partie 4 way handshake

La figure 6 montre l’attaque. Le faux point d’accès attaquant est la ligne du milieu. On va l’appeler Mitm.

D’abord un mot sur cette position. On a vu plus haut qu’elle était en théorie très difficile à atteindre puisque les adresses MAC sont utilisées dans la dérivation. Les auteurs de l’attaque ont habilement contourné cette difficulté en créant un faux point d’accès ayant le même nom (SSID) mais sur une fréquence wifi (channel) différente et avec la même adresse MAC (via macchanger, l’outil qui permet de prendre l’adresse MAC qu’on veut). Ce faux point d’accès, si le client s’accroche dessus, est en Man in the middle et dispose de la bonne adresse MAC.

Mitm va transmettre sans les altérer les messages 1, 2 et 3, mais il va bloquer le message 4 envoyé au final par le client.

Le client, croyant que le point d’accès a reçu le message 4, va commencer son trafic chiffré. Ce trafic est intercepté par Mitm et non retransmis vers le point d’accès réel.

Celui-ci, ne voyant pas arriver le message 4, va ré-émettre le message 3 au bout d’un moment (avec un replay counter augmenté). Mitm peut choisir de renvoyer ce nouveau message 3 vers le client tout de suite ou attendre un peu pour capturer un maximum de messages chiffrés en provenance du client.

Quoi qu’il en soit, lorsque Mitm va envoyer le nouveau message 3 vers le client, celui va être perturbé. A partir de là, tout dépend de la manière avec laquelle la norme wifi a été implémentée dans le client :

  • Soit le client accepte ce nouveau message 3, auquel cas, il réinstalle les mêmes clés, c’est à dire qu’il va réinitialiser sa séquence de flux de chiffrement (sa clé de flux de chiffrement) et donc se mettre à chiffrer son trafic ultérieur en réutilisant le même flux de codage que précédemment, ce qui est une énorme faille de sécurité (on verra juste en dessous pourquoi). Certes, le nombre de messages différents codés avec le même flux de codage va être faible, mais il ne faut pas oublier que Mitm peut toujours envoyer à intervalle régulier des messages dits de “deauthentication”, qui obligent celui-ci à se déconnecter et rejouer le 4 way handshake et donc l’attaque est repartie pour un tour. Avec ces deux techniques cumulées, Mitm peut faire en sorte que le flux de codage soit réinitialisé et réutilisé pour pratiquement tout le trafic du client.
  • Soit le client n’accepte que les messages 3 chiffrés à ce stade (vu que les clés sont installées de son côté). Dans ce cas l’attaque est différente et se complexifie d’une manière qui dépasse le cadre d’un article de vulgarisation (l’attaquant s’en sort en comptant sur le temps de propagation qui existe entre la carte Wifi et le CPU, mais c’est impossible à expliquer de manière simple). C’est le cas de MacOS, Android et OpenBSD. A noter que les auteurs ont publié en octobre 2018 une mise à jour de leur papier expliquant qu’ils savaient maintenant se passer du temps de propagation carte wifi/CPU.
  • Soit le client réinstalle des clés ne contenant que des 00 ! Ce bug semble être lié à un paragraphe de la norme Wifi qui prête à confusion. Ce bug est présent dans un client wifi appelé wpa_supplicant et couramment utilisé sous Linux et Android, ce qui rend ces 2 OS particulièrement vulnérables à l’attaque KRACK (avant patch évidemment)

Venons en maintenant à la question de fond : pourquoi est-ce si grave de réutiliser le même flux de chiffrement ?

Les chiffrements par flux se font généralement par l’opération XOR (OU exclusif) entre le message en clair et une clé de flux (ie une suite pseudo aléatoire d’octets)

OCTET en clair XOR OCTET de clé = OCTET chiffré

Pour déchiffrer : OCTET chiffré XOR OCTET de clé (le même évidemment) = OCTET en clair

Et au niveau du flux, c’est pareil :

Message en clair XOR f(clé, indice) = Message chiffré

Message chiffré XOR f(clé, indice) = Message en clair

Indice vaut 1 pour le premier octet, 2 pour le 2è octet, etc.

Normalement quand on chiffre deux messages différents sans réinitialiser le flux de la clé (ie avec des indices différents), on a :

Message 1 en clair XOR f(clé, indice 1) = Message 1 chiffré

Message 2 en clair XOR f(clé, indice 2) = Message 2 chiffré

Tout va bien, le système est protégé.

Mais si un attaquant réussit à réinitialiser l’indice, et donc qu’on rechiffre avec le même flux, alors on obtient :

Message 1 en clair XOR f(clé, indice 1) = Message 1 chiffré

Message 2 en clair XOR f(clé, indice 1) = Message 2 chiffré

Ou dit autrement :

Message 1 en clair XOR constante = Message 1 chiffré

Message 2 en clair XOR constante = Message 2 chiffré

Il est alors facile de faire disparaître la constante de l’équation :

Message 1 en clair XOR Message 2 en clair = Message 1 chiffré XOR Message 2 chiffré

Donc, à partir du moment où l’on sait où telle page web a été consultée (Message 1 en clair connu) et qu’on a réussi à capturer le trafic chiffré (Message 1 chiffré, et Message 2 chiffré connus), il est facile de retrouver Message 2 en clair sans pourtant jamais avoir eu connaissance de la clé. Et si au final Message 2 en clair c’est un flux web sur lequel on a donné une information sensible comme un couple login/mot de passe ou un numéro de carte bleue, dommage (sauf bien sûr si l’on utilise un protocole de plus haut niveau chiffré, comme https).

Et ça, c’est pour les OS qui font une réinitialisation des indices. Pour ceux qui repartent carrément sur une clé dans laquelle tous les octets sont à 00, l’attaquant voit alors de base tout le trafic en clair.

Conclusion

Depuis que cette faille KRACK a été rendue publique, les fabricants ont eu le temps de proposer des correctifs. Sauf que depuis que la faille a été rendue publique, les auteurs de l’attaque l’ont aussi améliorée (voir ici) et aboutissent à la conclusion que de s’en protéger de manière sûre n’est en fait pas si simple. A chaque fois qu’on ferme une porte, ils arrivent à rentrer par la fenêtre.

L’autre point intéressant à noter est qu’alors que ce mécanisme a été formellement prouvé comme inviolable, l’implémentation qui en a été fait a souvent permis d’introduire des vulnérabilités.

On ne répétera jamais assez de faire les mises à jour régulièrement. Et de choisir des mots de passe robustes. En effet, et il faut en avoir conscience, quand bien même la faille KRACK serait fermée définitivement, que rien n’empêche un attaquant de capturer les messages 1 et 2 du 4 way handshake, récupérant ainsi ANonce et SNonce pour ensuite tenter de retrouver PTK en essayant des PMK jusqu’à trouver la bonne. Si le mot de passe PMK du point d’accès est bien choisi et robuste, cette recherche va prendre des milliards d’années. Mais si le mot de passe est 1234567 ou équivalent, la bonne PMK va être trouvée dans les 5 mn par une attaque par dictionnaire.

Voilà, j’espère être resté dans le domaine de la vulgarisation, mais moi-même j’ai des doutes 🙂

Alain QUEMENEUR

Tagués avec : ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Résoudre : *
13 + 6 =