Krack, la nouvelle faille impactant WPA2

Krack logo

État des lieux

Découverte de la faille « Krack »

Key Reinstallation Attacks ou Krack est le nom donné à la faille récemment découverte par Mathi VANHOEF, chercheur en sécurité à l’Université KU Leuven (Belgique). Il serait possible de déchiffrer ou d’injecter des paquets sur le protocole WPA2 (Wi-Fi Protected Access II) en exploitant cette faille. Injecter un paquet signifie que l’on envoie arbitrairement un paquet (déjà envoyé précédemment ou non) à un équipement sur le réseau. L’étude a été également menée par Domien SCHEPERS et Frank PIESSENS eux-mêmes chercheurs en sécurité dans la même université.

Pourquoi Krack fait le buzz ?

Aucun équipement se connectant au réseau Wi-Fi n’est épargné par Krack (Key Reinstallation Attacks). Le point fort de cette vulnérabilité est qu’elle exploite une faille dans la norme des protocoles Wi-Fi, le comportement même du client et du point d’accès est donc vulnérable. Cela rend la correction de la vulnérabilité plus complexe.

Tout d’abord, une petite piqûre de rappel, lorsqu’on se connecte à un point d’accès, le client et le serveur effectue des « handshakes ». Ces échanges permettent de vérifier si le client peut ou non se connecter/rester connecté au point d’accès. Pour valider ces échanges, une unique clé d’installation est nécessaire. À sa réception, le pair (point d’accès ou client, tout dépend de l’équipement attaqué) attend un « accusé de réception ». Si celui-ci ne parvient pas à son destinataire, on peut donc démarrer un nouveau handshake, empêcher l’accusé de réception de parvenir à son destinataire et ainsi forcer l’émetteur à réinstaller une clé d’installation.

L’idéal pour un attaquant est de pouvoir intercepter/manipuler les échanges entre le client légitime et son point d’accès. Pour ce faire, l’attaquant a besoin de se placer entre le client et le point d’accès, c’est ce qu’on appelle une attaque « Man in the Middle » (homme du milieu en français). Un attaquant obtenant ainsi une position de Man in the Middle pourrait injecter et déchiffrer des paquets réseaux, mettant à mal la confidentialité et l’intégrité des échanges. L’étendue des actions réalisables par les pirates varie en fonction des cas d’usage et des scénarios. Une telle attaque peut être ciblée (Krack nécessite d’être à proximité du point d’accès Wi-Fi), mais dès qu’un code d’exploitation stable sera publié les attaquants opportunistes ne pourront pas être exclus. [SPOILER ALERT] L’attaquant peut être un voisin, une personne dans une salle d’attente, sur le parking, etc. [/SPOILER ALERT]

Krack vient ébranler nos croyances en matière de robustesse du protocole WPA2, car aucune authentification n’est nécessaire pour exploiter la faille.

Historique sur des protocoles utilisant la norme Wi-Fi

Avant 2003, WEP était le protocole standard pour le Wi-Fi. En 2001, les vulnérabilités affectant ce protocole sont mises en évidence. WEP est vulnérable à des attaques sur le vecteur d’initialisation (IV). Ces attaques permettent de récupérer en moins de 5 minutes la clé de chiffrement s’il y a de l’activité sur le réseau. Dans le cas contraire, il est souvent possible de générer du trafic en injectant des paquets. L’intérêt est de récupérer un échantillon suffisamment important de paquets afin de retrouver la clé utilisée.

Devant de telles vulnérabilités, il était donc nécessaire d’instaurer un nouveau protocole. C’est ainsi que WPA a été instauré en urgence pour pallier la faiblesse de WEP. Malgré tout, le protocole « pansement » WPA est également vulnérable s’il utilise l’algorithme TKIP (Temporal Key Integrity Protocol) ou la technologie WPS. Il est possible de déchiffrer le contenu des petits paquets de données prévisibles si WPA utilise l’algorithme TKIP. La vulnérabilité affectant WPS quant à elle, est plus critique puisqu’il est possible de retrouver le code PIN en 11000 combinaisons.

C’est dans ce contexte que WPA2 est standardisé en 2004. Ce nouveau protocole était réputé fiable, devenant le standard de facto. Krack ne permet pas de retrouver la clé de chiffrement pour se connecter au point d’accès, contrairement aux failles présentes dans les précédents protocoles. Il est toutefois possible de déterminer la clé de chiffrement utilisée pour WPA2 si celle-ci est faible. Pour espérer s’associer avec le point d’accès en question, il faut tout d’abord capturer un handshake entre le client et le point d’accès. Néanmoins, on ne capture pas un seul handshake, mais 4 handshakes puisque le processus d’authentification utilisé entre le client et le point d’accès est le 4-Way Handshake. Ainsi pour casser la clé utilisée il est nécessaire de réaliser des attaques par dictionnaire pour recalculer les 4 handshakes. Si on récupère un 4-Way Handshake identique à celui capturé, alors nous avons retrouvé la clé utilisée. Vous l’avez compris, si votre clé ne figure pas dans le dictionnaire de l’attaquant alors il ne pourra pas pénétrer votre réseau Wi-Fi.

