vanhoefm/fragattacksTesteur automatisé de vulnérabilités pour clients Wi-Fi et points d'accès, détectant les failles de fragmentation/agrégation FragAttacks via l'injection de trames, les tests en mode mixte et l'analyse de capture de paquets.
Ce dépôt contient l'outil FragAttacks. Il permet de tester les clients Wi-Fi et les points d'accès contre les attaques de fragmentation et d'agrégation. Ces vulnérabilités affectent tous les réseaux Wi-Fi protégés. Pour plus d'informations sur ces vulnérabilités, consultez fragattacks.com.
Les ressources supplémentaires suivantes sont disponibles :
Voir le journal des modifications pour un aperçu détaillé des mises à jour de l'outil effectuées depuis le 11 août 2020. Ce journal contient également des informations sur la version de hostap sur laquelle l'outil FragAttacks est basé.
Notez que les attaques sont identiques contre WPA2 et WPA3, car leurs chiffrements CCMP et GCMP sont identiques. Les anciens réseaux WPA utilisent par défaut TKIP pour le chiffrement, et l'applicabilité des attaques contre TKIP est discutée dans l'article et sur le site web. Pour illustrer que le Wi-Fi est vulnérable depuis sa création, l'article et le site web discutent également brièvement de l'applicabilité des attaques contre WEP.
Seules des cartes réseau sans fil spécifiques sont prises en charge. En effet, certaines cartes réseau peuvent écraser le numéro de séquence ou de fragment des trames injectées, ou réordonner les trames de différentes priorités, ce qui interfère avec l'outil de test (c'est-à-dire que l'outil peut indiquer qu'un appareil est sécurisé alors qu'il ne l'est pas). J'ai confirmé que les cartes réseau suivantes fonctionnent correctement :
Les deux dernières colonnes signifient :
Mode mixte : indique si la carte réseau peut être utilisée dans le mode mixte recommandé.
Mode injection : indique si la carte réseau peut être utilisée comme seconde interface pour injecter des trames en mode injection.
Oui indique que la carte fonctionne immédiatement dans le mode donné. Pilote/firmware patché signifie que la carte est compatible lorsqu'elle est utilisée avec des pilotes et/ou un firmware patchés. Non signifie que ce mode n'est pas pris en charge par la carte réseau. Je recommande d'utiliser l'outil de test en mode mixte.
Notez que les périphériques USB peuvent être utilisés dans une machine virtuelle et que les pilotes et/ou le firmware modifiés peuvent être installés dans cette machine virtuelle. Cependant, j'ai constaté que l'utilisation de machines virtuelles peut rendre les cartes réseau moins fiables, et je recommande plutôt l'utilisation d'une image USB live si vous ne pouvez pas installer les pilotes/firmware modifiés nativement.
Mon expérience avec les cartes réseau ci-dessus est disponible ici. En résumé :
L'AWUS036ACM en mode mixte semble fiable avec nos derniers pilotes et c'est celui que je recommande. Un appareil moins cher mais presque identique est un appareil avec un chipset MT7612U. Voir plus d'informations ici.
J'ai précédemment recommandé la Technoethical N150 HGA en mode mixte. Cette clé est identique à la TP-Link TL-WN722N v1.x et nécessite l'utilisation de pilotes et d'un firmware patchés. C'est l'une des clés les plus testées, mais elle est difficile à obtenir. C'est pourquoi je recommande maintenant l'AWUS036ACM à la place.
Les cartes Intel 3160 et 8265 sont prises en charge et testées de manière approfondie. Parfois, leur firmware plantait, mais un redémarrage rend la carte réseau à nouveau utilisable. L'Intel AX200 n'est pas compatible avec l'outil de test.
La WN111v2 semble bien fonctionner, bien que je ne l'aie pas testée de manière approfondie.
Le pilote de l'AWUS036ACH ne fait pas partie du noyau Linux et nécessite l'installation d'un pilote séparé. Sur Kali, vous pouvez installer ce pilote via le gestionnaire de paquets. Cette carte n'a pas été testée en profondeur.
Si vous ne parvenez pas à trouver l'une des cartes réseau ci-dessus, vous pouvez rechercher des cartes réseau alternatives qui ont de grandes chances de fonctionner également. Lorsque vous utilisez une carte réseau non explicitement prise en charge, je recommande fortement d'exécuter d'abord les tests d'injection avant de l'utiliser, et d'utiliser l'outil contre une implémentation connue comme vulnérable pour confirmer que l'outil fonctionne correctement.
L'outil de test a été testé sur Ubuntu 20.04 avec le noyau 5.8. Si vous utilisez une autre distribution Linux, notez que seules les versions du noyau inférieures ou égales à 5.12 sont prises en charge.
Avec Ubuntu 20.04, vous devrez d'abord installer le noyau 5.8 comme suit. Notez que votre noyau existant restera installé et continuera également d'être utilisé par défaut :
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
Redémarrez maintenant Ubuntu, maintenez la touche Maj enfoncée au démarrage, sélectionnez "Advanced options for Ubuntu", puis démarrez le noyau 5.8 en choisissant "Ubuntu, with Linux 5.8.0-63-generic". Vous pouvez modifier votre configuration GRUB afin qu'Ubuntu utilise cette version du noyau par défaut. Poursuivez les instructions suivantes sous ce noyau maintenant en cours d'exécution.
Installez les dépendances requises :
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc
Clonez maintenant ce dépôt, compilez les outils et configurez un environnement virtuel python3 :
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/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 via git, vous devez exécuter ./build.sh et ./pysetup.sh à nouveau.
Installez les pilotes patchés avec :
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
Cela compile les pilotes pour la plupart des cartes réseau prises en charge par Linux. Si vous souhaitez uniquement compiler les pilotes pour les cartes réseau que j'ai explicitement testées, utilisez make defconfig-experiments à la place. Vous pouvez obtenir les avertissements suivants :
make defconfig-wifi, vous pouvez obtenir des avertissements liés à -Wyacc et -Wformat-overflow. Vous pouvez ignorer ces avertissements tant que les pilotes sont compilés avec succès... needs unknown symbol ... Vous pouvez ignorer ces avertissements tant qu'ils ne contiennent pas le répertoire /lib/modules/*/updates/ et que les pilotes compilés fonctionnent.SSL error et la commande sign-file. Cela signifie que la signature numérique des modules du noyau a échoué. Vous pouvez généralement les ignorer.cat /sys/module/mac80211/parameters/fragattack_version après un redémarrage. Si ce fichier existe, les pilotes modifiés ont été installés avec succès.Installez maintenant le firmware ath9k_htc patché :
cd research/ath9k-firmware/
./install.sh
# Now reboot
Le script ./install.sh suppose que les images du firmware ath9k_htc se trouvent dans le répertoire /lib/firmware/ath9k_htc. Si ce n'est pas le cas sur votre système, vous devez copier manuellement htc_7010.fw et htc_9271.fw dans le répertoire approprié.
Après l'installation des pilotes et du firmware patchés, vous devez débrancher vos clés Wi-Fi et redémarrer votre système. Les instructions ci-dessus doivent être réexécutées si votre noyau Linux est mis à jour ou si les pilotes patchés sont mis à jour.
Notez que même si votre appareil fonctionne immédiatement, je recommande tout de même d'installer les pilotes modifiés, car cela garantit qu'il n'y a pas de régressions inattendues dans le noyau et dans le code des pilotes.
Si vous ne pouvez pas installer les pilotes/firmware modifiés nativement, vous pouvez télécharger une image USB live qui contient les pilotes/firmware modifiés ainsi que notre outil de test. Vous pouvez également utiliser une machine virtuelle avec des cartes réseau USB, bien que j'aie constaté que l'utilisation d'une machine virtuelle est moins fiable en pratique.
Chaque fois que vous voulez utiliser l'outil de test, vous devez d'abord charger l'environnement virtuel python en tant que root. Cela peut être fait avec :
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 l'outil de test. Assurez-vous également qu'aucun autre service réseau ne génère de trafic sortant. Vous pouvez vous en assurer en utilisant iptables pour bloquer le trafic en exécutant ./droptraffic.sh (vous pouvez annuler cela en redémarrant). Vérifiez éventuellement avec sudo airmon-ng check pour voir quels autres processus pourraient utiliser la carte réseau sans fil et interférer avec notre outil.
L'outil de test peut tester à la fois les clients et les points d'accès :
Tester les points d'accès : configurez le point d'accès que vous voulez tester en éditant research/client.conf. Il s'agit d'un fichier de configuration wpa_supplicant standard, voir la documentation hostap pour un aperçu de toutes les options prises en charge.
Tester les clients : vous devez exécuter l'outil de test avec le paramètre --ap (voir ci-dessous). Cela demande à l'outil de créer un point d'accès nommé testnetwork et avec le mot de passe abcdefgh. Connectez-vous à ce réseau avec le client que vous voulez tester. Par défaut, le client doit demander une adresse IP via DHCP. Pour modifier les propriétés du point d'accès créé, comme le canal sur lequel il est créé, vous pouvez modifier research/hostapd.conf.
Ce mode ne nécessite qu'une seule carte réseau sans fil, mais nécessite généralement un pilote et/ou un firmware patchés. Voir Pilotes patchés pour savoir comment installer les pilotes/firmware patchés, et Cartes réseau prises en charge pour les cartes réseau compatibles. Exécutez l'outil de test dans ce mode avec :
./fragattack.py wlan0 [--ap] $COMMAND
Les valeurs possibles de $COMMAND sont listées dans tester les vulnérabilités et tests de vulnérabilité étendus.
Un avantage de ce mode est qu'il fonctionne assez bien lors du test de clients qui peuvent entrer en état de veille. Néanmoins, si possible, je recommande de désactiver la fonctionnalité de veille du client testé, voir Gestion du mode veille.
Ce mode nécessite deux cartes réseau sans fil : l'une agira comme point d'accès ou client, et l'autre sera utilisée pour injecter des trames. L'avantage est que ce mode peut fonctionner sans nécessiter de pilotes patchés. Exécutez l'outil de test dans ce mode avec :
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
Ici, l'interface wlan0 agira comme un client ou un point d'accès légitime, et wlan1 sera utilisée pour injecter des trames. Pour wlan0, toute carte prenant en charge le mode client ou point d'accès normal sous Linux peut être utilisée. Pour wlan1, une carte prenant en charge le mode injection selon Cartes réseau prises en charge doit être utilisée.
Lors du test de clients dans ce mode, les trames injectées peuvent être envoyées lorsque le client est en état de veille. Cela fait échouer les attaques, vous devez donc vous assurer que le client n'entrera pas en état de veille.
Ce mode est expérimental et réservé à la recherche. Voir détails du mode hwsim pour plus d'informations.
Vous pouvez tester les appareils en exécutant l'outil de test comme indiqué dans modes d'interface et en remplaçant $COMMAND par l'une des commandes du tableau ci-dessous. Nous supposons que les clients demanderont une adresse IP via DHCP (si ce n'est pas le cas, voir configuration IP statique). Toutes les commandes fonctionnent à la fois contre les clients et les points d'accès, sauf indication contraire.
L'outil affiche TEST COMPLETED SUCCESSFULLY si l'appareil est vulnérable à l'attaque correspondant à la $COMMAND donnée, et affiche Test timed out! Retry to be sure, or manually check result si l'appareil n'est pas vulnérable. Une fois le test terminé, vous pouvez fermer l'outil de test avec CTRL+C. La plupart des attaques ont plusieurs variantes légères représentées par différentes valeurs de $COMMAND.
La vérification du résultat de certains tests nécessite d'exécuter tcpdump ou wireshark sur l'appareil testé (le tableau ci-dessous indique si tcpdump doit être utilisé). Cette capture de paquets tcpdump ne doit inclure que les paquets qui ont passé le traitement des couches PHY et MAC. Par exemple, sous Linux, cette capture doit être effectuée pendant que l'interface sans fil est en mode "managed" ou "ap", et non en mode monitor, ce qui signifie que la capture ne contiendra que les paquets qui ont passé le traitement au niveau de la couche Wi-Fi. Voir éviter tcpdump sur les points d'accès pour une discussion sur la manière dont certains tests peuvent néanmoins être effectués sans avoir à exécuter tcpdump sur les points d'accès.
Pour vérifier votre configuration de test, la première commande du tableau ci-dessous effectue un ping normal qui doit réussir. La deuxième commande envoie le ping sous forme de deux trames Wi-Fi fragmentées, et ne devrait échouer que dans le rare cas où l'appareil testé ne prend pas en charge la fragmentation. Si l'un de ces tests ne fonctionne pas, suivez les instructions de test d'injection de carte réseau pour vous assurer que votre carte réseau injecte correctement les trames. Si le client testé risque d'entrer en mode veille, voir Gestion du mode veille.
Les troisième, quatrième et cinquième commandes ne sont pas des attaques mais vérifient le comportement de base de défragmentation d'un appareil et sont discutées plus en détail sous le tableau.
La correspondance entre les commandes et les CVE est listée ci-dessous. Notez que pour les défauts d'implémentation, nous listons un identifiant CVE de référence. Cependant, les fournisseurs peuvent utiliser des CVE différents, car une vulnérabilité d'implémentation reçoit normalement un CVE unique pour chaque base de code affectée. Nous recommandons néanmoins de toujours se référer à ces CVE de référence comme un moyen de désigner facilement chaque type de défaut d'implémentation découvert.
ping : Ce test doit toujours réussir. S'il échoue, quelque chose ne va pas dans la configuration du test.- ping I,E,E : ce test devrait réussir sur tous les ordinateurs portables modernes, les smartphones et les points d'accès (AP). S'il échoue,
il y a probablement un problème avec la configuration du test. Essayez d'ajouter le paramètre --icmp-size 100 pour corriger. Si
cela fonctionne avec ce paramètre supplémentaire, vous devez exécuter tous les autres tests avec ce paramètre supplémentaire également.
La seule fois où j'ai rencontré un échec de ce test pour des raisons valables, c'est lorsque l'appareil testé ne prend pas en charge
la réception de trames fragmentées, ce qui peut être le cas sur les appareils IoT légers et, par exemple, OpenBSD.ping I,E,E --delay 5 : ce test est utilisé pour vérifier le délai maximal accepté entre deux fragments.
Si ce test ne fonctionne pas, réessayez avec --delay 1.5 ou moins. Par exemple, Linux supprime les fragments
de la mémoire après 2 secondes, ce qui signifie qu'un délai de 1,8 fonctionnera tandis que 2,2 n'entraînera aucune réponse. Si le délai maximal
accepté est faible, tous les fragments envoyés dans les autres tests doivent l'être dans ce délai maximal accepté.
Sinon, les tests échoueront trivialement et vous pourriez conclure qu'un appareil n'est pas vulnérable à une attaque alors
qu'il l'est en réalité.
ping-frag-sep : ce test envoie une trame Wi-Fi fragmentée qui est séparée par une trame sans rapport.
Autrement dit, il envoie le premier fragment, puis une trame Wi-Fi (normale) sans rapport, et enfin le second fragment.
Si ce test échoue, l'attaque à clé mixte (par défaut) et l'attaque par cache échoueront probablement aussi (car elles nécessitent
l'envoi d'autres trames entre deux fragments). Ce test échouera également si le récepteur vérifie que les fragments
ont des numéros de paquet consécutifs (voir le test suivant ping-frag-sep --pn-per-qos).
ping-frag-sep --pn-per-qos : identique au précédent, mais l'ajout du paramètre --pn-per-qos garantit que les deux fragments
de la requête ping ont un numéro de paquet (PN) consécutif. C'est quelque chose qu'un récepteur devrait vérifier
pour être sécurisé. Malheureusement, avant la divulgation de nos résultats, de nombreuses implémentations
ne vérifiaient pas si les PN sont consécutifs. Ce test peut échouer si le récepteur ne suit pas le dernier
compteur de paquets reçu par TID QoS, auquel cas vous pouvez ignorer les autres tests contenant le paramètre --pn-per-qos.
Le test ping I,E --amsdu vérifie si une implémentation prend en charge les A-MSDU non-SPP (il ne vérifie pas si l'appareil
est vulnérable à CVE-2020-24588). Pour prévenir les attaques, idéalement
le réseau doit imposer l'utilisation d'A-MSDU SPP et abandonner tous les A-MSDU non-SPP. Cependant, la plupart des fournisseurs
mettent actuellement en œuvre des atténuations ad hoc à la place (voir la section 7.2 de l'article). Pour cette raison, vous devez utiliser
les deux tests suivants pour vérifier si un appareil est vulnérable aux attaques d'agrégation (A-MSDU) (CVE-2020-24588) :
amsdu-inject : ce test simule l'attaque d'injection A-MSDU décrite dans la section 3.2 de l'article. En particulier,
il envoie une trame A-MSDU dont le début est également un en-tête LLC/SNAP valide (car c'est aussi ce qui se produit dans notre attaque
de référence). Si ce test réussit, l'appareil est vulnérable à CVE-2020-24588.
amsdu-inject-bad : certains appareils analysent incorrectement les trames A-MSDU qui commencent par un en-tête LLC/SNAP valide, ce qui fait échouer le
test ci-dessus. Dans ce cas, essayez plutôt amsdu-inject-bad (voir la section 3.6 de l'article). Notez que si ce test
réussit, l'impact de l'attaque est effectivement identique à celui des implémentations qui analysent correctement ces trames,
ce qui signifie que l'appareil est vulnérable à CVE-2020-24588.
Lors de l'exécution du test de clé mixte contre un AP, l'AP doit être configuré pour renouveler régulièrement (par exemple toutes les minutes)
la clé de session (PTK) en exécutant un nouveau handshake à 4 voies. L'outil affichera
Client cannot force rekey. Waiting on AP to start PTK rekey en attendant ce handshake de renouvellement de PTK.
Contre un petit nombre d'AP, l'outil de test peut également demander le renouvellement du PTK en ajoutant le paramètre --rekey-req,
ce qui signifie qu'il n'est pas nécessaire de configurer l'AP pour renouveler périodiquement la clé.
Certains AP ne peuvent pas être configurés pour renouveler régulièrement la clé de session (PTK). Contre ces AP, vous pouvez plutôt essayer un test d'attaque par cache. Si l'AP est vulnérable aux attaques par cache, il est probablement également vulnérable aux attaques à clé mixte (sauf s'il existe des preuves solides contredisant cela, par exemple si un audit du code indique que les attaques à clé mixte sont empêchées). Si l'AP n'est pas vulnérable aux attaques par cache, alors nous ne pouvons rien dire sur sa susceptibilité aux attaques à clé mixte, et dans ce cas je recommande plutôt de réaliser un audit du code.
ping I,F,BE,AE --pn-per-qos : le paramètre supplémentaire --pn-per-qos garantit que les deux fragments injectés ont
des numéros de paquet consécutifs, ce qui est nécessaire pour que l'attaque à clé mixte réussisse contre certains appareils
(par exemple contre Linux).
Plusieurs appareils implémentent le handshake à 4 voies différemment, ce qui aura un impact sur la réussite ou non de ces tests. En cas d'échec des tests, il est recommandé d'effectuer également les tests d'attaque à clé mixte listés dans Tests de vulnérabilité étendus.
Lors du test d'un AP, l'outil envoie un premier fragment, puis tente de se réassocier à l'AP, et enfin
envoie le second fragment. Cependant, tous les AP ne prennent pas correctement en charge le processus de réassociation. Dans ce cas,
ajoutez l'option --full-reconnect comme indiqué dans le tableau, ce qui fait que l'outil de test se désauthentifie
après l'envoi du premier fragment.
Lors du test d'un client, l'outil envoie un premier fragment, dissocie le client, et une fois que le client
s'est reconnecté, il envoie le second fragment. Idéalement, le client se reconnectera immédiatement après l'envoi
de la trame de dissociation. Cela peut nécessiter de désactiver tous les autres réseaux sur le client testé. J'ai également
constaté que certains clients ne semblent pas gérer correctement la dissociation, et dans ce cas vous pouvez ajouter l'option
--full-reconnect comme indiqué dans le tableau pour envoyer une trame de désauthentification à la place.
J'ai constaté qu'il est préférable d'exécuter chaque test d'attaque par cache plusieurs fois. Parfois, un test d'attaque par cache peut échouer alors que l'implémentation est vulnérable. Cela peut être dû au bruit de fond, à d'autres appareils envoyant des trames à l'appareil testé, etc.
ping I,E,R,AE [--full-recon] : ici, le second fragment est envoyé immédiatement après la reconnexion avec l'appareil
testé, ce qui est important si l'appareil efface les fragments de la mémoire après un court instant.
Notez que full-recon est un raccourci de full-reconnect.
ping I,E,R,E [--full-recon] : ici, le second fragment est envoyé 1 seconde après la reconnexion avec l'appareil
testé, ce qui peut être utile s'il y a un petit délai entre la fin du handshake
et l'installation de la clé négociée.
Dans nos expériences, ce test n'a échoué que contre Linux et contre les appareils qui ne prennent pas en charge la fragmentation.
ping I,E,P et linux-plain : si ce test réussit, les attaques qui en résultent sont décrites dans la section 6.3
de l'article. En résumé, en combinaison avec la vulnérabilité A-MSDU ou de cache, elle peut être exploitée pour
injecter des paquets. Lorsqu'elle n'est pas combinée à d'autres vulnérabilités, l'impact est spécifique à l'implémentation
(CVE-2020-26147).
ping I,P,E : si ce test réussit, il est trivial d'injecter des trames en clair vers l'appareil si
la fragmentation est utilisée par le réseau (CVE-2020-26147).
ping I,P : si ce test réussit, l'implémentation accepte les trames en clair dans un réseau Wi-Fi
protégé, permettant une injection de paquets triviale (CVE-2020-26140).
ping I,P,P : si ce test réussit, l'implémentation accepte les trames en clair fragmentées dans un réseau Wi-Fi
protégé, permettant une injection de paquets triviale (CVE-2020-26143).
Les deux tests suivants envoient des trames de diffusion, qui ne sont pas automatiquement retransmises, et il est donc recommandé de les exécuter plusieurs fois. En effet, le bruit de fond peut empêcher les appareils testés de recevoir la trame de diffusion injectée. Dans mes expériences, principalement les clients étaient concernés (parmi les AP testés, seuls ceux sous Free/NetBSD étaient concernés).
ping I,D,P --bcast-ra : envoyer un ping unicast dans un 2e fragment diffusé en clair une fois connecté. Le résultat
de cette variante de l'attaque est vérifié automatiquement par l'outil de test.
ping D,BP --bcast-ra : ici, la trame ci-dessus est envoyée lors de la connexion au réseau (c'est-à-dire pendant le handshake à 4 voies).
C'est important car plusieurs clients et AP ne sont vulnérables qu'avant la fin du handshake à 4 voies. Pour
confirmer le résultat de ce test, vous devez exécuter wireshark ou tcpdump sur la victime et surveiller si la
requête ping injectée est reçue par la victime. Dans tcpdump, vous pouvez utiliser le filtre icmp et dans wireshark, vous
pouvez également utiliser le filtre frame contains "test_ping_icmp" pour détecter plus facilement cette requête ping. Dans mes expériences,
principalement les clients étaient concernés.
eapol-amsdu I,P : il s'agit du test standard pour la vulnérabilité spécifique à l'implémentation discutée dans
la section 6.5 de l'article. Les clients et les AP peuvent être vulnérables. Son résultat est vérifié automatiquement par
l'outil de test.
Les tests se terminant par BP (eapol-amsdu BP et eapol-amsdu-bad BP) : ces tests injectent la trame malveillante
pendant l'exécution du handshake à 4 voies. Pour confirmer le résultat de ce test, vous devez exécuter wireshark
ou tcpdump sur la victime et surveiller si la requête ping injectée est reçue par la victime. Dans tcpdump,
vous pouvez utiliser le filtre icmp et dans wireshark, vous pouvez également utiliser le filtre frame contains "test_ping_icmp"
pour détecter plus facilement cette requête ping.
Les tests commençant par eapol-amsdu-bad (eapol-amsdu-bad BP et eapol-amsdu-bad I,P) : plusieurs implémentations
traitent incorrectement les trames A-MSDU dont les 6 premiers octets correspondent également à un en-tête RFC1042 valide pour EAPOL. Pour tester ces
implémentations, vous devez utiliser la variante de test eapol-amsdu-bad. Notez que si ce test réussit, l'impact
de l'attaque est identique à celui des implémentations qui analysent correctement ces trames (pour plus de détails, voir les sections 3.6 et
6.6 de l'article).
Si l'outil de test ne semble pas fonctionner, vérifiez les points suivants :
Vérifiez qu'aucun autre processus n'utilise la carte réseau (par exemple, tuez votre gestionnaire de réseau).
Si tout fonctionnait auparavant, essayez de débrancher votre clé Wi-Fi, redémarrez votre ordinateur ou votre machine
virtuelle, puis réessayez. Essayez également de désactiver le chiffrement matériel à l'aide du script disable-hwcrypto.sh
(redémarrez votre ordinateur après avoir exécuté ce script).
Assurez-vous que l'appareil testé n'entre pas dans un état de veille (ce qui l'amènerait à manquer les trames injectées). Je recommande d'exécuter l'outil de test en mode mixte car il gère mieux les clients qui peuvent passer en état de veille.
Exécutez les tests d'injection pour vous assurer que l'injection fonctionne correctement. Assurez-vous également qu'un canal de 20 MHz est utilisé ; l'injection sur d'autres canaux n'est pas testée.
Vérifiez que votre machine ne génère pas de trafic de fond qui interfère avec les tests. En particulier, désactivez la mise en réseau dans votre système d'exploitation, tuez manuellement votre client/serveur DHCP, etc. Voir aussi Avant chaque utilisation.
Confirmez que vous vous connectez au bon réseau. Revérifiez client.conf.
Assurez-vous que l'AP testé utilise (AES-)CCMP comme algorithme de chiffrement. Les autres algorithmes de chiffrement tels que TKIP ou GCMP ne sont pas pris en charge.
Si vous avez mis à jour le code avec git, exécutez à nouveau ./build.sh et ./pysetup.sh (voir Prérequis).
Si les pilotes patchés ont été mis à jour, pensez à les recompiler également.
Si vous utilisez une machine virtuelle, essayez plutôt d'exécuter l'outil de test depuis une image USB live.
Vérifiez que l'appareil testé ne bloque pas les requêtes ping ICMP. S'il ne répond pas aux pings, vous pouvez exécuter tcpdump ou wireshark sur l'appareil, ou essayer l'une des autres méthodes listées dans .
En raison des variations d'implémentation, il peut être difficile de confirmer/exploiter certaines vulnérabilités, en particulier l'attaque à clé mixte et l'attaque par cache peuvent être non triviales à confirmer en pratique. Par conséquent, je recommande de ne considérer un appareil comme sécurisé que s'il existe des vérifications explicites dans le code pour empêcher ces attaques. De plus, si le temps le permet, je recommande également les tests plus avancés suivants. Ils ont moins de chances de découvrir de nouvelles vulnérabilités, mais ils peuvent révéler des variantes d'attaque ou un comportement particulier de l'appareil que les tests normaux ne peuvent pas détecter.
Si les tests normaux de Test des vulnérabilités ont déjà confirmé la présence d'une certaine classe de vulnérabilité, il est peu utile de tester les autres variantes d'attaque de cette vulnérabilité. Toutes les commandes fonctionnent à la fois contre les clients et les AP, sauf indication contraire.
Il n'est utile d'exécuter ces deux tests que si le test principal ping I,E --amsdu échoue et que vous voulez mieux
comprendre comment l'appareil testé gère les trames A-MSDU :
ping I,E --amsdu-fake : si ce test réussit, le récepteur traite toutes les trames comme des trames normales (ce qui signifie qu'il ne prend pas
en charge les trames A-MSDU). Ce comportement n'est pas idéal, bien qu'il soit peu probable qu'un attaquant puisse en abuser en
pratique (voir la section 3.5 de l'article).
ping I,E --amsdu-fake --amsdu-spp : si ce test réussit, le récepteur authentifie l'indicateur QoS A-MSDU de chaque
trame reçue (c'est-à-dire qu'il ne le masque pas à zéro à la réception) mais traite ensuite toutes les trames reçues comme des trames normales
(ce qui signifie qu'il ne prend pas en charge la réception de véritables trames A-MSDU). Ce comportement n'est pas idéal, bien qu'il soit peu probable
qu'un attaquant puisse en abuser en pratique (voir la section 3.5 de l'article).
La plupart des appareils que j'ai testés sont vulnérables aux attaques à clé mixte. Si les tests d'attaque à clé mixte normaux indiquent
qu'un appareil n'est pas vulnérable, mais que le test ping-frag-sep réussit, il est vivement recommandé d'essayer
ces tests alternatifs d'attaque à clé mixte.En règle générale, lors du test d'un AP, vous pouvez ajouter le paramètre --rekey-req à n'importe lequel des tests d'attaque à clé mixte pour demander activement un handshake de renouvellement de clé. Un petit nombre d'AP effectueront alors le handshake de renouvellement de clé. La plupart des AP ignoreront toutefois cette demande et devront être explicitement configurés pour renouveler régulièrement la clé de session (PTK).
Quelques remarques concernant les tests :
ping I,F,BE,E et ping I,E,F,AE : Ce sont des tests d'attaque à clé mixte assez simples où les deux fragments sont injectés à des moments différents.
ping I,E,F,AE --rekey-plain : Certains pilotes (par exemple MediaTek) effectuent le handshake de renouvellement de clé en clair. Pour tester les appareils qui utilisent un tel pilote, vous devez ajouter le paramètre --rekey-plain.
ping I,E,F,AE --rekey-plain --rekey-req : Cette combinaison particulière est utile pour tester les routeurs qui utilisent un pilote MediaTek. Ces routeurs effectuent le handshake de renouvellement de clé en clair, et le client peut demander activement un handshake de renouvellement de clé.
ping I,E,F,AE --rekey-early-install : Un petit nombre de clients installent (incorrectement) la clé trop tôt pendant un renouvellement de clé de session pairwise. Pour tester ces clients de manière fiable, ajoutez le paramètre --rekey-early-install. Ce test n'est pas significatif contre les AP.
ping I,E,F,E [--rekey-pl] [--rekey-req] : Cette variante de test est identique aux tests précédents ping I,E,F,AE *, sauf que le second fragment est envoyé 1 seconde après le 4-way handshake. Cela peut être important car, sur un petit nombre d'appareils, il y a un léger délai avant que la nouvelle clé soit installée. Notez que est un raccourci de .
Enfin, si le test ping-frag-sep ne réussit pas, vous devriez essayer le test d'attaque à clé mixte suivant :
ping I,F,BE,AE --freebsd : Ce test effectue essentiellement le handshake de renouvellement de clé contre une implémentation FreeBSD, ou un pilote qui emprunte du code à FreeBSD, sans affecter le processus de défragmentation des trames de données. Voir l'annexe E de l'article pour plus de détails.ping I,E,R,AE --freebsd --full-reconnect : Ce test peut être utilisé pour vérifier si un AP FreeBSD, ou un pilote qui emprunte du code à FreeBSD, est vulnérable à une attaque par cache. Voir l'annexe E de l'article pour plus de détails sur le fonctionnement de ce test. Vous devriez également essayer ce test sans le paramètre --full-reconnect. Le test fonctionne aussi contre les clients, mais ceux-ci ne sont probablement pas concernés.
ping I,E,R,AP --freebsd --full-reconnect : Ce test est une variante contre les AP FreeBSD, ou contre un pilote qui emprunte du code à FreeBSD, où le second fragment est envoyé en clair après reconnexion à l'AP. Sur certains dongles FreeBSD, ce test était plus fiable et prouve que d'anciens fragments restent dans la mémoire de l'AP après reconnexion. Vous devriez également essayer ce test sans le paramètre --full-reconnect. Le test fonctionne aussi contre les clients, mais ceux-ci ne sont probablement pas concernés.
ping I,E,R,AP [--full-reconnect] : Dans ce test, le second fragment est envoyé en clair. Cela peut être utile si l'appareil testé n'installe pas immédiatement la clé après le 4-way handshake. Si ce test réussit, cela montre que l'appareil conserve des fragments en mémoire après s'être (re)connecté à un réseau, ce qui signifie qu'il est vulnérable aux attaques par cache. Contrairement aux deux commandes ci-dessus, celle-ci est également utile à exécuter contre les clients (ainsi que les AP).
ping I,E,E --amsdu : Ce test envoie une trame A-MSDU fragmentée, que tous les appareils ne peuvent pas recevoir correctement. Il ne teste pas une vulnérabilité. Ce test est plutôt utile pour déterminer l'exploitabilité pratique de l'« attaque mixte clair/chiffré ». En effet, si ce test réussit, il est plus facile d'attaquer l'appareil si le second fragment peut être envoyé en clair (test ping I,E,P). Voir la section 6.3 de l'article pour plus de détails.
ping I,E,P,E et linux-plain 3 : Si tous les autres tests d'attaque mixte clair/chiffré n'ont pas réussi, vous pouvez également essayer ces deux tests supplémentaires. Je pense qu'il est peu probable que cela révèle une nouvelle vulnérabilité.
La plupart des tests suivants envoient des trames broadcast, qui ne sont pas automatiquement retransmises. Il est donc recommandé de les exécuter plusieurs fois. En effet, le bruit de fond peut empêcher les appareils testés de recevoir la trame broadcast injectée. Dans mes expériences, principalement les clients ont été affectés. La plupart des clients ne sont vulnérables que lors de la connexion au réseau (c.-à-d. pendant l'exécution du 4-way handshake).
ping I,P --bcast-ra : Envoie une requête ICMP ping unicast dans une trame Wi-Fi broadcast en clair (CVE-2020-26145). Ce test peut être effectué à la fois contre les clients et les AP.
ping BP --bcast-ra : Similaire au test ci-dessus ping I,P --bcast-ra, mais le ping est envoyé avant que le client ne se soit authentifié auprès du réseau, c.-à-d. pendant l'exécution du 4-way handshake (CVE-2020-26145). Vous devez exécuter tcpdump ou wireshark pour vérifier si le client accepte la trame. Dans tcpdump, vous pouvez utiliser le filtre icmp et dans wireshark, vous pouvez également utiliser le filtre frame contains "test_ping_icmp" pour détecter plus facilement cette requête ping.
ping BP --bcast-ra --bcast-dst : Ce test est identique au précédent, mais il est utile si vous ne pouvez pas exécuter tcpdump sur l'AP cible. Notez que ce test n'a de sens que contre les AP. Le paramètre supplémentaire --bcast-dst dans ce test fait qu'un AP vulnérable diffuse la requête ping injectée à tous les clients connectés. En d'autres termes, pour vérifier si un AP est vulnérable, exécutez cette commande et écoutez les trames Wi-Fi broadcast sur un second appareil connecté à l'AP à l'aide du filtre icmp ou frame contains "test_ping_icmp".
ping BP [--bcast-dst] : Ce test est une variante des deux tests ci-dessus ping BP --bcast-ra [--bcast-dst], sauf que la requête ping est désormais envoyée dans une trame unicast en clair au lieu d'une trame broadcast (aucun CVE n'est encore attribué - cela est lié à CVE-2020-26145). Ce test doit être effectué à la fois contre les clients et les AP. Le ping est envoyé avant que le client ne se soit authentifié auprès du réseau (c.-à-d. pendant l'exécution du 4-way handshake), ce qui signifie que vous devez exécuter tcpdump ou wireshark pour vérifier si l'appareil accepte cette trame. Alternativement, lors du test des AP, vous pouvez ajouter le paramètre --bcast-dst comme dans le test ci-dessus, puis utiliser tcpdump ou wireshark sur un second appareil connecté à l'AP à l'aide du filtre icmp ou frame contains "test_ping_icmp".
eapfrag BP,BP : C'est une spécialisation des tests de fragments broadcast ci-dessus, effectuée avant que le client ne se soit authentifié. C'est une attaque très expérimentale basée sur l'analyse de code divulgué. Elle envoie d'abord un fragment en clair qui commence par un en-tête EAPOL, accepté car le 4-way handshake est encore en cours d'exécution. Elle envoie ensuite un second fragment broadcast avec le même numéro de séquence. D'après l'analyse du code divulgué, certains appareils peuvent alors accepter ce fragment (car le fragment précédent a été autorisé), mais le code ultérieur le traitera comme une trame normale (car le fragment est diffusé en broadcast). Vous devez utiliser tcpdump ou wireshark sur la victime pour déterminer si la trame est correctement reçue, par exemple en utilisant le filtre icmp ou . Une variante alternative est si la variante normale ne fonctionne pas.
Ce test peut être utilisé si vous souhaitez exécuter les tests eapol-amsdu[-bad] BP mais que vous ne pouvez pas exécuter tcpdump ou wireshark sur l'AP. Ce test n'a de sens que contre les AP : la commande eapol-amsdu[-bad] BP --bcast-dst fait qu'un AP vulnérable diffuse la requête ping injectée à tous les clients connectés. En d'autres termes, pour vérifier si un AP est vulnérable, exécutez cette commande et écoutez les trames Wi-Fi broadcast sur un second appareil connecté à l'AP à l'aide du filtre icmp ou frame contains "test_ping_icmp".
eapol-inject 00:11:22:33:44:55 : Ce test n'a de sens que contre les AP. Pour effectuer ce test, vous devez vous connecter au réseau à l'aide d'un second appareil et remplacer l'adresse MAC 00:11:22:33:44:55 par l'adresse MAC de ce second appareil. Avant d'être authentifié, l'outil de test enverra une trame EAPOL à l'AP avec pour destination finale ce second appareil. Si l'AP transmet la trame EAPOL au second appareil, l'AP est considéré comme vulnérable. Pour confirmer que l'AP transmet la trame EAPOL, vous devez exécuter tcpdump ou wireshark sur le second appareil. Vous pouvez utiliser le filtre wireshark frame contains "forwarded_data" lors de la surveillance du trafic déchiffré sur l'interface sans fil du second appareil (ou le filtre tcpdump ether proto 0x888e pour surveiller toutes les trames EAPOL). Voir la section 6.6 de l'article pour les détails et l'impact de cette attaque.
eapol-inject-lage 00:11:22:33:44:55 : Si le test eapol-inject ci-dessus réussit, vous pouvez également essayer eapol-inject-large pour voir si cette vulnérabilité peut être exploitée afin de forcer la transmission de fragments chiffrés. Vous devez à nouveau utiliser tcpdump ou wireshark pour le vérifier. Utilisez le filtre wireshark ou tshark (wlan.fc.frag == 1) || (wlan.frag > 0) pour détecter les trames fragmentées. J'ai constaté que cette attaque fonctionne très rarement.
ping I,D,E : Si ce test réussit, le client ou l'AP ne prend pas en charge la (dé)fragmentation, mais reste vulnérable aux attaques. Le problème est que le récepteur traite le dernier fragment comme une trame complète. Voir la section 6.8 de l'article pour les détails et la manière dont cela peut être exploité.
ping I,E,D : Si ce test réussit, le client ou l'AP traite le premier fragment comme une trame complète. Bien que ce comportement ne soit pas idéal, on ignore actuellement si cela peut, en soi, être exploité en pratique.
Le script test-injection.py peut être utilisé pour tester si les trames sont correctement injectées lors de l'utilisation du mode injection :
./test-injection.py wlan0 wlan1
Ici, nous testons si la carte réseau wlan0 injecte correctement les trames et nous utilisons la carte réseau wlan1 pour surveiller si les trames sont correctement injectées. Notez que les deux interfaces doivent prendre en charge le mode moniteur pour que ce script de test fonctionne.
Si vous ne disposez pas d'une seconde carte réseau, vous pouvez exécuter un test d'injection partiel à l'aide de :
./test-injection.py wlan0
Malheureusement, le test ci-dessus ne peut que vérifier si le noyau écrase des champs des trames injectées ; il ne peut pas vérifier si le firmware ou la puce sans fil elle-même écrase des champs.
Pour tester si une carte réseau injecte correctement les trames en mode mixte, qui est le mode que je recommande d'utiliser, vous pouvez exécuter les deux commandes suivantes :
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
Ici, nous testons si wlan0 injecte correctement les trames en surveillant les trames injectées à l'aide de la seconde carte réseau wlan1. La première commande teste si les trames sont correctement injectées en mode mixte lorsqu'on agit en tant que client, et la seconde commande en mode mixte lorsqu'on agit en tant qu'AP. Pour démarrer le test, le client doit pouvoir se connecter à un réseau, et l'AP attend qu'un client se connecte avant de lancer les tests d'injection (voir Avant chaque utilisation pour configurer la connexion du client et de l'AP).
Si vous souhaitez également tester le comportement de retransmission de wlan0 en mode mixte, vous pouvez exécuter :
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
Si vous ne disposez pas d'une seconde carte réseau, vous pouvez exécuter un test d'injection partiel en mode mixte à l'aide de :
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
Malheureusement, les tests ci-dessus ne peuvent que vérifier si le noyau écrase des champs des trames injectées ; ils ne peuvent pas vérifier si le firmware ou la puce sans fil elle-même écrase des champs.
Le script de test fournira une sortie détaillée indiquant quels tests ont réussi ou échoué, et se terminera en affichant soit ==> The most important tests have been passed successfully, soit un message indiquant que des tests importants ont échoué ou qu'il n'a pas pu capturer certaines trames injectées.
Notez que les scripts d'injection ne testent que le comportement le plus important. La meilleure façon de confirmer que l'injection fonctionne correctement est de réaliser les tests de vulnérabilité contre des appareils connus pour être vulnérables, et de confirmer que l'outil identifie correctement le ou les appareils comme vulnérables.
Lorsque certaines trames injectées n'ont pas pu être capturées, cela peut être dû au bruit de fond, ou au fait que la carte réseau testée n'est pas capable d'injecter correctement certaines trames (par exemple, le firmware de l'Intel AX200 plante lors de l'injection de trames fragmentées). Il se peut aussi que les trames soient en fait correctement injectées, mais que la carte réseau utilisée pour surveiller si les trames sont correctement injectées (wlan1 dans les exemples ci-dessus) ne soit pas fiable et, par exemple, manque la plupart des trames à cause du bruit de fond. Essayez également d'exécuter les tests sur un autre canal.
Lorsque les tests d'injection fonctionnent, mais que vous avez des difficultés à exécuter les tests d'attaque de manière fiable, cela peut être dû au fait que les appareils testés entrent en mode veille. Voir Gestion du mode veille pour des notes supplémentaires sur ce problème.
Lorsque vous utilisez wireshark pour inspecter le comportement d'injection d'un appareil, il est recommandé d'utiliser un second appareil en mode moniteur pour voir comment les trames sont injectées.
Si vous ouvrez l'interface utilisée pour injecter les trames, vous devriez voir les trames injectées deux fois : (1) d'abord, vous voyez la trame telle qu'elle est injectée par l'outil qui l'envoie, puis (2) une seconde fois, selon la façon dont la trame a été injectée par le pilote. Ces deux trames peuvent différer légèrement si le noyau a écrasé certains champs. Si vous ne voyez une trame injectée qu'une seule fois, elle a peut-être été supprimée par le noyau.
Si l'appareil que vous testez ne prend pas en charge DHCP, vous pouvez spécifier manuellement les adresses IP que l'outil de test doit utiliser. Par exemple :
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
Ici, l'outil de test utilisera l'adresse IP 192.168.100.10 et injectera une requête ping vers l'adresse IP du pair 192.168.100.1.
Lorsqu'un test envoie des paquets IP avant d'obtenir des adresses IP via DHCP, il utilise l'adresse IP par défaut 127.0.0.1. Pour utiliser des adresses IP (par défaut) différentes, vous pouvez également utiliser les paramètres --ip et -peerip.
La plupart des tests d'attaque fonctionnent en envoyant des requêtes ping ICMP de manières particulières, et en vérifiant si nous recevons une réponse ping ICMP. Si l'appareil testé ne prend pas en charge les pings ICMP, vous pouvez utiliser à la place des requêtes ARP en ajoutant le paramètre --arp à tous les tests. Si un test ne prend pas en charge l'envoi de requêtes ARP, l'outil affichera l'erreur Cannot override request type of the selected test ; dans ce cas, le test spécifique ne peut être exécuté qu'avec des requêtes ping ICMP.
TODO : Lorsque l'on agit en tant que client, nous pouvons également injecter des requêtes DHCP à la place.
Si vous ne pouvez pas obtenir l'une des cartes réseau sans fil recommandées, une seconde option consiste à obtenir une carte réseau qui utilise les mêmes pilotes sous Linux. En particulier, vous pouvez essayer :
Je recommande les cartes basées sur ath9k_htc. Toutes les cartes utilisant iwlmvm ne seront pas compatibles. Lorsque vous utilisez une carte réseau alternative, je recommande fortement d'exécuter d'abord les tests d'injection pour confirmer que la carte réseau est compatible.
Afin d'utiliser l'outil de test sur les canaux 5 GHz, la carte réseau utilisée doit permettre l'injection de trames dans le canal 5 GHz. Malheureusement, cela n'est pas toujours possible en raison des contraintes réglementaires. Pour voir sur quels canaux vous pouvez injecter des trames, exécutez iw list et cherchez dans la section Frequencies les canaux qui ne sont pas marqués comme désactivés, no IR, ou détection radar. Notez que ces conditions peuvent dépendre de votre carte réseau, du pays actuellement configuré et de l'AP auquel vous êtes connecté. Pour plus d'informations, voir par exemple la documentation Arch Linux.
Notez qu'un appareil peut utiliser différents pilotes pour gérer les bandes 2,4 et 5 GHz. Par conséquent, il est important de tester les appareils dans ces deux bandes, car un appareil peut se comporter différemment selon la bande de fréquences utilisée.
Notez qu'en mode mixte, le noyau Linux peut ne pas autoriser l'injection de trames alors même qu'il est autorisé d'envoyer des trames normales. Cela est dû au fait que dans la fonction ieee80211_monitor_start_xmit, le noyau refuse d'injecter des trames lorsque cfg80211_reg_can_beacon renvoie faux. Par conséquent, Linux peut refuser d'injecter des trames alors que cela est en réalité autorisé. Faire en sorte que cfg80211_reg_can_beacon renvoie vrai dans les bonnes conditions permet d'éviter ce bug.
En pratique, certaines personnes ont constaté que vous devez d'abord configurer manuellement la carte réseau sans fil sur le canal 5 GHz sur lequel l'AP opère. Voir ce problème GitHub pour plus de détails.
Les appareils tels que les téléphones mobiles ou les gadgets IoT peuvent mettre leur radio Wi-Fi en mode veille pour réduire la consommation d'énergie. En mode veille, ces appareils ne peuvent pas recevoir les trames Wi-Fi, ce qui peut interférer avec nos tests. Voici quelques options à essayer pour atténuer ce problème :
Essayez de désactiver le mode veille sur l'appareil testé. C'est la solution la plus fiable, mais elle n'est malheureusement pas toujours possible.
Exécutez l'outil de test en mode mixte. La plupart des cartes réseau mettront alors en file d'attente les trames injectées jusqu'à ce que l'appareil testé soit de nouveau éveillé.
Essayez une autre carte réseau pour effectuer les tests. J'ai constaté que différentes cartes réseau injectent les trames à des moments (légèrement) différents, et cela peut faire la différence entre une trame injectée qui arrive correctement ou qui est manquée. Par exemple, contre un Pixel 4 XL, l'outil de test n'était pas fiable avec une TL-WN722N, mais fonctionnait de manière fiable avec une Intel 8265.
Attribuez des adresses IP statiques à l'appareil testé et laissez l'outil de test utiliser des adresses IP statiques (voir Configuration d'adresse IP statique). Avec de nombreux tests, cela peut être plus fiable car l'outil de test peut alors envoyer immédiatement la trame de test au lieu de devoir d'abord utiliser/attendre DHCP.
c'est-à-dire lorsqu'il exécute la poignée de main en 4 étapes (4-way handshake). Cela les rend plus difficiles à tester automatiquement et signifie généralement que tcpdump ou un outil similaire doit être utilisé sur le dispositif testé. Cependant, les points d'accès (AP) peuvent être testés sans exécuter tcpdump sur l'AP. En particulier, les tests de l'attaque par fragment broadcast (CVE-2020-26145) et les tests de l'attaque A-MSDU EAPOL (CVE-2020-26144) peuvent être effectués sans exécuter tcpdump sur le dispositif testé. Au lieu de cela, tcpdump doit être exécuté sur un autre client connecté à l'AP. Concrètement, les commandes suivantes peuvent être utilisées :
ping I,P --bcast-ra --bcast-dst and ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst and eapol-amsdu-bad BP --bcast-dst
Avec ces commandes, vous pouvez surveiller la requête ping sur un autre client connecté à l'AP. Si la requête ping est reçue sur ce client indépendant, l'AP testé est vulnérable. Malheureusement, il semble actuellement difficile de tester les clients contre ces variantes d'attaque sans exécuter tcpdump sur le client.
Si, pour une raison quelconque, Linux ne reconnaît pas automatiquement ce dongle, exécutez sudo modprobe mt76x2u
pour charger manuellement le pilote. Ce dongle semble fiable avec nos derniers pilotes. Si le dongle n'est pas fiable,
créez le fichier /etc/modprobe.d/mt76.conf avec le contenu suivant :```
options mt76_usb disable_usb_sg=1
Redémarrez ensuite votre machine. Assurez-vous également d’utiliser un bon câble USB avec ce dongle ! J’ai déjà rencontré
un comportement peu fiable avec ce dongle, qui était causé par un mauvais câble USB 3.0. Donc si vous rencontrez des problèmes,
il peut être utile de brancher directement le dongle sans utiliser de câble.
Lors de l’utilisation de VirtualBox, assurez-vous d’activer l’USB 3.0 afin que le dongle soit reconnu. Voir
[ce problème](https://github.com/vanhoefm/fragattacks/issues/22) pour plus de détails.
L’AWUS036ACM utilise en interne un chipset MT7612U. Il existe désormais également des dongles avec un chipset MT7612UN qui
sont également fiables avec notre outil de test. Un exemple est le [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).
### ath9k_htc
Les Technoethical N150 HGA, TP-Link TL-WN722N v1.x et Alfa AWUS036NHA utilisent tous le pilote `ath9k_htc`.
Pour moi, ces appareils ont plutôt bien fonctionné dans une machine virtuelle, même si, comme avec tous les appareils, ils sont
plus fiables lorsqu’ils sont utilisés nativement. Lors de l’utilisation d’une VM, je recommande de configurer la VM pour utiliser un contrôleur
USB 2.0, car cela semblait plus stable (du moins avec VirtualBox).
Dans les noyaux récents, il y avait une ([désormais corrigée](https://www.spinics.net/lists/linux-wireless/msg200825.html))
régression avec le pilote `ath9k_htc` qui l’empêchait de fonctionner. Utilisez simplement un noyau à jour ou nos pilotes
patchés pour éviter ce problème.
#### AWUS036ACH
Cet appareil n’est généralement pas pris en charge par défaut dans la plupart des distributions Linux et nécessite une installation
manuelle des pilotes. Sur Kali Linux, vous pouvez installer le pilote avec `sudo apt install realtek-rtl88xxau-dkms`.
Pour installer le pilote sur d’autres distributions, consultez votre gestionnaire de paquets ou suivez les instructions
d’installation sur [GitHub](https://github.com/aircrack-ng/rtl8812au). Avant de brancher l’appareil,
il est recommandé d’exécuter `modprobe 88XXau rtw_monitor_retransmit=1`.
Malheureusement, cet appareil ne fonctionne pas en mode mixte, qui est le mode recommandé, et il est difficile
à utiliser en combinaison avec nos pilotes modifiés. En pratique, vous devrez désinstaller les pilotes
modifiés puis exécuter l’outil de test avec les paramètres `--no-drivercheck` et `--inject wlan0`
où wlan0 désigne la carte AWUS036ACH. En raison de ces limitations, cet appareil n’est pas recommandé.
### Intel AX200
J’ai testé l’Intel AX200 et constaté qu’il _n’est pas_ compatible avec l’outil de test : son firmware plante
après l’injection d’une trame avec le drapeau More Fragments défini. Si un développeur Intel lit ceci, veuillez
mettre à jour le firmware et rendre possible l’injection de trames fragmentées.
### Chips basés sur RT5572
J’ai testé ce chipset à l’aide de l’adaptateur général [CSL USB 2.0 WLAN Adapter 300Mbit](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20).
Après avoir désactivé le déchiffrement matériel en exécutant le script `disable-hwcrypto.sh`, j’ai pu effectuer
un test ping de base (`ping`). Un test ping fragmenté (`ping I,E,E`) était très peu fiable mais fonctionnait parfois.
La conclusion actuelle est que les chips RT5572 _pourraient_ fonctionner avec l’outil de test après avoir désactivé le chiffrement
matériel. Mais des expériences supplémentaires sont nécessaires pour le confirmer (les retours sont les bienvenus).
<a id="id-hwsim-details"></a>
## 9.9. Détails du mode Hwsim
**Avertissement** : *ce mode est actuellement expérimental, ne l’utilisez qu’à des fins de recherche.*
Ce mode ne nécessite qu’une seule carte réseau prenant en charge le mode moniteur et, contrairement au mode mixte, la
carte réseau n’a pas besoin de prendre en charge les interfaces virtuelles. L’inconvénient est que dans ce mode, les trames
sont traitées un peu plus lentement, et qu’il n’est pas fiable lorsque la carte réseau n’accuse pas réception des trames :
- En raison du commit 1672c0e31917 (« mac80211: start auth/assoc timeout on frame status »), l’authentification
en tant que client expirera instantanément, ce qui signifie que nous ne pouvons pas utiliser le mode hwsim en tant que client actuellement.
_TODO : Nous devons patcher le noyau pour éviter cette expiration._
- Si nous testons un client qui utilise le commit 1672c0e31917 (« mac80211: start auth/assoc timeout on frame status »),
nous (en tant que point d’accès) devons accuser réception des trames qui nous sont envoyées. Sinon, le client testé ne pourra
pas se connecter.
_TODO : Tester quels appareils accusent réception des trames en mode moniteur, et tester `iw set wlanX monitor active`._
- Certains points d’accès exigeront également que les trames d’authentification et d’association soient acquittées par le client.
Cela signifie que nous (en tant que client) devons à nouveau accuser réception des trames qui nous sont envoyées.
_TODO : Tester quels appareils accusent réception des trames en mode moniteur, et tester `iw set wlanX monitor active`._
- Pour une raison étrange, l’Intel/mvm ne peut pas recevoir les trames de données d’Android/iPhone/iPad
après le 4-way HS ? C’est un bug très étrange. _TODO : Enquêter plus en détail._
Avant d’utiliser ce mode, créez deux cartes réseau virtuelles :
./hwsim.sh
Cela affichera les deux interfaces « hwsim » virtuelles créées, par exemple wlan1 et wlan2. Lors du test
d’un point d’accès dans ce mode, vous devez d’abord rechercher le canal du point d’accès et placer la vraie carte réseau sur
ce canal :
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Pick the channel that the AP is on (in this example 11)
iw wlan0 set channel 11
Ici, wlan0 désigne la carte réseau _réelle_ (et non une interface créée par `hwsim.sh`). Lors du test d’un
client, vous n’avez pas à configurer le canal au préalable (il est tiré de `hostapd.conf`). Vous pouvez maintenant
lancer l’outil de test comme suit :
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
Après l’exécution de l’outil, vous pouvez le relancer directement avec une nouvelle `$COMMAND`.
<a id="id-wpa3-sae"></a>
## 9.10. Test des appareils WPA3 et SAE
Vous pouvez tester un point d’accès WPA3/SAE en ajoutant les deux lignes suivantes dans `client.conf` :
key_mgmt=SAE
ieee80211w=1
Pour tester les clients WPA3/SAE, vous pouvez modifier `hostapd.conf` et définir les paramètres :
wpa_key_mgmt=SAE
ieee80211w=2
Nous avons testé ce qui précède avec un Intel 8265, un Intel 3160, un Netgear WN111v2 (`carl9170`),
un TP-Link TL-WN722N (`ath9k_htc`) et un WNDA3200 (`ath9k_htc`). Avec ces
appareils, j’ai pu me connecter au point d’accès et exécuter quelques tests. Il semble donc
que cela devrait fonctionner avec tous les dongles déjà pris en charge. Notez que je
n’ai pas testé cela en détail : mon hypothèse est que le fait qu’un appareil
fonctionne en mode WPA2 ou WPA3 n’aura pas d’impact sur les résultats des tests.
Le `client.conf` fourni active par défaut à la fois la méthode hunting-and-pecking et
la méthode hash-to-element. Pour configurer un point d’accès prenant en charge hash-to-element (et ainsi
tester les clients WPA3/SAE les plus récents), vous pouvez modifier `hostapd.conf` et définir le paramètre :
sae_pwe=2
En définissant cette valeur, le point d’accès acceptera à la fois la méthode hunting-and-pecking et
la méthode hash-to-element.
<a id="id-live-image"></a>
## 9.11. Image USB live
Téléchargez l’[image USB live](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)
et écrivez-la sur une clé USB en utilisant :
# Unmount in case there's an old partition on the USB
sudo umount /dev/sdb*
# Copy the image
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
Le sha256sum de l’image est `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Remplacez `/dev/sdb`
par votre clé USB. Si vous n’utilisez pas Linux, recherchez en ligne comment écrire une image ISO sur votre clé USB.
Au démarrage de l’image live, cliquez sur « Try Ubuntu » pendant le démarrage. Ouvrez un terminal en cliquant avec le bouton droit sur le
bureau et en sélectionnant « Open in Terminal », puis exécutez :
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
Vous pouvez maintenant exécuter `./fragattacks.py` et suivre les instructions normales de ce README.
N’oubliez pas de désactiver le Wi-Fi avec `nmcli radio wifi off` comme indiqué ci-dessus, sinon le
gestionnaire réseau d’Ubuntu interférera avec l’outil de test. Ce README est également présent
sur l’image live à l’emplacement `~/fragattacks/README.md`.
Notez qu’airmon-ng peut être peu fiable sur l’image live et qu’il est préférable d’utiliser [iw](https://github.com/vanhoefm/fragattacks/issues/36).
<a id="id-design-notes"></a>
# 10. Notes de conception
Les arguments donnés à la commande ping définissent les actions que l’outil de test effectuera
et quand ces actions sont effectuées. Chaque action est séparée par une virgule (`,`). Par défaut,
une action est effectuée après que le client s’est connecté, et dans ce cas une seule lettre représente
quelle action est effectuée. Notez que cela est implémenté dans la fonction
[`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23).
Les actions possibles sont :
- `I` : obtenir une adresse IP. Par défaut, cela est fait en utilisant DHCP, à moins qu’une adresse IP soit explicitement
fournie à l’aide des arguments `--ip` et `--peerip`, auquel cas rien n’est fait.
- `E` : injecter un paquet/fragment chiffré de la requête ping.
- `P` : injecter un paquet/fragment en clair de la requête ping.
- `F` : rafraîchir la clé de session en initiant le 4-way handshake (en tant que point d’accès) ou en attendant le
4-way handshake (en tant que client).
- `R` : laisser le client se reconnecter au réseau.
- `D` : il s’agit d’une « méta-action » spéciale. Traitez-la comme un fragment vide de la requête ping
qui n’est pas réellement envoyé.
S’il n’y a qu’une seule action `E` ou `P`, la requête ping est injectée comme une trame unique.
S’il y a plusieurs actions `E`, `P`, la requête ping est fragmentée, le nombre
de fragments étant égal au nombre d’actions `E` ou `P`. S’il y a l’action spéciale `D`, alors
la requête ping est fragmentée sur les actions `E` ou `P` restantes (voir les exemples dans le tableau).
Ce comportement de fragmentation est implémenté dans la classe [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).
Une lettre peut être placée devant les actions ci-dessus pour modifier le moment où l’action doit être effectuée :
- `S` : l’action est effectuée sur le 1er ou le 2e message du 4-way handshake.
- `B` : l’action est effectuée sur le 3e ou le 4e message du 4-way handshake.
- `A` : l’action est effectuée immédiatement après la fin du 4-way handshake.
- `C` : l’action est effectuée 1 seconde après la fin du 4-way handshake. Le nombre de secondes
à attendre peut être modifié à l’aide du paramètre `--connected-delay`.
Par exemple, consultez les deux tableaux ci-dessus avec les commandes.
<a id="id-change-log"></a>
# 11. Journal des modifications
**Version 1.3.4 (en cours) :** :
- Toujours chiffrer les trames de requête EAPOL (Rekey), même lorsque `--rekey-plaintext` est utilisé.
- Le client accepte désormais les trames EAPOL rejouées. Cela garantit que les rekeys fonctionnent même lorsque le point d’accès testé
implémente incorrectement les rekeys.
- Mise à jour de wpa_supplicant pour réactiver la connexion aux réseaux Enterprise utilisant MS-CHAPv2. Auparavant, lorsque
le système d’exploitation utilise OpenSSL 3.0 ou supérieur, MD4 était désactivé par défaut, ce qui signifiait que MS-CHAPv2 ne pouvait pas être utilisé.
- Ajout du paramètre `--pre-test-delay`. Cela ajoute un délai entre l’obtention d’une adresse IP et la transmission
des premiers fragments/trames. Voir la [pull request](https://github.com/vanhoefm/fragattacks/pull/44) de
Michael Trimarchi et Angelo Compagnucci.
- Mise à jour des pilotes modifiés afin qu’ils compilent également sur le noyau Linux 5.13. Ceci est expérimental.
- Rendu le test d’injection plus fiable en attendant plus longtemps les trames dans le test de réorganisation.
- Apporté plusieurs modifications mineures pour faciliter la compilation du code sur les plateformes plus anciennes (qui ont des versions plus anciennes
de Python et des bibliothèques OpenSSL).
- Mis à jour le README avec un exemple sur la façon d’installer un noyau pris en charge plus ancien sur Ubuntu 20.04. Ajout de
notes de conception. Recommandation désormais de l’AWUS036ACM.
**Version 1.3.3 (11 mai 2021)** :
- Mise à jour des pilotes modifiés afin qu’ils compilent sur les noyaux Linux 5.10, 5.11 et 5.12.
- Mise à jour du firmware pour les appareils `ath9k_htc` (ne devrait avoir aucun impact sur les tests).
- Réorganisation du dépôt pour la version publique. Suppression des documents et diapositives internes pour référencer à la place
les versions publiques de ces documents.
- Prise en charge de base des canaux de 40 MHz lors de l’utilisation du paramètre `--inject-test[-postauth]` pour tester l’injection. Dans les
tests de vulnérabilité réels, l’utilisation de canaux de 40 MHz n’est pas testée (utilisez `disable_ht40` dans `client.conf` si nécessaire).
**Version 1.3.2 (8 mars 2021)** :
- Ajout des [documents de la présentation](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) et d’un
[résumé](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)
de la cause racine et de l’impact de chaque vulnérabilité.
- Mis à jour ce README pour [expliquer](#id-test-sanity) que le paramètre `--icmp-size 100` ou similaire peut être ajouté à
tous les tests qui envoient des trames fragmentées si l’appareil testé n’accepte que des fragments d’une certaine taille minimale.
- Corrigé des fautes de frappe mineures dans ce README.
**Version 1.3.1 (1er mars 2021)** :
- Ajouté le test [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) à ce README. Il injecte un ping en clair
pendant la connexion (c’est-à-dire pendant le 4-way handshake). Les clients et les points d’accès peuvent être vulnérables à cette attaque.
- Mis à jour l’[aperçu des attaques](#id-paper-clarifications) avec de nouveaux exemples sur la façon dont les vulnérabilités d’injection de paquets
peuvent être exploitées en pratique. Cela inclut des techniques pour tromper les clients IPv4-only afin qu’ils utilisent un serveur DNS malveillant
et des techniques pour communiquer directement avec des appareils derrière un NAT/pare-feu (par exemple pour exploiter des services locaux).
- Clarifié que les [tests de fragments broadcast](#id-extended-bcast-check) peuvent être effectués contre les clients et les points d’accès.
- L’outil de test vérifiera désormais si la version attendue de la bibliothèque Python Scapy a été chargée.
- Corrigé certaines références à l’article dans ce README (référence désormais correctement les sections 6.4, 6.6 et 6.8).
- Mise à jour vers la version 3 du brouillon de l’article. Il n’y a pas de changements majeurs par rapport à la version 2 du brouillon, seulement des ajustements mineurs de texte
et de structure. Sur le fond, il s’agit désormais de la version finale de l’article.
**Version 1.3 (20 janvier 2021)** :
- Cette version est basée sur le commit hostap `a337c1d7c` (« New TWT operations and attributes to TWT Setup and Nudge »).
- Ajout d’un [aperçu](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) des attaques et de leurs conditions préalables et création de [ces diapositives](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf)
pour mieux illustrer comment l’attaque d’agrégation (CVE-2020-24588) fonctionne en pratique.
- Ajout d’<a href="#id-wpa3-sae">instructions</a> sur la façon de tester les appareils WPA3/SAE en utilisant soit la méthode hunting-and-pecking,
soit la méthode hash-to-element. Cela implique également que la protection des trames de gestion (MFP) est prise en charge par l’outil de test.
- Ajout d’une clarification à ce README sur la façon d’utiliser tcpdump pour vérifier le résultat de certains tests.
- Ajouté le test supplémentaire `ping BP --bcast-ra --bcast-dst` à ce README pour pouvoir tester CVE-2020-26145
contre des points d’accès qui ne peuvent pas exécuter tcpdump (avec ce test, tcpdump doit être exécuté sur un client connecté indépendant).
- Ajouté les tests supplémentaires `ping I,E,F,E [--rekey-pl] [--rekey-req]` à ce README pour mieux détecter les attaques
de clés mixtes (CVE-2020-24587) sur certains appareils.
- Corrigé l’injection de trames fragmentées lors de l’utilisation de dongles ath9k_htc en combinaison avec 802.11n.
- Le script `pysetup.sh` a été ajouté pour créer l’environnement virtuel Python. Ce script corrige également
[un bug](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) dans la bibliothèque scapy
lorsqu’elle est utilisée avec Python 3.9.
- Les pilotes patchés ont été mis à jour pour compiler correctement sur Linux 5.9.0.
- Corrigé le test `ping-frag-sep`. Auparavant, il se comportait comme `ping-frag-sep --pn-per-qos`. Notez que ce test
n’est pas utilisé pour détecter des vulnérabilités mais seulement pour mieux comprendre les implémentations.
**Version 1.2 (15 novembre 2020)** :
- Cette version (et les versions inférieures) est basée sur le commit hostap `1c67a0760` (« tests: Add basic power saving tests for ap_open »).
- L’outil se termine automatiquement après qu’un test est terminé ou a expiré.
- L’outil détecte si le 4-way handshake boucle ou s’il n’y a pas de réponse à une demande de rekey (`--rekey-req`).
- Lors de l’utilisation d’un serveur DHCP externe, l’outil enverra désormais toujours les trames EAPOL avec comme adresse de destination
le point d’accès (au lieu du serveur DHCP). Ceci est important dans les tests d’attaque à clés mixtes et de cache lors de l’utilisation d’un
serveur DHCP externe.
- Lors du test d’un point d’accès avec `--rekey-req`, l’outil enverra désormais une EAPOL Rekey Request avec un Replay Counter de
un au lieu de zéro.
- La sortie de débogage affiche désormais la clé (de groupe) correcte lors du chiffrement des trames broadcast/multicast. Cela n’influence
aucun résultat de test, cela change uniquement la sortie de l’outil de test.
- Clarifié que toutes les commandes de ce README peuvent tester à la fois les clients et les points d’accès, sauf indication contraire.
- Clarifié la description des attaques de cache, des fragments broadcast et des tests d’attaque A-MSDU EAPOL dans ce README.
- Clarifié qu’il est important de tester à la fois les bandes 2,4 et 5 GHz dans ce README.
**Version 1.1 (20 octobre 2020)** :
- Corrigé un bug où la commande `ping I,E,D` envoyait une requête ping chiffrée normale. Elle envoie désormais une
requête ping chiffrée avec le drapeau More Fragments défini dans l’en-tête.
- Déplacé les commandes `amsdu-inject-[bad]` vers la section 7 de ce README. Elles simulent des attaques réelles et peuvent
être utilisées pour vérifier si les atténuations temporaires fonctionnent (voir la section 7.2 de l’article).
- Corrigé l’orthographe des SPP A-MSDU dans ce README et l’outil de test. Le nouvel argument `--amsdu-spp` est désormais un
synonyme de l’ancien argument `--amsdu-ssp`.
**Version 1.0 (11 août 2020)** :
- Préparé la version initiale pour une utilisation pendant l’embargo.
| Carte réseau | USB | 5GHz | mode mixte | mode injection |
|---|
| Technoethical N150 HGA | Oui | Non | pilote/firmware patché | pilote/firmware patché |
| TP-Link TL-WN722N v1.x | Oui | Non | pilote/firmware patché | pilote/firmware patché |
| Alfa AWUS036NHA | Oui | Non | pilote/firmware patché | pilote/firmware patché |
| Intel Wireless-AC 8265 | Non | Oui | pilote patché | oui |
| Intel Wireless-AC 3160 | Non | Oui | pilote patché | oui |
| Alfa AWUS036ACM | Oui | Oui | pilote patché | oui |
| Netgear WN111v2 | Oui | Non | pilote patché | oui |
| Alfa AWUS036ACH | Oui | Oui | non | oui |
| Commande | Description courte |
|---|
ping | Envoyer un ping normal. |
ping I,E,E | Envoyer un ping fragmenté normal. |
ping I,E,E --delay 5 | Envoyer un ping fragmenté normal avec un délai de 5 secondes entre les fragments. |
ping-frag-sep | Envoyer un ping fragmenté normal avec des fragments séparés par une autre trame. |
ping-frag-sep --pn-per-qos | Identique à ci-dessus, mais fonctionne aussi si la cible n'accepte que des PN consécutifs. |
ping I,E --amsdu | Envoyer un ping encapsulé dans une trame A-MSDU normale (non protégée SPP). |
amsdu-inject | Simuler une attaque : envoyer une trame A-MSDU dont le début est également un en-tête rfc1042 valide. |
amsdu-inject-bad | Identique à ci-dessus, mais contre des cibles qui analysent incorrectement la trame. |
ping I,F,BE,AE | Injecter deux fragments chiffrés avec une clé différente. |
ping I,F,BE,AE --pn-per-qos | Identique à ci-dessus, mais fonctionne aussi si la cible n'accepte que des PN consécutifs. |
ping I,E,R,AE | Injecter un fragment, tenter de déclencher une réassociation, puis injecter le second fragment. |
ping I,E,R,E | Identique à ci-dessus, mais avec un délai plus long avant l'envoi du second fragment. |
ping I,E,R,AE --full-recon | Injecter un fragment, désauthentifier et se reconnecter, puis injecter le second fragment. |
ping I,E,R,E --full-recon | Identique à ci-dessus, mais avec un délai plus long avant l'envoi du second fragment. |
ping I,E,E --inc-pn 2 | Envoyer un ping fragmenté avec des numéros de paquet non consécutifs. |
ping I,E,P | Envoyer un ping fragmenté : premier fragment chiffré, second fragment en clair. |
ping I,P,E | Envoyer un ping fragmenté : premier fragment en clair, second fragment chiffré. |
ping I,P | Envoyer un ping en clair. |
ping I,P,P | Envoyer un ping fragmenté : les deux fragments sont envoyés en clair. |
linux-plain | Attaque de fragmentation mixte clair/chiffré spécifique à Linux. |
ping I,D,P --bcast-ra | Envoyer un ping unicast dans un second fragment diffusé en clair une fois connecté. |
ping D,BP --bcast-ra | Identique à ci-dessus, mais la trame est envoyée pendant la poignée de main à 4 voies (vérifier avec tcpdump). |
eapol-amsdu I,P | Envoyer un A-MSDU en clair contenant une requête ping déguisée en trame EAPOL. |
eapol-amsdu BP | Identique à ci-dessus, mais la trame est envoyée pendant la poignée de main (vérifier avec tcpdump). |
eapol-amsdu-bad I,P | Envoyer un A-MSDU en clair malformé contenant une requête ping déguisée en trame EAPOL. |
eapol-amsdu-bad BP | Identique à ci-dessus, mais la trame est envoyée pendant la connexion (vérifier avec tcpdump). |
Dans l'ensemble, il peut être fastidieux de tester si un appareil est vulnérable aux attaques par cache. Je recommande donc aussi de réaliser un audit du code pour vérifier si les fragments restent en mémoire après une dissociation ou une désauthentification d'un réseau, ou après une réassociation (cela peut aussi être vérifié dynamiquement à l'aide de prints de débogage). Si les fragments restent en mémoire, vous devez considérer cela comme un risque, même si l'on ne sait pas si cela peut être exploité. Cela revient à savoir qu'une implémentation a un débordement de tampon sans (encore) savoir comment l'exploiter.
Exécutez l'outil avec le paramètre supplémentaire --debug 2 pour obtenir des sorties de débogage supplémentaires de wpa_supplicant ou
hostapd et de l'outil de test lui-même.
Confirmez à l'aide d'une seconde interface moniteur qu'aucune autre trame n'est envoyée entre les fragments. Par exemple, j'ai constaté que mon appareil Intel envoie parfois des trames Block Ack Response Action entre les fragments, ce qui interférait avec le processus de défragmentation de l'appareil testé.
Revérifiez que vous utilisez un firmware modifié si nécessaire pour votre carte réseau sans fil. L'outil
de test vérifie déjà cela automatiquement pour les appareils ath9k_htc. L'outil de test vérifie également automatiquement
si vous utilisez des pilotes modifiés, même s'il peut être bon de revérifier manuellement cela sur votre
distribution Linux spécifique.
Il peut être utile d'ajouter un délai entre l'obtention de l'adresse IP et la transmission du premier fragment/première trame.
Pour ce faire, utilisez le paramètre --pre-test-delay.
| Commande | Description courte |
|---|
ping I,E --amsdu-fake | Si ce test réussit, l'indicateur A-MSDU est ignoré (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | Vérifie si l'indicateur A-MSDU est authentifié mais ensuite ignoré (§3.5). |
ping I,F,BE,E | Si la nouvelle clé est installée relativement tard. |
ping I,E,F,AE | Variante si aucune trame de données n'est acceptée pendant le handshake de renouvellement de clé. |
ping I,E,F,AE --rekey-plain | Si l'appareil effectue le handshake de renouvellement de clé en clair. |
ping I,E,F,AE --rekey-plain --rekey-req | Comme ci-dessus, et demander activement un renouvellement de clé en tant que client. |
ping I,E,F,AE --rekey-early-install | Installe la nouvelle clé après l'envoi du message 3 du handshake à 4 voies. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | Comme les 4 tests ci-dessus, mais avec un délai plus long avant le 2e fragment. |
ping I,F,BE,AE --freebsd | Attaque à clé mixte contre FreeBSD ou des implémentations similaires. |
ping I,E,R,AE --freebsd [--full-reconnect] | Attaque par cache spécifique aux implémentations FreeBSD. |
ping I,E,R,AP --freebsd [--full-reconnect] | Attaque par cache spécifique aux implémentations FreeBSD. |
ping I,E,R,AP [--full-reconnect] | Test d'attaque par cache où le 2e fragment est envoyé en clair. |
ping I,E,E --amsdu | Envoie un ping normal sous forme de trame A-MSDU fragmentée. |
ping I,E,P,E | Ping avec 1er fragment chiffré, 2e en clair, 3e chiffré. |
linux-plain 3 | Comme linux-plain mais le fragment leurre est envoyé avec la priorité QoS 3. |
ping I,P --bcast-ra | Ping dans une trame de diffusion en clair après le handshake à 4 voies. |
ping BP --bcast-ra [--bcast-dst] | Ping dans une trame de diffusion en clair pendant le handshake à 4 voies (utiliser tcpdump). |
ping BP [--bcast-dst] | Ping dans une trame en clair pendant le handshake à 4 voies (utiliser tcpdump). |
eapfrag BP,BP | Attaque expérimentale par fragments de diffusion (utiliser tcpdump). |
eapol-amsdu[-bad] BP --bcast-dst | Comme eapol-amsdu BP mais plus facile à vérifier contre les AP (utiliser tcpdump). |
eapol-inject 00:11:22:33:44:55 | Teste si l'AP transmet des trames EAPOL avant d'être authentifié (utiliser tcpdump). |
eapol-inject-large 00:11:22:33:44:55 | Fait envoyer à l'AP des trames fragmentées par injection EAPOL (utiliser tcpdump). |
ping I,D,E | Envoie un ping dans un second fragment chiffré (pas de 1er fragment). |
ping I,E,D | Envoie un ping dans un premier fragment chiffré (pas de 2e fragment). |
--rekey-pl--rekey-plainframe contains "test_ping_icmp"eapfrag BP,AE