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).

Prerequisiti

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.

Prima di ogni utilizzo

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.

Test dei Client

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/:

1. ./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).

2. ./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à.

3. ./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.

4. ./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: .

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.

• Se il client può usare più radio/schede Wi-Fi, esegui il test usando diverse schede Wi-Fi.

• Puoi aggiungere il parametro --debug per un output di debug più dettagliato.

• Tutti i parametri non riconosciuti vengono passati a hostapd, quindi puoi includere qualcosa come -dd -K per far sì che hostapd emetta tutte le informazioni di debug.

Corrispondenza con i test della Wi-Fi Alliance

La Wi-Fi Alliance ha creato uno strumento personalizzato di rilevamento delle vulnerabilità basato sui nostri script. Al momento della scrittura, questo strumento è accessibile solo ai membri della Wi-Fi Alliance. I loro strumenti supportano diversi test, e questi test corrispondono alle funzionalità dei nostri script come segue:

• 4.1.1 (Ritrasmissione in chiaro del messaggio 3 EAPOL). Attualmente non supportiamo questo test. Questo test non è comunque necessario. Assicurati che il dispositivo in test superi il test 4.1.3, e poi supererà anche questo test.

• 4.1.2 (Ritrasmissione immediata di EAPOL M3 in chiaro). Attualmente non supportiamo questo test. Ancora una volta, assicurati che il dispositivo in test superi il test 4.1.3, e poi supererà anche questo test.

