Ce projet contient des scripts pour tester si les clients ou points d'accès (AP) sont affectés par l'attaque KRACK contre WPA2. Pour plus de détails sur cette attaque, consultez notre site web et l'article de recherche.

Rappelez-vous que nos scripts ne sont pas des scripts d'attaque ! Vous aurez besoin des identifiants réseau appropriés pour tester si un point d'accès ou un client est affecté par l'attaque KRACK.

Décembre 2024 : un bug a été corrigé dans le 7ème test ./krack-test-client.py --gtkinit. Avant cette correction, il était mentionné que (la sortie de) ce test n'était pas fiable, mais maintenant la sortie devrait être digne de confiance lorsque l'on suit les nouvelles instructions. C'est-à-dire que lorsque ce test indique désormais que l'appareil est vulnérable, il est effectivement probablement vulnérable.

Janvier 2021 : les scripts ont été rendus compatibles avec Python3 et ont été mis à jour pour mieux prendre en charge les distributions Linux récentes. Si vous souhaitez revenir à l'ancienne version, exécutez git fetch --tags && git checkout v1 après avoir cloné le dépôt (puis revenez à la dernière version en utilisant git checkout research).

Prérequis

Nos scripts ont été testés sur Kali Linux. Pour installer les dépendances requises sur Kali, exécutez :

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

Maintenant, compilez notre instance hostapd modifiée et créez un environnement virtuel python. Cela garantit que vous utilisez des bibliothèques python compatibles (celles listées dans krackattack/requirements.txt) :

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

Ensuite, désactivez le chiffrement matériel pour des résultats optimaux :

cd krackattack
sudo ./disable-hwcrypto.sh

Notez que si nécessaire, vous pouvez réactiver plus tard le chiffrement matériel en utilisant le script sudo ./reenable-hwcrypto.sh. Il est recommandé de redémarrer après avoir désactivé le chiffrement matériel. Nous avons testé nos scripts avec un Intel Dual Band Wireless-AC 7260 et un TP-Link TL-WN722N v1 sur Kali Linux.

Avant chaque utilisation

Chaque fois avant d'utiliser les scripts, vous devez désactiver le Wi-Fi dans votre gestionnaire de réseau. Ensuite, exécutez :

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

Après cela, vous pouvez exécuter les scripts plusieurs fois tant que vous ne fermez pas le terminal.

Si vous souhaitez annuler les effets de disable-hwcrypto.sh, supprimez le fichier /etc/modprobe.d/nohwcrypt.conf.

Tester les clients

Modifiez d'abord hostapd/hostapd.conf et éditez la ligne interface= pour spécifier l'interface Wi-Fi qui sera utilisée pour exécuter les tests. Notez que pour tous les tests, une fois le script en cours d'exécution, vous devez laisser l'appareil testé se connecter au SSID testnetwork en utilisant le mot de passe abcdefgh. Vous pouvez modifier les paramètres du point d'accès en modifiant hostapd/hostapd.conf. Dans tous les tests, le client doit utiliser DHCP pour obtenir une adresse IP après s'être connecté au réseau Wi-Fi. Cela est dû au fait que certains tests ne démarrent qu'après que le client a demandé une adresse IP via DHCP !

Vous devez maintenant exécuter les tests suivants situés dans le répertoire krackattacks/ :

