Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
macstealer — MacStealer : Contournement de l'isolation des clients Wi-Fi | Kitploit
Outils/GitHubGitHub/vanhoefm/macstealer
Audit Wi-FiAnalyse des VulnérabilitésExploitationCollecte d'InformationsSécurité RéseauSécurité Sans FilTests d'IntrusionRed Teaming
GitHubvanhoefm/macstealer

macstealer

MacStealer : Contournement de l'isolation des clients Wi-Fi

Voir le dépôt
5526024il y a 9 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
Site web

MacStealer : contournement de l'isolation des clients Wi-Fi

1. Introduction

Ce dépôt contient MacStealer. Il permet de tester les réseaux Wi-Fi pour les contournements de l'isolation des clients (CVE-2022-47522). Notre attaque peut intercepter (voler) le trafic destiné à d'autres clients au niveau de la couche MAC, même si les clients sont empêchés de communiquer entre eux. Cette vulnérabilité affecte les réseaux Wi-Fi avec des initiés malveillants, où notre attaque peut contourner l'isolation des clients, parfois également appelée isolation AP. L'attaque peut également être utilisée pour contourner l'inspection ARP dynamique (DAI), et peut probablement aussi être utilisée pour contourner d'autres méthodes qui empêchent les clients de s'attaquer mutuellement. L'attaque est également connue sous le nom d'attaque de substitution de contexte de sécurité (security context override attack), voir la section 5 de notre article USENIX Security '23 (dépôt).

Des exemples concrets de réseaux potentiellement affectés sont :

  • Les réseaux d'entreprise où les utilisateurs peuvent se méfier les uns des autres, et où des techniques telles que l'isolation des clients ou l'inspection ARP sont utilisées pour empêcher les utilisateurs de s'attaquer mutuellement. Par exemple, les réseaux d'entreprise avec des comptes pour les invités et le personnel, des réseaux comme eduroam et govroam, etc.

  • Les points d'accès publics protégés par Passpoint (anciennement Hotspot 2.0). Ce sont des points d'accès auxquels vous pouvez vous connecter automatiquement et en toute sécurité. Par exemple, il peut vous authentifier de manière transparente en utilisant la carte SIM de votre téléphone.

  • Les réseaux domestiques WPA2 ou WPA3 avec l'isolation des clients activée. Cela inclut les réseaux avec un SSID séparé pour les invités ou pour les appareils (IoT) non sécurisés. Cela inclut également les réseaux où plusieurs mots de passe sont utilisés pour isoler davantage les appareils, également connus sous le nom de Multi-PSK, Identity PSK, per-station PSK, ou EasyPSK. Voir la discussion sur le modèle de menace pour plus d'informations.

  • Les points d'accès publics basés sur WPA3 SAE-PK. Ce sont des points d'accès protégés par un mot de passe public partagé, mais où un adversaire ne peut pas abuser de ce mot de passe public.

Nous notons que notre attaque ne peut pas contourner les VLANs. En d'autres termes, d'après les expériences actuelles, notre attaque ne peut pas être utilisée pour exploiter un appareil dans un autre VLAN.

Le dépôt des autres résultats de notre article USENIX Security '23 est également disponible.

2. Détails de la vulnérabilité

L'idée centrale de l'attaque est que la manière dont les clients sont authentifiés n'a aucun lien avec la façon dont les paquets sont routés vers le bon client Wi-Fi. En effet, l'authentification est effectuée sur la base de mots de passe, de noms d'utilisateur, d'identités 802.1X et/ou de certificats, mais une fois que le client est connecté, le routage des paquets est effectué sur la base des adresses MAC. Un initié malveillant peut abuser de cela pour intercepter des données destinées à un client Wi-Fi en déconnectant une victime puis en se connectant sous l'adresse MAC de la victime (en utilisant les identifiants de l'adversaire). Tous les paquets encore en route vers la victime, comme les données d'un site web que la victime était encore en train de charger, seront désormais reçus par l'adversaire à la place.