En revanche, une faille a été relevée en 2012 par Ahmad MD SOHAIL impactant WPA2. La faille nommée « Hole 196 » permet à un utilisateur connecté au point d’accès de réaliser des attaques Man in the Middle sur son réseau. Krack n’a cependant pas besoin d’être au préalable connecté.

Fonctionnement de Krack

Pour se connecter à un point d’accès via le protocole WPA2, le 4-Way Handshake est le standard. Le Fast Basic Service Set Transition (FT Handshake) quant à lui permet de maintenir la connexion d’un client de manière dynamique.

Les réseaux d’entreprises utilisent également le 4-Way Handshake et très souvent le FT Handshake.

Le 4-Way Handshake détermine si les périphériques cherchant à rejoindre un réseau Wi-Fi ont les bonnes informations d’identifications. Lorsque cela se produit le 4-Way Handshake est supposé produire une nouvelle clé de chiffrement. Krack profite de cela pour réutiliser une clé de chiffrement émise auparavant.

En effet, pour garantir la sécurité, la clé ne doit être installée et utilisée qu’une seule fois. Le protocole WPA2 ne garantit pas cette pratique.

La clé est installée après réception du message 3 du 4-Way Handshake. Néanmoins, le point d’accès va retransmettre le message 3 s’il n’a pas reçu une réponse appropriée. Le client peut donc recevoir plusieurs fois le message 3.

À chaque fois que c’est le cas, la même clé de chiffrement va être réinstallée et donc réinitialiser le nonce. Un nonce est un nombre unique pour la session établie entre le client et le point d’accès. L’attaquant peut forcer la réinitialisation des nonces en collectant et en rejouant les transmissions du message 3 du 4-Way Handshake. L’attaque utilise donc ce qu’on appelle du « nonce reuse ». Cela va permettre de rejouer, déchiffrer et/ou injecter des paquets réseau.

Schéma simplifié du 4-Way Handshake

Schéma simplifié d'une réinstallation de la clé lors du 4-Way Handshake

Cette même technique peut être utilisée pour attaquer les handshakes Group Key, PeerKey, Tunneled Direct-Link Setup (TDLS) et FT.

Si la victime utilise l’algorithme TKIP ou GCMP de WPA/WPA2 au lieu de AES-CCMP, la situation est aggravée, car l’attaquant peut à la fois déchiffrer, mais aussi injecter des paquets réseaux. Il est important de souligner que GCMP est actuellement en train de changer de nom pour « Wireless Gigabit (WiGig) » et est supposé être très utilisé ces prochaines années.

Quand on attaque le 4-Way Handshake on peut déchiffrer/injecter des paquets envoyés par le client. En revanche, si on attaque le FT Handshake, on peut déchiffrer/injecter des paquets envoyés au client. Rappelons cependant que ces attaques ne permettent pas de déterminer le mot de passe du point d’accès Wi-Fi.

L’impact est plus sévère sur les distributions Linux et Android. Ces systèmes font appel à une bibliothèque, néanmoins l’utilisation qu’est faite de celle-ci provoque la suppression de la clé de chiffrement de la mémoire une fois qu’elle a été installée une première fois. Donc si on retransmet une partie du handshake, le client va automatiquement réinstaller la clé. Ce comportement est apparu dans les versions 6.0+ d’Android, soit plus de 40% des Android sur le marché. Cela permet de réinstaller la clé composée uniquement de 0 et s’associer au pair Wi-Fi (point d’accès).

Dans une moindre mesure, Windows et Apple sont également touchés par Krack via le FT Handshake. La réinstallation de la clé ne peut avoir lieu que si le message 3 peut se retransmettre. Windows et iOS n’autorisent pas cette retransmission, ils ne sont donc pas vulnérables à Krack via le 4-Way Handshake. En revanche cela ne les protège pas d’un point d’accès corrompu via FT Handshake.

Il est important de préciser que Krack ne permet pas de passer outre le chiffrement supplémentaire de données (TLS).

Krack peut s’attaquer soit à un client soit à un routeur. Cela implique donc qu’un client à jour est tout de même sujet à subir une attaque Krack s’il se connecte à un routeur vulnérable.

Les routeurs sont vulnérables s’ils ne sont pas mis à jour et s’ils supportent le FT Handshake. Ce handshake fait partie du standard 802.11r qui est principalement supporté par les réseaux d’entreprises et non ceux des particuliers.

