Script per verificare client WPA2 e AP per le vulnerabilità di reinstallazione della chiave KRACK utilizzando hostapd modificato e replay dei frame in modalità monitor.
This project contains scripts to test if clients or access points (APs) are affected by the KRACK attack against WPA2. For details behind this attack see our website and the research paper.
Remember that our scripts are not attack scripts! You will need the appropriate network credentials in order to test if an access point or client is affected by the KRACK attack.
Dicembre 2024: è stato corretto un bug nel settimo test ./krack-test-client.py --gtkinit. Prima di questa correzione, veniva indicato che (l'output di) questo test era inaffidabile, ma ora l'output dovrebbe essere attendibile seguendo le nuove istruzioni. In altre parole, quando questo test ora indica che il dispositivo è vulnerabile, è effettivamente probabile che lo sia.
Gennaio 2021: gli script sono stati resi compatibili con Python3 e sono stati aggiornati per supportare meglio le distribuzioni Linux più recenti. Se vuoi tornare alla vecchia versione, esegui git fetch --tags && git checkout v1 dopo aver clonato il repository (e torna all'ultima versione usando git checkout research).
I nostri script sono stati testati su Kali Linux. Per installare le dipendenze richieste su Kali, esegui:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw
Ora compila la nostra istanza modificata di hostapd e crea un ambiente virtuale python. Questo garantisce che tu stia usando librerie python compatibili (quelle elencate in krackattack/requirements.txt):
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh
Quindi disabilita la crittografia hardware per ottenere risultati ottimali:
cd krackattack
sudo ./disable-hwcrypto.sh
Nota che se necessario puoi successivamente riabilitare la crittografia hardware usando lo script sudo ./reenable-hwcrypto.sh. Si consiglia di riavviare dopo aver disabilitato la crittografia hardware. Abbiamo testato i nostri script con una Intel Dual Band Wireless-AC 7260 e una TP-Link TL-WN722N v1 su Kali Linux.
Ogni volta, prima di usare gli script, devi disabilitare il Wi-Fi nel tuo gestore di rete. Quindi esegui:
sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate
Dopo aver fatto questo, puoi eseguire gli script più volte finché non chiudi il terminale.
Se vuoi annullare gli effetti di disable-hwcrypto.sh, elimina il file /etc/modprobe.d/nohwcrypt.conf.
Per prima cosa modifica hostapd/hostapd.conf e modifica la riga interface= per specificare l'interfaccia Wi-Fi che verrà usata per eseguire i test. Nota che per tutti i test, una volta che lo script è in esecuzione, devi far connettere il dispositivo in test all'SSID testnetwork usando la password abcdefgh. Puoi modificare le impostazioni dell'AP modificando hostapd/hostapd.conf. In tutti i test il client deve usare DHCP per ottenere un IP dopo essersi connesso alla rete Wi-Fi. Questo perché alcuni test iniziano solo dopo che il client ha richiesto un IP tramite DHCP!
Dovresti ora eseguire i seguenti test situati nella directory krackattacks/:
./krack-test-client.py --replay-broadcast. Verifica se il client accetta frame broadcast replicati. Se il client accetta frame broadcast replicati, questo deve essere corretto prima. Se non correggi il client, il nostro script non sarà in grado di determinare se la chiave di gruppo viene reinstallata (perché allora lo script dirà sempre che la chiave di gruppo viene reinstallata).
./krack-test-client.py --group --gtkinit. Verifica se il client installa la chiave di gruppo nell'handshake della chiave di gruppo con il contatore di sequenza di ricezione (RSC) fornito. Vedi la sezione 6.4 del nostro articolo di ricerca successivo per i dettagli su questa vulnerabilità.
./krack-test-client.py --group. Verifica se il client reinstalla la chiave di gruppo nell'handshake della chiave di gruppo. In altre parole, verifica se il client è vulnerabile a CVE-2017-13080. Lo script verifica le reinstallazioni della chiave di gruppo inviando richieste ARP broadcast al client usando un numero di pacchetto già usato (replicato) (qui numero di pacchetto = nonce = IV). Nota che se il client accetta sempre frame broadcast replicati (vedi --replay-broadcast), questo test potrebbe concludere erroneamente che la chiave di gruppo viene reinstallata.
./krack-test-client.py. Verifica le reinstallazioni delle chiavi nell'handshake a 4 vie inviando ripetutamente messaggi 3 cifrati al client. In altre parole, verifica CVE-2017-13077 (la vulnerabilità con il maggiore impatto) e CVE-2017-13078. Lo script monitora il traffico inviato dal client per vedere se la chiave pairwise viene reinstallata. Nota che questo esegue effettivamente due test: se la chiave pairwise viene reinstallata e se la chiave di gruppo viene reinstallata. Assicurati che il client richieda un IP tramite DHCP per avviare il test di reinstallazione della chiave di gruppo. Per assicurarti che il client stia inviando abbastanza frame unicast, puoi facoltativamente fare ping all'AP: ping 192.168.100.254.
./krack-test-client.py --tptk. Identico al test 4, tranne per il fatto che un messaggio 1 contraffatto viene iniettato prima di inviare il messaggio 3 cifrato. Questa variante del test è importante perché alcuni client (ad es. wpa_supplicant v2.6) sono vulnerabili alle reinstallazioni della chiave pairwise nell'handshake a 4 vie solo quando un messaggio 1 contraffatto viene iniettato prima di inviare un messaggio 3 ritrasmesso.
./krack-test-client.py --tptk-rand. Come il test precedente, tranne per il fatto che il messaggio 1 contraffatto contiene un ANonce casuale.
./krack-test-client.py --gtkinit. Verifica se il client installa la chiave di gruppo nell'handshake a 4 vie con il contatore di sequenza di ricezione (RSC) fornito. Questo viene fatto ritrasmettendo Msg3/4 dell'handshake a 4 vie, ogni volta con una nuova chiave di gruppo e un contatore di replay molto alto. Sappiamo che è vulnerabile se il client in test successivamente accetta frame broadcast con un contatore di replay più basso. Purtroppo alcuni client non accettano affatto Msg3/4 ritrasmessi, il che significa che tali client non possono essere testati con questo comando. I client che accettano un Msg3/4 ritrasmesso, e che quindi possono essere testati con questo comando, risponderanno con un Msg4/4 che può essere rilevato in base al seguente output:
[09:24:11] 02:20:2a:22:a8:30: received a new message 4
Raccomandiamo anche di eseguire questo test in ambienti con poco rumore di fondo e di eseguirlo più volte.
Alcune osservazioni aggiuntive:
Il test più importante è ./krack-test-client, che verifica le reinstallazioni ordinarie delle chiavi nell'handshake a 4 vie.
Esegui questi test in una stanza con poche interferenze. Un'elevata quantità di perdita di pacchetti renderà questo script meno affidabile!
Facoltativamente puoi ispezionare manualmente il traffico di rete per confermare l'output dello script (alcune schede Wi-Fi potrebbero interferire con i nostri script):
Usa una scheda Wi-Fi aggiuntiva in modalità monitor per confermare che il nostro script (l'AP) invii frame usando i numeri di pacchetto (IV) corretti. In particolare, verifica se i frame broadcast replicati vengono effettivamente inviati usando un numero di pacchetto (IV) già usato.
Usa una scheda Wi-Fi aggiuntiva in modalità monitor per verificare le reinstallazioni della chiave pairwise monitorando gli IV dei frame inviati dal client.
Cattura il traffico sul client per vedere se le richieste ARP broadcast replicate vengono accettate o meno.