Plus précisément, l'attaque se compose de trois étapes :

  1. Laisser la victime demander des données : L'adversaire attend d'abord que la victime (client) établisse une connexion Wi-Fi avec le point d'accès (AP) vulnérable. Nous supposons que la victime enverra ensuite une requête à un serveur sur Internet. Par exemple, la victime peut envoyer une requête HTTP au site web (en clair) example.com. L'objectif de l'adversaire est d'intercepter la réponse qui sera envoyée par le site web.

  2. Se connecter sous l'adresse MAC de la victime : Une fois que la victime a demandé des données, par exemple en envoyant un paquet de requête HTTP, l'adversaire déconnectera de force la victime du réseau avant que la réponse n'arrive au point d'accès vulnérable. Dans notre exemple, cela signifie que la victime est déconnectée avant que la réponse de example.com n'arrive au point d'accès. Une fois la victime déconnectée, l'adversaire usurpe l'adresse MAC de la victime et se connectera au réseau en utilisant ses propres identifiants. Cela signifie que l'adversaire est un initié malveillant qui peut se connecter au réseau avec ses propres identifiants, par exemple en utilisant son propre nom d'utilisateur et mot de passe dans un réseau Wi-Fi d'entreprise.

  3. Intercepter la réponse : Une fois que l'adversaire s'est connecté sous l'adresse MAC de la victime, le point d'accès associera les nouvelles clés de chiffrement générées par l'adversaire à l'adresse MAC de la victime. Par conséquent, lorsque la réponse du serveur arrive au réseau Wi-Fi, ou tout trafic entrant destiné à la victime en général, le routeur transférera ces paquets entrants à l'adresse MAC de la victime. Dans notre exemple, cela signifie que la réponse de example.com est transférée par le routeur à l'adresse MAC de la victime. Cependant, l'adversaire utilise désormais cette adresse MAC. Cela signifie que le point d'accès chiffrera la réponse en utilisant les clés de l'adversaire. En d'autres termes, l'adversaire recevra désormais tout trafic en attente encore en route vers la victime.

Nous notons que le trafic intercepté peut être protégé par un chiffrement de couche supérieure, tel que TLS et HTTPS. Néanmoins, même si un chiffrement de couche supérieure est utilisé, notre attaque révèle toujours l'adresse IP avec laquelle une victime communique. Cela révèle à son tour les sites web qu'une victime visite, ce qui peut être des informations sensibles en soi.

Par défaut, l'attaque n'intercepte pas le trafic envoyé par la victime, mais ne peut intercepter que le trafic envoyé vers la victime. Cependant, un adversaire peut tenter des attaques ultérieures pour intercepter également le trafic envoyé par la victime. En particulier, en interceptant une réponse DNS destinée à la victime, l'adversaire peut usurper une réponse DNS et intercepter tout le trafic IP à la fois envoyé vers la victime et envoyé par la victime.

Effectuer l'attaque ci-dessus n'a de sens que lorsque l'isolation des clients est activée sur le réseau cible. Sinon, si l'isolation des clients est désactivée, un initié malveillant peut simplement attaquer directement d'autres clients en utilisant des techniques telles que l'usurpation ARP (voir les tests d'isolation des clients).

L'attaque est identique contre les réseaux d'entreprise WPA1, WPA2 et WPA3. Cela vient du fait que l'attaque n'exploite aucune propriété cryptographique du Wi-Fi, mais abuse plutôt de la manière dont un réseau détermine à quel client les paquets doivent être envoyés, c'est-à-dire routés.

Pour plus de détails sur l'attaque, voir l'attaque de substitution de contexte de sécurité (section 5) dans notre article Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues.

3. Contre-mesures possibles

3.1. Empêcher le vol d'adresse MAC

Pour atténuer notre attaque, un point d'accès peut temporairement empêcher les clients de se connecter s'ils utilisent une adresse MAC qui a été récemment connectée au point d'accès. Cela empêche un adversaire d'usurper une adresse MAC et d'intercepter les trames en attente ou en file d'attente destinées à une victime. Lorsqu'il peut être garanti que l'utilisateur derrière une adresse MAC n'a pas changé, le client peut être autorisé à se reconnecter immédiatement. Notez que cette vérification doit être effectuée sur tous les points d'accès qui font partie du même système de distribution, et plus précisément, sur tous les points d'accès entre lesquels les clients peuvent effectuer un roaming tout en conservant leur adresse IP actuelle.

3.1.1. Lors de l'utilisation de phrases de passe partagées

Pour reconnaître de manière sécurisée les utilisateurs récemment connectés, un point d'accès peut stocker une correspondance entre l'adresse MAC d'un client et ses associations de sécurité mises en cache (par exemple, son PMK mis en cache). Un client peut être autorisé à se (re)connecter immédiatement sous une adresse MAC récemment utilisée en prouvant qu'il possède l'association de sécurité mise en cache liée à cette adresse MAC, par exemple en se connectant avec le PMK mis en cache correct.

Lors de l'utilisation de multi-PSK, également connu sous le nom de per-station PSK ou Identity PSK, le point d'accès peut conserver une correspondance entre les adresses MAC récemment connectées et le mot de passe (unique) qu'elles ont utilisé. Lorsqu'un client se connecte, le point d'accès vérifie si son adresse MAC a été récemment utilisée. Si ce n'est pas le cas, ou si c'est le cas et que le client utilise le même mot de passe qu'auparavant, le client peut se connecter normalement. Cependant, si la même adresse MAC est utilisée avec un mot de passe différent, le client est obligé d'attendre une durée prédéfinie avant de pouvoir se connecter avec succès.

Lors de l'utilisation de SAE-PK pour sécuriser les points d'accès publics, la seule méthode que nous connaissons pour reconnaître de manière sécurisée qu'une adresse MAC est réutilisée par le même utilisateur qu'auparavant consiste à s'appuyer sur les associations de sécurité mises en cache (par exemple, le PMK mis en cache lié à l'adresse MAC).