Comment vérifier si mon point d’accès est vulnérable ?

Les chercheurs n’ont pas rendu public le code source de l’exploit, afin de retarder l’exploitation de cette faille et donner aux éditeurs et constructeurs le temps de la corriger.

En revanche, un script est mis à disposition par Mathi VANHOEF pour tester si un point d’accès est vulnérable.

Le script du chercheur peut être trouvé sur son dépôt github :

https://github.com/vanhoefm/krackattacks-test-ap-ft

Un guide complet a été réalisé par un membre de la communauté afin de tester ce script :

http://rootsaid.com/krack-test/

Kismet est également un outil qui permet de détecter en temps réel les tentatives de Krack sur notre point d’accès. L’outil remonte des alertes via une interface Web. Ce dernier est également disponible sur github :

https://github.com/kristate/krackinfo

Un autre guide a également vu le jour pour présenter cet outil :

http://rootsaid.com/kismet-krack-test/

Un membre de la communauté propose une « preuve de concept » (PoC ou Proof-of-Concept) de Krack. Le PoC est pour le moment instable, mais permet d’appréhender un peu plus le fonctionnement de la vulnérabilité :

https://github.com/Hackndo/krack-poc

Recommandations

De nombreux patchs ont déjà vu le jour, il est recommandé de les appliquer, un membre de la communauté recense les différents patchs sur ce répertoire Github :

https://github.com/kristate/krackinfo

Les utilitaires wpa_supplicant et hostapd se sont vus corrigés. wpa_supplicant s’occupe de l’authentification avec le point d’accès, tandis que hostapd permet de créer des points d’accès et de les gérer. Il suffit de mettre à jour les clients Linux. En revanche les points d’accès sont plus compliqués à mettre à jour, les attaques Krack via FT handshake sont donc probables.

Malgré le fait que WPA2 soit vulnérable en l’absence de patch, il n’est pas recommandé de choisir un des autres protocoles (WPA, WEP) qui ne maintiennent pas un niveau de sécurité suffisant. WPA2 reste le standard pour les communications Wi-Fi.

Il est conseillé d’utiliser l’algorithme AES-CCMP (Counter Mode Cipher Block Chaining Message Authentication Code Protocol) qui ne permet à Krack « que » de rejouer et déchiffrer les paquets, mais pas d’en créer pour les injecter contrairement à TKIP et GCMP (Galois Counter Mode Protocol).

Il est également possible de désactiver le FT Handshake et la fonctionnalité cliente (où le point d’accès se connecte en tant que client à un autre point d’accès) et sur les points d’accès afin de ralentir les attaques contre ces derniers.

Vous pouvez utiliser un Virtual Private Network (VPN) ou vous connecter via Ethernet pour vous mettre à l’abri d’une attaque Krack. Si vous choisissez d’utiliser une connexion Wi-Fi et donc d’opter pour un VPN, il faut que celui-ci soit en « Client-to-Site », assurant que l’intégralité du trafic IP est chiffrée, depuis le poste de travail, jusqu’au point de sortie du VPN. L’attaquant ne pourra donc rien faire des données qu’il intercepte. Par ailleurs, mettre à jour un client ne suffit pas, l’AP peut lui être toujours vulnérable. Les deux pairs Wi-Fi doivent disposer d’un correctif pour assurer l’intégrité et la confidentialité des échanges.

Tests d’intrusion Wi-Fi

L’équipe Audit Technique de Digitemis réalise des tests d’intrusion sur des réseaux sans fil d’entreprise. Ces tests visent à évaluer le niveau global de sécurité de ces infrastructures face à des vulnérabilités comme Krack, mais aussi des failles affectant les équipements (routeur, point d’accès, etc.) et applications (portail captif, serveur RADIUS, etc.). Nous simulons ainsi le comportement d’un attaquant cherchant à s’introduire sur le réseau ou à intercepter et écouter les communications (boîte noire). Ces tests sont souvent complémentés par une phase d’évaluation du niveau d’étanchéité entre les réseaux gérés par les points d’accès Wi-Fi (boîte grise) : entre le réseau « invité » et le réseau interne, entre deux réseaux internes, etc.

La première phase de tests est réalisée en boîte noire depuis le poste d’un de nos auditeurs. Durant ces opérations, celui-ci cherche à capturer et déchiffrer le trafic réseau, contourner ou affaiblir les phases d’authentification pour obtenir un accès illégitime. Une attention particulière est portée à la robustesse des protocoles (WEP, WPA, WPS) et des algorithmes assurant la confidentialité et l’authenticité des échanges.