./krack-test-client.py --replay-broadcast. Ce test vérifie si le client accepte les trames broadcast rejouées. Si le client accepte les trames broadcast rejouées, cela doit être corrigé en premier. Si vous ne corrigez pas le client, notre script ne pourra pas déterminer si la clé de groupe est en cours de réinstallation (car le script dira alors toujours que la clé de groupe est en cours de réinstallation).
./krack-test-client.py --group --gtkinit. Ce test vérifie si le client installe la clé de groupe dans la poignée de main de clé de groupe avec le compteur de séquence de réception (RSC) donné. Voir la section 6.4 de notre article de recherche de suivi pour les détails de cette vulnérabilité.
./krack-test-client.py --group. Ce test vérifie si le client réinstalle la clé de groupe dans la poignée de main de clé de groupe. En d'autres termes, il teste si le client est vulnérable à CVE-2017-13080. Le script teste les réinstallations de la clé de groupe en envoyant des requêtes ARP broadcast au client en utilisant un numéro de paquet déjà utilisé (rejoué) (ici numéro de paquet = nonce = IV). Notez que si le client accepte toujours les trames broadcast rejouées (voir --replay-broadcast), ce test pourrait conclure à tort que la clé de groupe est en cours de réinstallation.
./krack-test-client.py. Ce test vérifie les réinstallations de clé dans la poignée de main à 4 voies en envoyant à plusieurs reprises des messages 3 chiffrés au client. En d'autres termes, il teste CVE-2017-13077 (la vulnérabilité ayant le plus grand impact) et CVE-2017-13078. Le script surveille le trafic envoyé par le client pour voir si la clé par paire est en cours de réinstallation. Notez que cela effectue en réalité deux tests : si la clé par paire est réinstallée, et si la clé de groupe est réinstallée. Assurez-vous que le client demande une adresse IP via DHCP pour que le test de réinstallation de la clé de groupe démarre. Pour garantir que le client envoie suffisamment de trames unicast, vous pouvez éventuellement pinger le point d'accès : .

Quelques remarques supplémentaires :