Les défenses ci-dessus supposent qu'après un certain délai, plus aucun paquet en attente n'arrivera pour la victime. Pour éviter les fuites au-delà de ce délai, les clients peuvent utiliser un chiffrement de bout en bout (tel que TLS) avec les services avec lesquels ils communiquent.

3.1.1. Lors de l'utilisation de l'authentification 802.1X et des extensions RADIUS

Lors de l'utilisation d'une authentification 802.1X basée sur EAP, une autre méthode, meilleure, pour reconnaître de manière sécurisée les utilisateurs récemment connectés repose sur l'identité EAP qu'ils ont utilisée pendant l'authentification 802.1X. Un point d'accès peut apprendre de manière sécurisée l'identité EAP à partir du serveur RADIUS qui a authentifié le client, et peut conserver une correspondance entre les adresses MAC récemment connectées et leur identité EAP correspondante. Lorsqu'un client se connecte, le point d'accès vérifie si son adresse MAC a été récemment utilisée. Si ce n'est pas le cas, ou si c'est le cas et que le client utilise la même identité EAP qu'auparavant, le client peut se connecter normalement. Cependant, si la même adresse MAC est utilisée avec une identité EAP différente, le client est obligé d'attendre une durée prédéfinie avant de pouvoir se connecter avec succès.

L'un des défis est que le point d'accès peut ne pas toujours connaître l'identité 802.1X d'un client en raison de préoccupations liées à la confidentialité. Par exemple, ces informations peuvent n'être disponibles qu'au niveau du serveur AAA du domaine d'origine, et le point d'accès ne recevra du serveur RADIUS qu'une identité d'utilisateur facturable (Chargeable User Identity). Cette identité ne permet pas au point d'accès de reconnaître deux associations du même appareil/des mêmes identifiants car sa valeur peut changer constamment. Le point d'accès reçoit néanmoins l'identité anonyme dans la réponse EAP-Response/Identity, telle que anonymous@realm, et peut s'appuyer sur celle-ci pour reconnaître au moins les utilisateurs de différents domaines.

Pour empêcher les utilisateurs d'un même domaine de s'attaquer mutuellement, sans révéler l'identité d'un client au point d'accès, une coopération et des modifications du serveur RADIUS sont nécessaires. En particulier, le serveur RADIUS peut être mis à jour pour aider à détecter si l'adresse MAC a été récemment utilisée par un autre utilisateur du même domaine (dans le réseau local donné). Le serveur RADIUS devrait alors être informé lorsqu'un client se déconnecte, afin de savoir quand une adresse MAC a été utilisée pour la dernière fois par l'un de ses utilisateurs, et doit être informé de l'adresse MAC de tout client qui tente de se connecter.

Une dernière remarque est que, bien que cette approche reposant sur l'identité EAP empêche différents utilisateurs de s'attaquer mutuellement, elle n'empêcherait pas un appareil compromis d'attaquer un autre appareil du même utilisateur. Autrement dit, les attaques ne seraient empêchées qu'entre différents utilisateurs, mais pas entre différents appareils d'un même utilisateur.

3.2. Protéger l'adresse MAC de la passerelle

Il est important de noter que notre attaque ne se limite pas à intercepter les paquets destinés aux clients Wi-Fi. Un adversaire pourrait également tenter de s'associer avec l'adresse MAC d'une passerelle par défaut ou d'un autre serveur du réseau local. Pour empêcher de telles attaques, le point d'accès ou le contrôleur peut interdire aux clients d'utiliser une adresse MAC égale à celle de la passerelle par défaut. Plus généralement, la détection des adresses MAC en double peut être utilisée lorsqu'un client Wi-Fi se connecte au réseau, afin d'empêcher les clients Wi-Fi d'utiliser une adresse MAC également utilisée par d'autres appareils du réseau.

3.3. Protection des trames de gestion (802.11w)

L'utilisation de la protection des trames de gestion (MFP) rendrait l'attaque plus difficile mais pas impossible. Dans des travaux antérieurs, nous avons trouvé quelques moyens par lesquels les clients peuvent être déconnectés/désauthentifiés même lorsque la MFP est utilisée. Sur la base de cette expérience, il semble toujours exister une méthode pour déconnecter de force un client du réseau, même lorsque la MFP est utilisée. Autrement dit, il est difficile d'empêcher complètement les attaques de déconnexion et de désauthentification. Cela dit, la MFP constituerait un obstacle supplémentaire à surmonter lors de l'exécution de l'attaque en pratique, elle peut donc être une contre-mesure utile pour rendre l'attaque plus difficile (mais pas impossible) en pratique.

3.4. Utilisation des VLANs

D'après des expériences préliminaires, l'attaque ne fonctionne pas à travers différents VLANs. En d'autres termes, l'initié malveillant qui exécute l'attaque doit se trouver dans le même VLAN que la victime. Une contre-mesure consiste donc à placer différents groupes d'utilisateurs dans différents VLANs. Cependant, un initié malveillant serait toujours en mesure d'exécuter l'attaque (c'est-à-dire de contourner l'isolation des clients) contre d'autres utilisateurs du même VLAN.