• 4.1.3 (Ritrasmissione immediata di EAPOL M3 cifrato durante l'handshake di rekey pairwise). Questo corrisponde a ./krack-test-client.py, tranne per il fatto che gli EAPOL M3 cifrati vengono inviati periodicamente invece che immediatamente.

• 4.1.5 (Reinstallazione della PTK nell'handshake a 4 vie quando la STA usa la costruzione temporale della PTK, stesso ANonce). Esegui questo test usando ./krack-test-client.py --tptk.

• 4.1.6 (Reinstallazione della PTK nell'handshake a 4 vie quando la STA usa la costruzione temporale della PTK, ANonce casuale). Esegui questo test usando ./krack-test-client.py --tptk-rand.

• 4.2.1 (Test della vulnerabilità dell'handshake della chiave di gruppo sulla STA). Esegui questo test usando ./krack-test-client.py --group.

• 4.3.1 (Reinstallazione di GTK e IGTK su STA con supporto alla modalità sleep WNM). Attualmente non supportiamo questo test (e in realtà nemmeno la Wi-Fi Alliance lo supporta!).

Test degli Access Point: Rilevamento di un handshake FT vulnerabile (802.11r)

1. Crea un file di configurazione wpa_supplicant che possa essere usato per connettersi alla rete. Un esempio di base è:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

Nota l'uso di "FT-PSK". Salvalo come network.conf o simile. Per maggiori informazioni vedi wpa_supplicant.conf.

2. Prova a connetterti alla rete usando il wpa_supplicant della tua piattaforma. Probabilmente richiederà un comando come:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

Se questo fallisce, o l'AP non supporta FT, oppure hai fornito opzioni di configurazione di rete errate al punto 1. Nota che se l'AP non supporta FT, non è affetto da questa vulnerabilità.

3. Usa questo script come wrapper per il precedente comando wpa_supplicant:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

Questo eseguirà il comando wpa_supplicant usando i parametri forniti e aggiungerà un'interfaccia di monitoraggio virtuale che eseguirà i test di attacco. È importante diventare prima root e poi caricare l'ambiente virtuale python (vedi sopra come creare questo ambiente virtuale).

4. Usa wpa_cli per fare roaming verso un AP diverso della stessa rete. Per esempio:

   root@kitploit:~

    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
    ...
   

In questo esempio eravamo connessi all'AP c4:e9:84:db:fb:7b della testnet (vedi comando status). Il comando scan_results mostra che questa rete ha anche un secondo AP con MAC c4:e9:84:1d:a5:bc. Successivamente facciamo roaming verso questo secondo AP.

5. Genera traffico tra l'AP e il client. Per esempio:

   root@kitploit:~

    arping -I wlan0 192.168.1.10
   

6. Ora guarda l'output di ./krack-ft-test.py per vedere se l'AP è vulnerabile.

   1. Prima dovrebbe dire "Detected FT reassociation frame". Poi inizierà a replicare questo frame per tentare l'attacco.
   2. Lo script mostra quali IV (= numeri di pacchetto) l'AP sta usando quando invia frame di dati.
   3. Il messaggio IV reuse detected (IV=X, seq=Y). AP is vulnerable! significa che abbiamo confermato che è vulnerabile.

Assicurati anche di controllare manualmente le tracce di rete, per confermare che questo script stia replicando correttamente la richiesta di riassociazione, e per confermare manualmente se c'è riuso di IV (= numero di pacchetto) o meno.

Esempio di output di un AP vulnerabile:

[15:59:24] Replaying Reassociation Request
[15:59:25] AP transmitted data using IV=1 (seq=0)
[15:59:25] Replaying Reassociation Request
[15:59:26] AP transmitted data using IV=1 (seq=0)
[15:59:26] IV reuse detected (IV=1, seq=0). AP is vulnerable!

Esempio di output di un AP corretto (nota che gli IV non vengono mai riusati):

[16:00:49] Replaying Reassociation Request
[16:00:49] AP transmitted data using IV=1 (seq=0)
[16:00:50] AP transmitted data using IV=2 (seq=1)
[16:00:50] Replaying Reassociation Request
[16:00:51] AP transmitted data using IV=3 (seq=2)
[16:00:51] Replaying Reassociation Request
[16:00:52] AP transmitted data using IV=4 (seq=3)

Extra: Decrittazione Hardware

Per confermare che la decrittazione hardware sia disabilitata, esegui systool -vm ath9k_htc o simile dopo aver collegato la tua scheda Wi-Fi per confermare che il parametro nohwcript/swcrypto/hwcrypto sia stato impostato. Nota che devi sostituire ath9k_htc con il modulo del kernel per la tua scheda di rete wireless.

Extra: 5 GHz non supportato

Non c'è supporto ufficiale per testare dispositivi nella banda dei 5 GHz.

Se tuttavia vuoi usare lo strumento su canali a 5 GHz, la scheda di rete usata deve consentire l'iniezione di frame nel canale a 5 GHz. Sfortunatamente, questo non è sempre possibile a causa dei vincoli normativi. Per vedere su quali canali puoi iniettare frame puoi eseguire iw list e cercare sotto Frequencies i canali che non sono contrassegnati come disabilitati, no IR, o radar detection. Nota che queste condizioni possono dipendere dalla tua scheda di rete, dal paese attualmente configurato e dall'AP a cui sei connesso. Per maggiori informazioni vedi, ad esempio, la documentazione di Arch Linux.

Nota che il kernel Linux potrebbe non consentire l'iniezione di frame anche se è consentito inviare frame normali. Questo perché nella funzione ieee80211_monitor_start_xmit il kernel rifiuta di iniettare frame quando cfg80211_reg_can_beacon restituisce false. Di conseguenza, Linux potrebbe rifiutare di iniettare frame anche se in realtà è consentito. Far sì che cfg80211_reg_can_beacon restituisca true nelle condizioni corrette (o in tutte) previene questo bug. Quindi dovrai modificare i driver Linux in modo che cfg80211_reg_can_beacon restituisca sempre true, ad esempio modificando manualmente il codice del driver packport.

Extra: Test Manuali

È anche possibile eseguire manualmente test (più dettagliati) clonando il repository git di hostap:

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

E seguendo le istruzioni in tests/cipher-and-key-mgmt-testing.txt.