Le test le plus important est ./krack-test-client, qui teste les réinstallations ordinaires de clé dans la poignée de main à 4 voies.
Effectuez ces tests dans une pièce avec peu d'interférences. Un taux élevé de perte de paquets rendra ce script moins fiable !
Vous pouvez éventuellement inspecter manuellement le trafic réseau pour confirmer la sortie du script (certaines cartes Wi-Fi peuvent interférer avec nos scripts) :
- Utilisez une carte Wi-Fi supplémentaire en mode moniteur pour confirmer que notre script (le point d'accès) envoie des trames avec les numéros de paquet (IV) appropriés. En particulier, vérifiez si les trames broadcast rejouées sont bien envoyées avec un numéro de paquet (IV) déjà utilisé.
- Utilisez une carte Wi-Fi supplémentaire en mode moniteur pour vérifier les réinstallations de la clé par paire en surveillant les IV des trames envoyées par le client.
- Capturez le trafic sur le client pour voir si les requêtes ARP broadcast rejouées sont acceptées ou non.
Si le client peut utiliser plusieurs radios/cartes Wi-Fi, effectuez le test en utilisant plusieurs cartes Wi-Fi.
Vous pouvez ajouter le paramètre --debug pour plus de sortie de débogage.
Tous les paramètres non reconnus sont transmis à hostapd, vous pouvez donc inclure quelque chose comme -dd -K pour que hostapd affiche toutes les informations de débogage.

Correspondance avec les tests de la Wi-Fi Alliance

La Wi-Fi Alliance a créé un outil de détection de vulnérabilités personnalisé basé sur nos scripts. Au moment de la rédaction, cet outil n'est accessible qu'aux membres de la Wi-Fi Alliance. Leurs outils prennent en charge plusieurs tests différents, et ces tests correspondent aux fonctionnalités de notre script comme suit :

4.1.1 (Retransmission en clair du message EAPOL 3). Nous ne prenons actuellement pas en charge ce test. Ce test n'est de toute façon pas nécessaire. Assurez-vous que l'appareil testé réussit le test 4.1.3, et il réussira également ce test.
4.1.2 (Retransmission immédiate d'EAPOL M3 en clair). Nous ne prenons actuellement pas en charge ce test. Encore une fois, assurez-vous que l'appareil testé réussit le test 4.1.3, et il réussira également ce test.
4.1.3 (Retransmission immédiate d'EAPOL M3 chiffré pendant la poignée de main de renouvellement de clé par paire). Cela correspond à ./krack-test-client.py, sauf que les EAPOL M3 chiffrés sont envoyés périodiquement au lieu d'immédiatement.
4.1.5 (Réinstallation du PTK dans la poignée de main à 4 voies lorsque la STA utilise la construction de PTK temporel, même ANonce). Exécutez ce test en utilisant ./krack-test-client.py --tptk.
4.1.6 (Réinstallation du PTK dans la poignée de main à 4 voies lorsque la STA utilise la construction de PTK temporel, ANonce aléatoire). Exécutez ce test en utilisant ./krack-test-client.py --tptk-rand.
4.2.1 (Test de vulnérabilité de la poignée de main de clé de groupe sur la STA). Exécutez ce test en utilisant ./krack-test-client.py --group.
4.3.1 (Réinstallation de GTK et IGTK sur une STA prenant en charge le mode veille WNM). Nous ne prenons actuellement pas en charge ce test (et la Wi-Fi Alliance non plus, en fait !).

Tester les points d'accès : Détection d'une poignée de main FT vulnérable (802.11r)

Créez un fichier de configuration wpa_supplicant qui peut être utilisé pour se connecter au réseau. Un exemple de base est :
```
 ctrl_interface=/var/run/wpa_supplicant
 network={
   ssid="testnet"
   key_mgmt=FT-PSK
   psk="password"
 }
```
Notez l'utilisation de "FT-PSK". Enregistrez-le sous network.conf ou similaire. Pour plus d'informations, consultez wpa_supplicant.conf.
Essayez de vous connecter au réseau en utilisant le wpa_supplicant de votre plateforme. Cela nécessitera probablement une commande telle que :
```
 sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
```
Si cela échoue, soit le point d'accès ne prend pas en charge FT, soit vous avez fourni de mauvaises options de configuration réseau à l'étape 1. Notez que si le point d'accès ne prend pas en charge FT, il n'est pas affecté par cette vulnérabilité.
Utilisez ce script comme wrapper autour de la commande wpa_supplicant précédente :
```
 sudo su
 source venv/bin/activate
 ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
```
Ceci exécutera la commande wpa_supplicant avec les paramètres fournis, et ajoutera une interface de surveillance virtuelle qui effectuera des tests d'attaque. Il est important de devenir d'abord root puis de charger l'environnement virtuel python (voir ci-dessus comment créer cet environnement virtuel).

Utilisez wpa_cli pour effectuer un roaming vers un autre point d'accès du même réseau. Par exemple :

 wpa_cli -i wlan0
 > status
 bssid=c4:e9:84:db:fb:7b
 ssid=testnet
 ...
 > scan_results 
 bssid / frequency / signal level / flags / ssid
 c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
 c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
 ...
 > roam c4:e9:84:1d:a5:bc
 ...

Supplément : Déchiffrement matériel

Pour confirmer que le déchiffrement matériel est désactivé, exécutez systool -vm ath9k_htc ou similaire après avoir branché votre carte Wi-Fi pour confirmer que le paramètre nohwcript/swcrypto/hwcrypto a été défini. Notez que vous devez remplacer ath9k_htc par le module noyau de votre carte réseau sans fil.

Supplément : 5 GHz non pris en charge

Il n'y a pas de support officiel pour tester les appareils dans la bande 5 GHz.

Si vous souhaitez néanmoins utiliser l'outil sur les canaux 5 GHz, la carte réseau utilisée doit permettre l'injection de trames sur 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, vous pouvez exécuter iw list et chercher dans Frequencies les canaux qui ne sont pas marqués comme disabled, no IR, ou radar detection. Notez que ces conditions peuvent dépendre de votre carte réseau, du pays actuellement configuré et du point d'accès auquel vous êtes connecté. Pour plus d'informations, voir par exemple la documentation Arch Linux.

Notez que le noyau Linux peut ne pas autoriser l'injection de trames même s'il est autorisé à 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 false. Par conséquent, Linux peut refuser d'injecter des trames même si cela est en réalité autorisé. Faire en sorte que cfg80211_reg_can_beacon renvoie true dans les conditions correctes (ou toutes) empêche ce bug. Vous devrez donc patcher les pilotes Linux pour que cfg80211_reg_can_beacon renvoie toujours true, par exemple en patchant manuellement le code du pilote packport.

Supplément : Tests manuels

Il est également possible d'effectuer manuellement des tests (plus détaillés) en clonant le dépôt git hostap :

git clone git://w1.fi/srv/git/hostap.git

Et en suivant les instructions dans tests/cipher-and-key-mgmt-testing.txt.

krackattacks-scripts

Populaires