Notez que lors de l'utilisation de multi-PSK (c.-à-d. per-station PSK ou identity PSK), vous pouvez placer les clients dans différents VLANs en fonction du mot de passe qu'ils utilisent. En d'autres termes, vous pouvez utiliser un VLAN pour chaque mot de passe. Cela empêche les clients ayant des mots de passe différents de s'attaquer mutuellement.

4. Prérequis de l'outil

L'outil MacStealer fonctionne avec toute carte réseau prise en charge par Linux. Nous avons testé MacStealer sur Ubuntu 22.04. Pour installer les dépendances requises sur Ubuntu 22.04, exécutez :

root@kitploit:~
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
	libdbus-1-dev git pkg-config build-essential net-tools python3-venv \
	aircrack-ng rfkill

Clonez maintenant ce dépôt, compilez les outils et configurez un environnement virtuel python3 :

root@kitploit:~
git clone https://github.com/vanhoefm/macstealer.git macstealer
cd macstealer/research
./build.sh
./pysetup.sh

Les instructions ci-dessus ne doivent être exécutées qu'une seule fois.

Après avoir récupéré du nouveau code avec git, vous devez exécuter à nouveau ./build.sh et ./pysetup.sh. Voir le journal des modifications pour un aperçu détaillé des mises à jour de MacStealer depuis le début de la divulgation coordonnée.

5. Avant chaque utilisation

5.1 Environnement d'exécution

Chaque fois que vous souhaitez utiliser MacStealer, vous devez d'abord charger l'environnement virtuel python3 en tant que root. Cela peut être fait en utilisant :

root@kitploit:~
cd research
sudo su
source venv/bin/activate

Vous devez maintenant désactiver le Wi-Fi dans votre gestionnaire de réseau afin qu'il n'interfère pas avec MacStealer. Vous pouvez éventuellement vérifier avec sudo airmon-ng check pour voir quels autres processus pourraient utiliser la carte réseau sans fil et interférer avec MacStealer.

5.2. Configuration du réseau

L'étape suivante consiste à modifier client.conf avec les informations du réseau que vous souhaitez tester. Il s'agit d'une configuration pour wpa_supplicant qui doit contenir deux blocs réseau : un représentant la victime et un représentant l'attaquant. Un exemple de fichier de configuration pour tester le réseau fictif kuleuven est :

root@kitploit:~
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test: fill in properties of the network to test
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Victim login: fill in login credentials representing the victim
	identity="[email protected]"
	password="SuperSecret"
}

network={
	# Don't change this field, the script relies on it
	id_str="attacker"

	# Network to test: you can copy this from the previous block
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Attacker login: fill in login credentials representing the attacker
	identity="[email protected]"
	password="SomePassword"
}

Dans la partie « network to test », vous devez fournir le nom du réseau testé et sa configuration de sécurité. Voir wpa_supplicant.conf pour la documentation sur la façon d'écrire/modifier les fichiers de configuration et pour des exemples de blocs réseau pour différents types de réseaux Wi-Fi. Dans le premier bloc réseau, sous « victim login », vous devez spécifier des identifiants de connexion valides représentant la victime simulée. Dans le deuxième bloc réseau, vous pouvez fournir exactement les mêmes informations sous « network to test », mais vous devez fournir des identifiants de connexion représentant l'attaquant simulé.

Dans l'exemple ci-dessus, MacStealer testera une attaque où l'adversaire est [email protected] et cet adversaire tentera d'intercepter le trafic envoyé vers la victime [email protected].

Par défaut, le script utilise le fichier de configuration client.conf. Vous pouvez utiliser un autre fichier de configuration en fournissant le paramètre --config network.conf, où vous pouvez remplacer network.conf par le fichier de configuration que vous souhaitez utiliser.

Ce dépôt contient également les fichiers de configuration d'exemple suivants :

  • multipsk.conf : Un fichier de configuration pour tester un réseau qui utilise multi-PSK où un mot de passe est utilisé par les appareils de confiance et un second mot de passe est donné aux invités.

  • saepk.conf : Un fichier de configuration pour tester un point d'accès public qui utilise SAE-PK.

Notez qu'il est également possible de modifier le ou les blocs réseau pour tester un AP/BSS spécifique.

5.3. Configuration du serveur

Par défaut, MacStealer enverra un paquet TCP SYN à 8.8.8.8 sur le port 443 dans tous les tests, ce qui correspond à un serveur DNS de Google. Si vous souhaitez utiliser un autre serveur ou port, vous pouvez en fournir un à l'aide du paramètre --server. Par exemple :

root@kitploit:~
./macstealer.py wlan0 --server 208.67.222.222

Vous pouvez également ajouter le port qui doit être utilisé dans les paquets TCP SYN :