Lors de la phase en boîte grise, l’auditeur dispose de comptes utilisateurs lui permettant d’accéder aux réseaux Wi-Fi. À l’aide des outils adaptés, il évalue notamment :

  • Les possibilités de rebond entre les réseaux ;
  • Le niveau de sécurité des équipements de routage et d’administration ;
  • La robustesse du chiffrement et tente d’intercepter et déchiffrer le trafic des autres utilisateurs.

Il est également possible d’étendre le type de scénario simulé grâce à la fourniture d’un poste utilisateur préconfiguré (avec un compte Wi-Fi). L’obtention de ce poste permet simuler de la perte ou du vol d’un équipement nomade. L’auditeur peut alors réaliser des tests visant à évaluer la possibilité d’extraire et réutiliser ces informations pour se connecter frauduleusement au réseau.

Article réalisé par Romain KOSZYK et Marc LEBRUN.

Bibliographie

Discovering Logical Vulnerabilities in the Wi-Fi Handshake Using Model-Based Testing, étude de Mathy Vanhoef, Domien Schepers et Frank Piessens, PDF consulté le 17/12/2017

Key Reinstallation Attacks : Forcing Nonce Reuse in WPA2, étude de Mathy Vanhoef et Frank Piessens,   PDF consulté le 17/12/2017

Key Reinstallation Attacks, Breaking WPA2 by forcing nonce reuse, Mathy Vanhoef, site officiel de KRACK, site consulté le 17/12/2017

Github contenant le script de test Krack du chercheur, Mathy Vanhoef, Github, répertoire consulté le 17/12/2017

Github contenant l’outil Kismet, dragorn, Github, répertoire consulté le 17/12/2017

Github contenant un état des lieux des différents patchs, kristate, Github, répertoire consulté le 17/12/2017

Github contenant un PoC de Krack, Hackndo, Github, répertoire consulté le 19/12/2017

KISMET – KRACK Test in Kali-Linux, Root Said, Root Said, site consulté le 17/12/2017

« KRACK Vulnerability Test – Test your WIFI router for KRACK (FT) », Root Said, Root Said, site consulté le 17/12/2017 sur http://rootsaid.com/krack-test/

« KRACK – Casser le WPA2 », Hackndo, Hackndo, site consulté le 19/12/2017 sur http://beta.hackndo.com/krack/

« What is the WPA2 Krack attack and how can I tell if my network is vulnerable? », George Harrison, The Sun, site consulté le 17/12/2017 sur https://www.thesun.co.uk/tech/4696036/wpa2-krack-attack-wifi/

« Here’s every patch for KRACK Wi-Fi vulnerability available right now », Charlie Osborne et Zack Whittaker, Zero Day, site consulté le 17/12/2017 sur http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/

« Kali on KRACK », Johnny Long, Kali-Linux, site consulté le 17/12/2017 sur https://www.kali.org/news/kali-on-krack/

« KRACK WPA2 Wi-Fi exploit already fixed in iOS, macOS, tvOS, watchOS betas », Rene Ritchie, iMore, site consulté le 17/12/2017 sur https://www.imore.com/krack-wpa2-wi-fi-exploit-already-fixed-ios-macos-tvos-watchos-betas

« KRACK WPA2 protocol Wi-Fi attack: How it works and who’s at risk », James Sanders, TechRepublic, site consulté le 17/12/2017 sur https://www.techrepublic.com/article/krack-wpa2-protocol-wi-fi-attack-how-it-works-and-whos-at-risk/

« Krack : cette faille majeure qui menace le Wi-Fi », Mathieu Chartier, Les Numériques, site consulté le 17/12/2017 sur https://www.lesnumeriques.com/informatique/wi-fi-protocole-securite-wpa2-a-ete-hacke-n67389.html

« Krack : 5 questions sur la faille critique qui menace la sécurité du Wi-Fi », Julien Lausson, Numerama, site consulté le 17/12/2017 sur http://www.numerama.com/tech/298172-krack-questions-sur-la-faille-critique-qui-menace-la-securite-wpa2-des-reseaux-wi-fi.html

« Tout ce que vous devez savoir sur la faille de sécurité majeure des réseaux Wi-Fi ! », Stéphanie Schmidt, Trust My Science, site consulté le 17/12/2017 sur http://trustmyscience.com/tout-ce-que-vous-devez-savoir-sur-la-faille-de-securite-wi-fi-krack/

« Wi-Fi Protected Access (WPA) handshake traffic can be manipulated to induce nonce and session key reuse », Vulnerability Notes Database, Vulnerability Notes Database, site consulté le 17/12/2017 sur https://www.kb.cert.org/vuls/id/228519/

Je partage

Derniers articles

Illustration de sécurité WordPress avec logo central et éléments numériques de sécurité

Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur

Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !

Lire l'article

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article