root@kitploit:~
./macstealer.py wlan0 --server 208.67.222.222:80

Remplacez wlan0 par le nom de votre interface Wi-Fi et l'adresse IP par le serveur que vous souhaitez utiliser. Ce serveur doit retransmettre les réponses TCP SYN/ACK et devrait, idéalement, envoyer un SYN/ACK retransmis plus de 10 secondes après que MacStealer a transmis le SYN TCP initial. Vous pouvez tester ce comportement de retransmission à l'aide du paramètre --ping comme suit :

root@kitploit:~
./macstealer.py wlan0 --server 208.67.222.222 --ping

MacStealer affichera ce qui suit si le serveur a le comportement de retransmission requis :

root@kitploit:~
[22:53:15] Received SYN/ACK 15.265095233917236 seconds after sending SYN.
[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.

Si le serveur fourni n'envoie pas de réponses TCP SYN/ACK, ou ne les retransmet pas assez tardivement, MacStealer affichera ce qui suit :[22:52:05] Received SYN/ACK 1.0727121829986572 seconds after sending SYN. [22:52:24] >>> Ping test done. Consider using a server that retransmits SYN/ACK for a longer time.

La raison pour laquelle le serveur doit continuer à retransmettre un SYN/ACK après plus de 10 secondes est qu'il peut parfois falloir plusieurs secondes pour se reconnecter en tant qu'attaquant simulé. Ce processus de reconnexion doit être terminé avant que le serveur n'envoie le dernier paquet TCP SYN/ACK retransmis.

6. Test des vulnérabilités

Le tableau suivant contient les commandes courantes que vous exécuterez lors du test d'un réseau ainsi qu'une brève description de ce que fait chaque commande. Sous le tableau, les détails de chaque commande sont expliqués.

Si le réseau testé utilise la protection des trames de gestion (802.11w), l'outil suppose que l'adversaire peut toujours déconnecter de force la victime du réseau. Cette hypothèse est basée sur des recherches récentes qui ont montré que les attaques par déconnexion sont généralement toujours possibles, bien que moins simples ou générales, lorsque la MFP est utilisée.

6.1. Vérifications préliminaires

Avant de tester les vulnérabilités, vous pouvez utiliser les deux commandes suivantes pour confirmer que MacStealer peut se connecter au réseau en tant que victime et en tant qu'attaquant :

  • ./macstealer.py wlan0 --ping : se connecte au réseau en utilisant les identifiants de la victime. Une fois connecté, un SYN TCP est envoyé au serveur (qui est par défaut 8.8.8.8 et peut être modifié). MacStealer vérifiera si le SYN/ACK est retransmis et combien de fois. Vous pouvez utiliser cette commande pour confirmer que les identifiants de la victime sont corrects et que le serveur configuré retransmet correctement les réponses SYN/ACK.

  • ./macstealer.py wlan0 --ping --flip : identique au test ci-dessus, mais le script se connectera en utilisant les identifiants de l'adversaire. Vous pouvez l'utiliser pour confirmer que les identifiants de l'adversaire sont corrects.

6.2. Tests de vulnérabilité (CVE-2022-47522)

  • ./macstealer.py wlan0 : test de la variante par défaut de l'attaque par vol d'adresse MAC. L'attaquant se reconnectera au même AP/BSS que la victime.

  • ./macstealer.py wlan0 --other-bss : l'attaquant se connectera à un AP/BSS différent du même réseau. Un réseau qui est (aussi) vulnérable à ce test est plus facile à exploiter en pratique. Si un seul AP/BSS est à portée radio, le script expirera lors de la connexion en tant qu'attaquant.

6.3. Tests d'isolation client (couche Ethernet)

Exploiter la vulnérabilité de vol d'adresse MAC n'a de sens que si l'isolation client est activée ou si des techniques telles que l'inspection ARP sont utilisées pour empêcher les clients de s'attaquer entre eux. Sinon, un adversaire peut utiliser des attaques plus simples comme l'empoisonnement ARP pour intercepter le trafic. Pour tester si l'isolation client est activée, ou si l'inspection ARP est utilisée par le réseau, vous pouvez utiliser les commandes suivantes :

  • ./macstealer.py wlan0 --c2c wlan1 : avec ces arguments, MacStealer teste si le réseau autorise le trafic ARP empoisonné de client à client de l'attaquant (wlan1) vers la victime (wlan0). Ici wlan1 est une seconde interface réseau sans fil. Le script testera ensuite si des paquets ARP malveillants peuvent être envoyés de l'attaquant à la victime.

  • ./macstealer.py wlan0 --c2c-eth wlan1 : similaire au test ci-dessus, mais au lieu d'envoyer des paquets ARP malveillants, l'attaquant enverra des paquets DNS à la victime.

La vulnérabilité de vol d'adresse MAC doit être considérée comme un risque en pratique si le trafic de client à client est bloqué dans l'un des deux tests ci-dessus (c'est-à-dire lorsque l'isolation client est activée ou lorsque d'autres techniques telles que l'inspection ARP sont utilisées pour empêcher les utilisateurs de s'attaquer entre eux).

Par défaut, MacStealer essaiera de se connecter au même AP/BSS en utilisant les deux interfaces, il est donc important que les deux cartes réseau puissent voir les mêmes réseaux (c'est-à-dire assurez-vous que les deux interfaces réseau prennent en charge les mêmes bandes de fréquences et canaux). Si vous voulez que les deux clients se connectent à un AP/BSS différent, vous pouvez utiliser le paramètre --other-bss.

Vous pouvez utiliser le paramètre --flip-id pour tester si le trafic de la victime (wlan0) est autorisé vers l'attaquant (wlan1).

6.4. Liste de vérification pour le dépannage

Si MacStealer ne semble pas fonctionner, vérifiez les points suivants :

  1. Vérifiez qu'aucun autre processus n'utilise la carte réseau (par exemple, tuez votre gestionnaire de réseau). Vous pouvez voir la sortie kernel reports: match already configured si un autre processus utilise également la carte réseau.

  2. Si tout fonctionnait auparavant, essayez de débrancher votre adaptateur Wi-Fi, de redémarrer votre ordinateur ou votre machine virtuelle, puis réessayez.

  3. Confirmez que vous vous connectez au bon réseau. Revérifiez client.conf.

  4. Si vous avez mis à jour le code avec git, exécutez à nouveau ./build.sh et ./pysetup.sh (voir Prérequis).

  5. Si vous utilisez une machine virtuelle, essayez d'exécuter MacStealer depuis une installation Linux native à la place.

  6. Exécutez MacStealer avec le paramètre supplémentaire -dd pour obtenir des informations de débogage supplémentaires de wpa_supplicant et de MacStealer lui-même.

7. Utilisation avancée

7.1. Test de l'isolation client au niveau de la couche IP

Les tests d'isolation client par défaut vérifient si le trafic au niveau de la couche Ethernet est autorisé entre les clients. Il est également possible de tester si le trafic au niveau de la couche IP est autorisé entre les clients à l'aide de la commande suivante :

root@kitploit:~
./macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]

Lorsque le trafic au niveau de la couche IP est autorisé entre les clients, il est toujours possible que les clients s'attaquent entre eux. Par exemple, les attaques par redirection ICMP peuvent alors encore être possibles. Ces attaques sont plus lourdes que l'usurpation ARP, mais elles devraient idéalement être également empêchées en bloquant aussi le trafic au niveau de la couche IP entre les clients.

7.2. Test des propriétés générales du réseau

Les tests suivants peuvent être exécutés pour tester les propriétés générales d'un réseau. Ces tests ne sont pas directement liés aux vulnérabilités, mais peuvent être utilisés pour mieux comprendre le comportement d'un réseau.

  • ./macstealer.py wlan0 --same-id [--other-bss] [--flip] : tester si les connexions TCP restent actives après la déconnexion et la reconnexion à un point d'accès. Si les connexions ne restent pas actives après la reconnexion, le réseau n'est probablement pas vulnérable aux attaques par vol d'adresse MAC. Cependant, un inconvénient majeur de ce comportement est que les clients légitimes doivent ouvrir de nouvelles connexions TCP à chaque reconnexion à ce réseau, ce qui donne l'impression que ce réseau est lent et peu fiable (une meilleure défense devrait donc être utilisée à la place).

    Vous pouvez utiliser le paramètre --other-bss pour vous reconnecter à un AP/BSS différent du même réseau. Vous pouvez utiliser l'argument --flip pour effectuer ce test sous l'identité de l'attaquant au lieu de l'identité de la victime.

  • ./macstealer.py wlan0 --flip : test de l'attaque normale de vol d'adresse MAC, mais en inversant les rôles de l'attaquant et de la victime. En d'autres termes, l'attaquant utilisera les « identifiants de la victime » fournis dans le fichier de configuration, et la victime utilisera les « identifiants de l'adversaire ».

  • ./macstealer.py wlan0 --c2c wlan1 --same-id [--flid-id] : tester si le trafic de client à client est autorisé entre deux appareils du même utilisateur. Voir tests d'isolation client pour la documentation sur le paramètre wlan1.

    Vous pouvez utiliser l'argument --flip pour effectuer ce test sous l'identité de l'attaquant au lieu de l'identité de la victime.

7.3. Autres paramètres

  • --delay seconds : vous pouvez utiliser le paramètre --delay pour spécifier un délai, en secondes, avant de vous reconnecter en tant qu'attaquant.

  • -d ou -dd : l'ajout de l'un de ces paramètres augmente la verbosité de débogage du script et de l'instance wpa_supplicant sous-jacente.

7.4. Test d'un point d'accès / BSS spécifique

Par défaut, MacStealer sélectionne automatiquement un AP/BSS du réseau auquel se connecter et à tester. Si vous avez un réseau avec plusieurs AP/BSS, vous pouvez en tester un spécifique en le spécifiant dans le bloc réseau de la victime à l'aide du mot-clé bssid. Par exemple, vous pouvez utiliser :

root@kitploit:~
...

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test: fill in properties of the network to test
	ssid="kuleuven"
	key_mgmt=WPA-EAP
	eap=PEAP
	phase2="auth=MSCHAPV2"

	# Victim login: fill in login credentials representing the victim
	identity="[email protected]"
	password="SuperSecret"

	# This a specific AP/BSS
	bssid=00:11:22:33:44:55
}

...

Avec la configuration ci-dessus, MacStealer testera 00:11:22:33:44:55. Cela signifie qu'il se connectera à la fois en tant que victime et en tant qu'attaquant à cet AP.

Vous pouvez également combiner cela avec le paramètre --other-bss. Dans ce cas, la victime se connectera à 00:11:22:33:44:55, et l'attaquant se connectera à un AP/BSS différent du même réseau.

Une autre option consiste à spécifier un BSS/AP explicite dans le bloc réseau de la victime et de l'attaquant.

Notez que MacStealer recherchera l'AP/BSS donné pendant au plus 30 secondes. S'il ne trouve pas l'AP/BSS spécifié, l'outil se fermera.

7.5. Test d'un réseau SAE-PK

Vous pouvez tester un réseau SAE-PK en utilisant le fichier de configuration suivant. Notez que pour les réseaux SAE-PK, il n'y a pas de différence dans la façon dont la victime et l'attaquant s'authentifient, c'est-à-dire qu'ils utilisent tous deux le même mot de passe.

root@kitploit:~
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl

# WPA3/SAE: support both hunting-and-pecking loop and hash-to-element
sae_pwe=2

network={
	# Don't change this field, the script relies on it
	id_str="attacker"

	# Network to test - attacker login
	ssid="test-saepk"
	psk="7iip-ytnz-qa25"
	key_mgmt=SAE
	ieee80211w=2
}

network={
	# Don't change this field, the script relies on it
	id_str="victim"

	# Network to test - victim login
	ssid="test-saepk"
	psk="7iip-ytnz-qa25"
	key_mgmt=SAE
	ieee80211w=2
}

8. Discussion du modèle de menace

8.1. Authentification WPA-PSK

En pratique, l'isolation client est également utilisée dans les réseaux sécurisés par un mot de passe pré-partagé. Par exemple, plusieurs routeurs offrent une option pour créer un réseau pour les invités ou les appareils (IoT) non sécurisés, où les clients de ce réseau sont isolés afin de ne pas pouvoir s'attaquer entre eux. Cependant, l'avantage sécuritaire de l'utilisation de l'isolation client dans ce scénario peut être remis en question. L'isolation client est censée empêcher un initié malveillant d'attaquer les autres. Mais si l'initié malveillant connaît le mot de passe pré-partagé, il peut simplement créer un clone pirate (jumeau maléfique), piéger les victimes pour qu'elles se connectent à cette copie malveillante du réseau, puis attaquer d'autres clients ! En d'autres termes, utiliser l'isolation client dans un réseau sécurisé par un mot de passe n'apporte aucune sécurité forte, un client malveillant peut créer un AP pirate pour continuer à attaquer d'autres clients.

Cela dit, on peut soutenir que la création d'un AP pirate peut être détectée par l'administrateur réseau, ce qui signifie que l'isolation client rend les attaques plus difficiles. De plus, lorsqu'un appareil léger est compromis (à distance), il peut ne pas avoir les ressources nécessaires pour agir (facilement) comme un AP pirate. Cela rend les attaques plus difficiles, mais pas impossibles, lorsque l'isolation client est utilisée. Dans l'ensemble, bien que l'isolation client n'apporte aucune garantie de sécurité forte dans un réseau protégé par mot de passe, on peut soutenir qu'elle augmente la difficulté pratique de mener des attaques.

Notre attaque MacStealing est plus facile à réaliser que la création d'un AP pirate. Tout ce que l'initié malveillant, par exemple un appareil IoT compromis et léger, doit faire est d'usurper une adresse MAC et de se (re)connecter au réseau. Une telle attaque est également plus difficile à détecter. Sur la base de cette observation, notre nouvelle attaque aggrave la situation, et l'on peut donc soutenir que notre attaque devrait également être considérée comme pertinente dans les réseaux protégés par un mot de passe pré-partagé.

Conclusion : lorsque vous utilisez l'isolation client dans un réseau protégé par mot de passe, vous partez du principe qu'un initié malveillant ne créera pas d'AP pirate. Sinon, l'utilisation de l'isolation client est dénuée de sens d'un point de vue sécuritaire. L'attaque MacStealing peut être réalisée sans créer d' AP pirate et rend donc les attaques plus faciles.

8.2. Idées reçues courantes

  • Le but de notre attaque n'est pas de contourner les listes d'adresses MAC autorisées/interdites des points d'accès. L'usurpation d'adresses MAC pour contourner le filtrage d'adresses MAC est une attaque différente et connue.

  • Le but de notre attaque n'est pas de détourner la connexion payante de quelqu'un dans les hotspots Wi-Fi. Par exemple, certains hotspots ouverts (ou protégés) exigent que l'utilisateur paie avant de pouvoir accéder à Internet. Souvent, un abonné payant est reconnu sur la base de son adresse MAC, et un adversaire peut usurper l'adresse MAC d'une victime pour obtenir l'accès à Internet. Ce n'est pas le but de notre attaque ; l'objectif de MacStealer est de contourner l'isolation client.

  • Notre attaque affecte également les réseaux qui se défendent contre la vulnérabilité Hole 196. Par exemple, les réseaux Passpoint (anciennement Hotspot 2.0) sont tenus de prévenir la vulnérabilité Hole 196, mais restent vulnérables à notre attaque.

  • Notre attaque fonctionne dans les réseaux qui se défendent contre l'usurpation ARP. Dans les réseaux Wi-Fi mal sécurisés, un adversaire peut trivialement effectuer une usurpation ARP pour intercepter le trafic d'une victime, et notre attaque n'est pas vraiment pratique. Cependant, les réseaux modernes, qui peuvent contenir des initiés malveillants, s'appuient sur l'isolation client ou d'autres méthodes pour empêcher les attaques de type machine-in-the-middle. Notre attaque contourne toutes ces défenses modernes et permet toujours à un adversaire d'intercepter le trafic destiné à une victime.

Pour résumer, notre attaque affecte les réseaux Wi-Fi où les clients sont empêchés de s'attaquer entre eux, permettant à un adversaire d'intercepter le trafic destiné à un autre client.

8.3. CVE assigné

La plupart des fournisseurs utilisent CVE-2022-47522 pour désigner la vulnérabilité de contournement de l'isolation client Wi-Fi discutée dans ce dépôt git. Cette vulnérabilité correspond à l'attaque de la section 5 de notre article.

Malheureusement, d'autres fournisseurs utilisent également ce CVE pour désigner la vulnérabilité (strictement parlant sans rapport) discutée dans la section 3 de notre article. En fait, la description réelle du CVE telle qu'elle se trouve sur MITRE, à notre avis, ne décrit que l' attaque de la section 3 de notre article. En pratique, il semble que CVE-2022-47522 soit utilisé pour désigner toutes les attaques de notre article, même si elles sont techniquement différentes.

9. Journal des modifications

Version 1.2 (en cours)

  • README amélioré : clarification de l'utilisation de l'identifiant CVE.

  • README amélioré : concentration de l'introduction sur le contournement de l'isolation client, mise à jour des défenses avec des remarques 802.1X et pour empêcher le vol de l'adresse MAC de la passerelle par défaut.

  • Ajout du paramètre --delay pour spécifier un délai en secondes avant de se reconnecter en tant qu'attaquant.

Version 1.1 (18 janvier 2023)

  • Par défaut, utiliser 8.8.8.8 comme serveur au lieu de 216.58.208.100 (les deux sont des serveurs Google).

  • Mise à jour des tests d'isolation client : par défaut, test avec empoisonnement ARP au niveau de la couche Ethernet. Fournit également une option pour envoyer des données UDP avec transfert au niveau de la couche Ethernet, et un test avec transfert au niveau de la couche IP.

  • README amélioré : mise à jour des types de réseaux qui peuvent être affectés. Inclusion d'une discussion sur la question de savoir si les réseaux WPA2 ou WPA3 protégés par mot de passe sont affectés. Explication des différentes commandes pour tester le trafic de client à client au niveau Ethernet ou IP.

  • README amélioré : discussion sur la MFP, discussion sur les VLAN comme mesure d'atténuation, clarification des AP sur lesquels la vérification d'identité doit être effectuée, spécification du port du serveur.

  • Sortie améliorée de MacStealer.

Version 1.0 (3 janvier 2023) :

  • Préparation de la version initiale pour une utilisation pendant l'embargo. Le code est basé sur le commit hostap 0f3f9cdcab6a.
Télécharger l’outil
CommandeBrève description
Vérifications préliminaires
./macstealer.py wlan0 --pingSe connecter en tant que victime et tester le comportement de retransmission du serveur.
./macstealer.py wlan0 --ping --flipSe connecter en tant qu'attaquant et tester le comportement de retransmission du serveur.
Tests de vulnérabilité
./macstealer.py wlan0Tester la variante par défaut de l'attaque par vol d'adresse MAC.
./macstealer.py wlan0 --other-bssLaisser l'attaquant se connecter à un point d'accès différent de celui de la victime.
Isolation client : couche Ethernet
./macstealer.py wlan0 --c2c wlan1Tester le trafic Ethernet de client à client (empoisonnement ARP).
./macstealer.py wlan0 --c2c-eth wlan1Tester le trafic Ethernet de client à client (DNS).