vanhoefm/fragattacksTester automatico di vulnerabilità per client Wi-Fi e punti di accesso, che rileva i difetti di frammentazione/aggregazione di FragAttacks tramite iniezione di frame, test in modalità mista e analisi della cattura dei pacchetti.
Questo repository contiene il tool FragAttacks. Può testare client Wi-Fi e punti di accesso per attacchi di frammentazione e aggregazione. Queste vulnerabilità riguardano tutte le reti Wi-Fi protette. Per maggiori informazioni su queste vulnerabilità, consulta fragattacks.com.
Sono disponibili le seguenti risorse aggiuntive:
Consulta il registro delle modifiche per una panoramica dettagliata degli aggiornamenti al tool apportati dall'11 agosto 2020. Questo registro delle modifiche contiene anche informazioni sulla versione di hostap su cui si basa il tool FragAttacks.
Nota che gli attacchi sono identici contro WPA2 e WPA3 perché i loro cifrari di crittografia CCMP e GCMP sono identici. Le reti WPA più vecchie utilizzano per impostazione predefinita TKIP per la crittografia, e l'applicabilità degli attacchi contro TKIP è discussa nell'articolo e sul sito web. Per illustrare che il Wi-Fi è vulnerabile sin dalla sua creazione, l'articolo e il sito web discutono brevemente anche l'applicabilità degli attacchi contro WEP.
Sono supportate solo specifiche schede di rete wireless. Questo perché alcune schede di rete potrebbero sovrascrivere il numero di sequenza o di frammento dei frame iniettati, oppure riordinare frame di priorità diverse, e questo interferisce con il tool di test (cioè il tool potrebbe affermare che un dispositivo è sicuro anche se non lo è). Ho confermato che le seguenti schede di rete funzionano correttamente:
Le ultime due colonne indicano:
Modalità mista: se la scheda di rete può essere usata nella modalità mista consigliata.
Modalità di iniezione: se la scheda di rete può essere usata come seconda interfaccia per iniettare frame in modalità di iniezione.
Sì indica che la scheda funziona immediatamente nella modalità indicata. Driver/firmware patchato significa che la scheda è compatibile se usata con driver e/o firmware patchati. No significa che questa modalità non è supportata dalla scheda di rete. Consiglio di usare il tool di test in modalità mista.
Nota che i dispositivi USB possono essere usati all'interno di una macchina virtuale, e i driver e/o firmware modificati possono essere installati in questa macchina virtuale. Tuttavia, ho riscontrato che l'uso di macchine virtuali può rendere le schede di rete meno affidabili, e raccomando invece l'uso di un'immagine USB live se non puoi installare i driver/firmware modificati nativamente.
La mia esperienza con le schede di rete sopra elencate si trova qui. In sintesi:
L'AWUS036ACM in modalità mista sembra affidabile con i nostri ultimi driver ed è quello che raccomando. Un dispositivo più economico ma quasi identico è uno con chipset MT7612U. Vedi maggiori informazioni qui.
In precedenza raccomandavo il Technoethical N150 HGA in modalità mista. Questo dongle è identico al TP-Link TL-WN722N v1.x e richiede l'uso di driver e firmware patchati. È uno dei dongle più testati, ma è difficile da reperire. Ecco perché ora raccomando invece l'AWUS036ACM.
Le Intel 3160 e 8265 sono supportate e ampiamente testate. A volte il loro firmware si è bloccato, ma un riavvio rende di nuovo utilizzabile la scheda di rete. La Intel AX200 non è compatibile con il tool di test.
La WN111v2 sembra funzionare bene, anche se non l'ho testata estesamente.
Il driver per l'AWUS036ACH non fa parte del kernel Linux e richiede l'installazione di un driver separato. Su Kali puoi installare questo driver tramite il gestore dei pacchetti. Questa scheda non è stata testata estesamente.
Se non riesci a trovare una delle schede di rete sopra elencate, puoi cercare schede di rete alternative che hanno un'alta probabilità di funzionare. Quando usi una scheda di rete non esplicitamente supportata, raccomando vivamente di eseguire prima i test di iniezione prima di usarla, e di usare il tool contro un'implementazione nota per essere vulnerabile per confermare che il tool funzioni correttamente.
Il tool di test è stato testato su Ubuntu 20.04 usando il kernel 5.8. Se usi un'altra distribuzione Linux, nota che sono supportate solo versioni del kernel inferiori o uguali alla 5.12.
Quando usi Ubuntu 20.04, devi prima installare il kernel 5.8 come segue. Nota che il tuo kernel esistente continuerà a essere installato e continuerà anche a essere usato per impostazione predefinita:
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
Ora riavvia Ubuntu, tieni premuto il tasto Shift durante l'avvio, seleziona "Opzioni avanzate per Ubuntu", e poi avvia il kernel 5.8 scegliendo "Ubuntu, with Linux 5.8.0-63-generic". Puoi modificare la tua configurazione GRUB in modo che Ubuntu usi questa versione del kernel per impostazione predefinita. Continua con le istruzioni successive con questo kernel ora in esecuzione.
Installa le dipendenze richieste:
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
Ora clona questo repository, compila i tool e configura un ambiente virtuale python3:
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
Le istruzioni sopra devono essere eseguite solo una volta. Dopo aver scaricato nuovo codice tramite git, devi eseguire di nuovo ./build.sh e ./pysetup.sh.
Installa i driver patchati usando:
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
Questo compila i driver per la maggior parte delle schede di rete supportate da Linux. Se vuoi compilare solo i driver per le schede di rete che ho testato esplicitamente, usa invece make defconfig-experiments. Potresti ricevere i seguenti avvisi:
make defconfig-wifi potresti ricevere avvisi relativi a -Wyacc e -Wformat-overflow. Puoi ignorare questi avvisi finché i driver vengono compilati con successo... needs unknown symbol ... Puoi ignorare questi avvisi finché non contengono la directory /lib/modules/*/updates/ e i driver compilati funzionano.SSL error e il comando sign-file. Questo significa che la firma digitale dei moduli del kernel è fallita. Di solito puoi ignorarlo.cat /sys/module/mac80211/parameters/fragattack_version dopo un riavvio. Se questo file esiste, i driver modificati sono stati installati con successo.Ora installa il firmware ath9k_htc patchato:
cd research/ath9k-firmware/
./install.sh
# Now reboot
Lo script ./install.sh presuppone che le immagini del firmware ath9k_htc si trovino nella directory /lib/firmware/ath9k_htc. Se sul tuo sistema non è così, devi copiare manualmente htc_7010.fw e htc_9271.fw nella directory appropriata.
Dopo aver installato i driver e il firmware patchati, devi scollegare i tuoi dongle Wi-Fi e riavviare il sistema. Le istruzioni sopra devono essere eseguite di nuovo se il kernel Linux viene aggiornato o se i driver patchati vengono aggiornati.
Nota che anche quando il tuo dispositivo funziona immediatamente, raccomando comunque di installare i driver modificati, poiché questo garantisce che non ci siano regressioni inaspettate nel codice del kernel e dei driver.
Nel caso non possa installare i driver/firmware modificati nativamente, puoi scaricare un'immagine USB live che contiene i driver/firmware modificati insieme al nostro tool di test. In alternativa, puoi usare una macchina virtuale con schede di rete USB, anche se ho riscontrato che in pratica l'uso di una macchina virtuale è meno affidabile.
Ogni volta che vuoi usare il tool di test, devi prima caricare l'ambiente virtuale python come root. Puoi farlo usando:
cd research
sudo su
source venv/bin/activate
Ora dovresti disattivare il Wi-Fi nel tuo gestore di rete in modo che non interferisca con il tool di test. Assicurati anche che nessun altro servizio di rete stia causando traffico in uscita. Puoi assicurartene usando iptables per bloccare il traffico eseguendo ./droptraffic.sh (puoi annullare riavviando). Facoltativamente, controlla usando sudo airmon-ng check per vedere quali altri processi potrebbero usare la scheda di rete wireless e potrebbero interferire con il nostro tool.
Il tool di test può testare sia client che AP:
Test degli AP: configura l'AP che vuoi testare modificando research/client.conf. Questo è un file di configurazione standard di wpa_supplicant, consulta la documentazione hostap per una panoramica di tutte le opzioni supportate.
Test dei client: devi eseguire il tool di test con il parametro --ap (vedi sotto). Questo istruisce il tool a creare un AP con nome testnetwork e password abcdefgh. Collegati a questa rete con il client che vuoi testare. Per impostazione predefinita, il client deve richiedere un IP tramite DHCP. Per modificare le proprietà dell'AP creato, come il canale su cui viene creato, puoi modificare research/hostapd.conf.
Questa modalità richiede una sola scheda di rete wireless, ma generalmente richiede un driver e/o firmware patchato. Vedi Driver patchati su come installare driver/firmware patchati, e Schede di rete supportate per le schede di rete compatibili. Esegui il tool di test in questa modalità usando:
./fragattack.py wlan0 [--ap] $COMMAND
I possibili valori di $COMMAND sono elencati in test per le vulnerabilità e test estesi delle vulnerabilità.
Un vantaggio di questa modalità è che funziona abbastanza bene quando si testano client che potrebbero entrare in stato di sospensione. Tuttavia, se possibile, raccomando di disabilitare la funzionalità di sospensione del client in test, vedi Gestione della modalità di sospensione.
Questa modalità richiede due schede di rete wireless: una fungerà da AP o client, e l'altra sarà usata per iniettare frame. Il vantaggio è che questa modalità può funzionare senza richiedere driver patchati. Esegui il tool di test in questa modalità usando:
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
Qui l'interfaccia wlan0 fungerà da client o AP legittimo, e wlan1 sarà usata per iniettare frame. Per wlan0, può essere usata qualsiasi scheda che supporti la normale modalità client o AP su Linux. Per wlan1, deve essere usata una scheda che supporti la modalità di iniezione secondo Schede di rete supportate.
Quando si testano client in questa modalità, i frame iniettati potrebbero essere inviati mentre il client è in stato di sospensione. Questo fa fallire gli attacchi, quindi devi assicurarti che il client non entri in stato di sospensione.
Questa modalità è sperimentale e solo a scopo di ricerca. Vedi dettagli sulla modalità hwsim per maggiori informazioni.
Puoi testare i dispositivi eseguendo il tool di test come discusso in modalità di interfaccia e sostituendo $COMMAND con uno dei comandi nella tabella qui sotto. Assumiamo che i client richiedano un IP tramite DHCP (se non è così, vedi configurazione IP statico). Tutti i comandi funzionano sia contro client che AP, salvo diversa indicazione.
Il tool restituisce TEST COMPLETED SUCCESSFULLY se il dispositivo è vulnerabile all'attacco corrispondente al $COMMAND indicato, e restituisce Test timed out! Retry to be sure, or manually check result se il dispositivo non è vulnerabile. Dopo che il test è stato completato, puoi chiudere il tool di test usando CTRL+C. La maggior parte degli attacchi ha diverse lievi varianti rappresentate da diversi valori di $COMMAND.
La verifica del risultato di alcuni test richiede l'esecuzione di tcpdump o wireshark sul dispositivo in test (la tabella sotto indica se tcpdump deve essere usato). Questa cattura di pacchetti tcpdump deve includere solo i pacchetti che hanno superato l'elaborazione dei livelli PHY e MAC. Ad esempio, su Linux questa cattura dovrebbe essere effettuata mentre l'interfaccia wireless è in modalità "managed" o "ap", non in modalità monitor, il che significa che la cattura conterrà solo pacchetti che hanno superato l'elaborazione a livello Wi-Fi. Vedi evitare tcpdump sugli AP per una discussione su come alcuni test possono comunque essere eseguiti senza dover eseguire tcpdump sugli AP.
Per verificare la configurazione del test, il primo comando nella tabella qui sotto esegue un normale ping che deve avere successo. Il secondo comando invia il ping come due frame Wi-Fi frammentati e dovrebbe fallire solo nel raro caso in cui il dispositivo testato non supporti la frammentazione. Nel caso in cui uno di questi test non funzioni, segui le istruzioni in test di iniezione della scheda di rete per assicurarti che la tua scheda di rete stia iniettando correttamente i frame. Se il client in test potrebbe entrare in modalità di sospensione, vedi Gestione della modalità di sospensione.
Il terzo, quarto e quinto comando non sono attacchi, ma verificano il comportamento di base di deframmentazione di un dispositivo e sono discussi più avanti sotto la tabella.
Come i comandi corrispondono alle CVE è elencato qui sotto. Nota che per i difetti di implementazione elenchiamo un identificatore CVE di riferimento, tuttavia i fornitori potrebbero usare CVE diverse perché una vulnerabilità di implementazione normalmente riceve una CVE unica per ogni codebase interessata. Tuttavia raccomandiamo di fare sempre riferimento a queste CVE di riferimento come modo per riferirsi facilmente a ogni tipo di difetto di implementazione scoperto.
ping: questo test deve sempre avere successo. Se fallisce, qualcosa non va nella configurazione del test.- ping I,E,E: Questo test dovrebbe riuscire su tutti i laptop, smartphone e AP moderni. Se fallisce,
probabilmente c'è un problema con la configurazione del test. Prova ad aggiungere il parametro --icmp-size 100 come correzione. Se
funziona con questo parametro aggiuntivo, devi eseguire anche tutti gli altri test con questo parametro aggiuntivo.
L'unica volta in cui ho riscontrato il fallimento di questo test per motivi validi è quando il dispositivo testato non supporta
la ricezione di frame frammentati, cosa che può accadere su dispositivi IoT leggeri e, per esempio, OpenBSD.ping I,E,E --delay 5: Questo test viene utilizzato per verificare il ritardo massimo accettato tra due frammenti.
Se questo test non funziona, riprova con --delay 1.5 o inferiore. Ad esempio, Linux rimuove i frammenti
dalla memoria dopo 2 secondi, il che significa che un ritardo di 1.8 funzionerà mentre 2.2 non produrrà alcuna risposta. Nel caso in cui il ritardo
massimo accettato sia basso, tutti i frammenti inviati negli altri test devono essere inviati entro questo ritardo massimo accettato.
Altrimenti, i test falliranno banalmente e potresti concludere che un dispositivo non è vulnerabile a un attacco anche
se in realtà lo è.
ping-frag-sep: Questo test invia un frame Wi-Fi frammentato che è separato da un frame non correlato.
Invia cioè il primo frammento, poi un frame Wi-Fi (normale) non correlato e infine il secondo frammento.
Se questo test fallisce, l'attacco a chiave mista (predefinito) e l'attacco alla cache probabilmente falliranno anche loro (poiché richiedono
l'invio di altri frame tra due frammenti). Questo test fallirà anche nel caso in cui il ricevente verifichi se i frammenti
abbiano numeri di pacchetto consecutivi (vedi il prossimo test ping-frag-sep --pn-per-qos).
ping-frag-sep --pn-per-qos: Come sopra, ma l'aggiunta del parametro --pn-per-qos garantisce che entrambi i frammenti
della richiesta ping abbiano un numero di pacchetto (PN) consecutivo. Questo è qualcosa che un ricevente dovrebbe
verificare per essere sicuro. Purtroppo, prima della divulgazione dei nostri risultati, molte implementazioni
non verificano se i PN sono consecutivi. Questo test potrebbe fallire nel caso in cui il ricevente non tenga traccia dell'ultimo
contatore di pacchetti ricevuto per QoS TID, nel qual caso puoi ignorare gli altri test che contengono
il parametro --pn-per-qos.
Il test ping I,E --amsdu verifica se un'implementazione supporta gli A-MSDU non-SPP (non controlla se il dispositivo
è vulnerabile a CVE-2020-24588). Per prevenire gli attacchi, idealmente
la rete deve imporre l'uso di A-MSDU SPP e scartare tutti gli A-MSDU non-SPP. Tuttavia, la maggior parte dei fornitori sta
attualmente implementando mitigazioni ad hoc (vedere Sezione 7.2 dell'articolo). Per questo motivo, devi utilizzare
i seguenti due test per verificare se un dispositivo è vulnerabile agli attacchi di aggregazione (A-MSDU) (CVE-2020-24588):
amsdu-inject: Questo test simula l'attacco di iniezione A-MSDU descritto nella Sezione 3.2 dell'articolo. In particolare,
invia un frame A-MSDU il cui inizio è anche un header LLC/SNAP valido (poiché è anche ciò che accade nel nostro attacco
di riferimento). Se questo test riesce, il dispositivo è vulnerabile a CVE-2020-24588.
amsdu-inject-bad: Alcuni dispositivi analizzano erroneamente i frame A-MSDU che iniziano con un header LLC/SNAP valido, causando il
fallimento del test precedente. In quel caso prova invece amsdu-inject-bad (vedere Sezione 3.6 nell'articolo). Nota che se questo test
riesce, l'impatto dell'attacco è effettivamente identico a quello delle implementazioni che analizzano correttamente tali frame,
il che significa che il dispositivo è vulnerabile a CVE-2020-24588.
Quando si esegue il test a chiave mista contro un AP, l'AP deve essere configurato per rinnovare regolarmente (ad esempio ogni minuto)
la chiave di sessione (PTK) eseguendo un nuovo 4-way handshake. Lo strumento mostrerà
Client cannot force rekey. Waiting on AP to start PTK rekey mentre attende questo handshake di rinnovo PTK.
Contro un numero limitato di AP, lo strumento può anche richiedere il rinnovo del PTK aggiungendo il parametro --rekey-req
il che significa che non è necessario configurare l'AP per rinnovare periodicamente la chiave.
Alcuni AP non possono essere configurati per rinnovare regolarmente la chiave di sessione (PTK). Contro questi AP puoi invece provare un test di attacco alla cache. Se l'AP è vulnerabile agli attacchi alla cache, allora è probabile che sia vulnerabile anche agli attacchi a chiave mista (a meno che non vi siano prove forti che lo contraddicano, ad esempio un audit del codice che indica che gli attacchi a chiave mista sono prevenuti). Se l'AP non è vulnerabile agli attacchi alla cache, allora non possiamo dire nulla sulla sua suscettibilità agli attacchi a chiave mista, e in tal caso raccomando di eseguire invece un audit del codice.
ping I,F,BE,AE --pn-per-qos: Il parametro aggiuntivo --pn-per-qos garantisce che entrambi i frammenti iniettati abbiano
numeri di pacchetto consecutivi, requisito necessario affinché l'attacco a chiave mista riesca contro determinati dispositivi
(ad esempio contro Linux).
Molti dispositivi implementano il 4-way handshake in modo diverso e questo influirà sul successo o meno di questi test Nel caso in cui i test falliscano, si consiglia di eseguire anche i test dell'attacco a chiave mista elencati in Test di vulnerabilità estesi.
Quando si testa un AP, lo strumento invia un primo frammento, poi tenta di riassociarsi all'AP e infine
invia il secondo frammento. Tuttavia, non tutti gli AP supportano correttamente il processo di riassociazione. In tal caso,
aggiungi l'opzione --full-reconnect come mostrato nella tabella, che fa sì che lo strumento esegua la deautenticazione
dopo l'invio del primo frammento.
Quando si testa un client, lo strumento invia un primo frammento, dissocia il client e, una volta che il client
si è riconnesso, invia il secondo frammento. Idealmente il client si riconnetterà immediatamente dopo l'invio
del frame di dissociazione. Questo potrebbe richiedere la disattivazione di tutte le altre reti nel client in test. Ho anche
notato che alcuni client non sembrano gestire correttamente la dissociazione e in tal caso puoi aggiungere
l'opzione --full-reconnect come mostrato nella tabella per inviare invece un frame di deautenticazione.
Ho scoperto che è meglio eseguire ogni test di attacco alla cache più volte. A volte un test di attacco alla cache potrebbe fallire anche se l'implementazione è vulnerabile. Ciò può essere dovuto al rumore di fondo, ad altri dispositivi che inviano frame al dispositivo testato, ecc.
ping I,E,R,AE [--full-recon]: Qui il secondo frammento viene inviato immediatamente dopo la riconnessione con il
dispositivo in test, il che è importante nel caso in cui il dispositivo cancelli i frammenti dalla memoria dopo poco tempo.
Nota che full-recon è un'abbreviazione di full-reconnect.
ping I,E,R,E [--full-recon]: Qui il secondo frammento viene inviato 1 secondo dopo la riconnessione con il
dispositivo in test, il che può essere utile nel caso in cui vi sia un piccolo ritardo tra il completamento dell'handshake
e l'installazione della chiave negoziata.
Nei nostri esperimenti, questo test è fallito solo contro Linux e contro dispositivi che non supportano la frammentazione.
ping I,E,P e linux-plain: se questo test riesce, gli attacchi risultanti sono descritti nella Sezione 6.3
dell'articolo. In sintesi, in combinazione con la vulnerabilità A-MSDU o della cache, può essere sfruttato per
iniettare pacchetti. Quando non è combinato con altre vulnerabilità, l'impatto è specifico dell'implementazione
(CVE-2020-26147).
ping I,P,E: se questo test riesce, è banale iniettare frame plaintext verso il dispositivo se
la rete sta utilizzando la frammentazione (CVE-2020-26147).
ping I,P: se questo test riesce, l'implementazione accetta frame plaintext in una rete Wi-Fi protetta,
consentendo un'iniezione di pacchetti banale (CVE-2020-26140).
ping I,P,P: se questo test riesce, l'implementazione accetta frame plaintext frammentati in una rete
Wi-Fi protetta, consentendo un'iniezione di pacchetti banale (CVE-2020-26143).
I due test seguenti inviano frame broadcast, che non vengono ritrasmessi automaticamente, e pertanto si consiglia di eseguirli più volte. Questo perché il rumore di fondo può impedire ai dispositivi testati di ricevere il frame broadcast iniettato. Nei miei esperimenti, sono stati colpiti principalmente i client (tra gli AP testati solo quelli Free/NetBSD sono stati colpiti).
ping I,D,P --bcast-ra: Invia un ping unicast in un secondo frammento broadcast plaintext dopo la connessione. Il risultato
di questa variante dell'attacco viene verificato automaticamente dallo strumento di test.
ping D,BP --bcast-ra: Qui il frame sopra descritto viene inviato durante la connessione alla rete (cioè durante il 4-way handshake).
Questo è importante perché diversi client e AP sono vulnerabili solo prima del completamento del 4-way handshake. Per
confermare il risultato di questo test devi eseguire wireshark o tcpdump sulla vittima e monitorare se la
richiesta ping iniettata viene ricevuta dalla vittima. In tcpdump puoi usare il filtro icmp e in wireshark puoi
anche usare il filtro frame contains "test_ping_icmp" per rilevare più facilmente questa richiesta ping. Nei miei esperimenti
sono stati colpiti principalmente i client.
eapol-amsdu I,P: Questo è il test standard per la vulnerabilità specifica dell'implementazione discussa nella
Sezione 6.5 dell'articolo. Sia i client che gli AP possono essere vulnerabili. Il suo risultato viene verificato automaticamente da
dallo strumento di test.
I test che terminano con BP (eapol-amsdu BP e eapol-amsdu-bad BP): Questi test iniettano il frame dannoso
durante l'esecuzione del 4-way handshake. Per confermare il risultato di questo test devi eseguire wireshark
o tcpdump sulla vittima e monitorare se la richiesta ping iniettata viene ricevuta dalla vittima. In tcpdump
puoi usare il filtro icmp e in wireshark puoi anche usare il filtro frame contains "test_ping_icmp"
per rilevare più facilmente questa richiesta ping.
I test che iniziano con eapol-amsdu-bad (eapol-amsdu-bad BP e eapol-amsdu-bad I,P): Diverse implementazioni
elaborano erroneamente i frame A-MSDU i cui primi 6 byte corrispondono anche a un header RFC1042 valido per EAPOL. Per testare queste
implementazioni, devi usare la variante di test eapol-amsdu-bad. Nota che se questo test riesce, l'impatto
dell'attacco è identico a quello delle implementazioni che analizzano correttamente tali frame (per i dettagli vedere le Sezioni 3.6 e
6.6 nell'articolo).
Nel caso in cui lo strumento di test non sembri funzionare, controlla quanto segue:
Verifica che nessun altro processo stia utilizzando la scheda di rete (ad esempio termina il tuo network manager).
Se in precedenza tutto funzionava, prova a scollegare la chiavetta Wi-Fi, riavvia il computer o la macchina
virtuale e poi riprova. Prova anche a disabilitare la crittografia hardware usando lo script disable-hwcrypto.sh
(riavvia il computer dopo aver eseguito questo script).
Assicurati che il dispositivo in test non entri in stato di sospensione (causando la perdita dei frame iniettati). Consiglio di eseguire lo strumento di test in modalità mista poiché gestisce meglio i client che potrebbero entrare in stato di sospensione.
Esegui i test di iniezione per assicurarti che l'iniezione funzioni correttamente. Assicurati anche che venga utilizzato un canale da 20 MHz; l'iniezione su altri canali non è testata.
Controlla che la tua macchina non stia generando traffico di fondo che interferisca con i test. In particolare, disabilita la rete nel tuo sistema operativo, termina manualmente il client/server DHCP, ecc. Vedi anche Prima di ogni utilizzo.
Conferma di esserti connesso alla rete corretta. Ricontrolla client.conf.
Assicurati che l'AP in test stia usando (AES-)CCMP come algoritmo di crittografia. Altri algoritmi di crittografia come TKIP o GCMP non sono supportati.
Se hai aggiornato il codice usando git, esegui di nuovo ./build.sh e ./pysetup.sh (vedi Prerequisiti).
Nel caso in cui i driver patchati siano stati aggiornati, ricordati di ricompilarli.
Se stai usando una macchina virtuale, prova invece a eseguire lo strumento di test da un'immagine live USB.
Controlla che il dispositivo testato non blocchi le richieste ping ICMP. Nel caso non risponda ai ping, puoi eseguire tcpdump o wireshark sul dispositivo, oppure provare uno degli altri metodi elencati in .
A causa delle variazioni nelle implementazioni, può essere difficile confermare/sfruttare determinate vulnerabilità, in particolare l'attacco a chiave mista e quello alla cache possono essere non banali da confermare nella pratica. Pertanto, raccomando di considerare un dispositivo sicuro solo se nel codice sono presenti controlli espliciti per prevenire questi attacchi. Inoltre, se il tempo lo consente, raccomando anche i seguenti test più avanzati. Questi hanno una minore probabilità di scoprire nuove vulnerabilità, ma potrebbero rivelare varianti di attacco o comportamenti particolari del dispositivo che i test normali non possono rilevare.
Se i test normali in Test per le vulnerabilità hanno già confermato la presenza di una determinata classe di vulnerabilità, c'è poca necessità di testare le altre varianti di attacco di quella vulnerabilità. Tutti i comandi funzionano sia contro i client che contro gli AP, salvo diversa indicazione.
È utile eseguire questi due test solo se il test principale ping I,E --amsdu fallisce e vuoi comprendere meglio
come il dispositivo testato gestisce i frame A-MSDU:
ping I,E --amsdu-fake: Se questo test riesce, il ricevente tratta tutti i frame come frame normali (il che significa che non
supporta i frame A-MSDU). Questo comportamento non è ideale, anche se è improbabile che un attaccante possa abusarne nella
pratica (vedere Sezione 3.5 nell'articolo).
ping I,E --amsdu-fake --amsdu-spp: Se questo test riesce, il ricevente autentica il flag QoS A-MSDU di ogni
frame ricevuto (cioè non lo maschera a zero in ricezione) ma poi tratta tutti i frame ricevuti come frame normali
(il che significa che non supporta la ricezione di veri frame A-MSDU). Questo comportamento non è ideale, anche se è improbabile
che un attaccante possa abusarne nella pratica (vedere Sezione 3.5 nell'articolo).
La maggior parte dei dispositivi che ho testato è vulnerabile agli attacchi a chiave mista. Nel caso in cui i normali test dell'attacco a chiave mista indichino
che un dispositivo non è vulnerabile, ma il test ping-frag-sep riesca, è altamente raccomandato provare
questi test alternativi dell'attacco a chiave mista.Come osservazione generale, quando si testa un AP, è possibile aggiungere il parametro --rekey-req a qualsiasi test di attacco a chiave mista per
richiedere attivamente un rekey handshake. Un numero ridotto di AP eseguirà quindi il rekey handshake. La maggior parte degli AP ignorerà
comunque questa richiesta, e dovrà essere configurata esplicitamente per rinnovare regolarmente la chiave di sessione (PTK).
Alcune note sui test:
ping I,F,BE,E e ping I,E,F,AE: questi sono test di attacco a chiave mista abbastanza semplici in cui entrambi i frammenti vengono
iniettati in momenti diversi.
ping I,E,F,AE --rekey-plain: alcuni driver (ad es. MediaTek) eseguono il rekey handshake in chiaro. Per testare
dispositivi che utilizzano un driver di questo tipo è necessario aggiungere il parametro --rekey-plain.
ping I,E,F,AE --rekey-plain --rekey-req: questa combinazione particolare è utile per testare router che utilizzano un driver MediaTek.
Questi router eseguono il rekey handshake in chiaro e il client può richiedere attivamente un rekey handshake.
ping I,E,F,AE --rekey-early-install: un numero ridotto di client installa (erroneamente) la chiave troppo presto durante
un rekey della sessione pairwise. Per testare in modo affidabile questi client, aggiungere il parametro --rekey-early-install. Questo test
non è significativo contro gli AP.
ping I,E,F,E [--rekey-pl] [--rekey-req]: questa variante di test è la stessa dei precedenti test ping I,E,F,AE *,
tranne per il fatto che il secondo frammento viene inviato 1 secondo dopo il 4-way handshake. Questo può essere importante perché in un
numero ridotto di dispositivi c'è un piccolo ritardo prima che la nuova chiave venga installata. Notare che è un'abbreviazione
di .
Infine, nel caso in cui il test ping-frag-sep non abbia successo, si dovrebbe provare il seguente test di attacco a chiave mista:
ping I,F,BE,AE --freebsd: questo essenzialmente esegue il rekey handshake contro un'implementazione FreeBSD, o
un driver che prende in prestito codice da FreeBSD, senza influenzare il processo di deframmentazione dei frame di dati. Vedere
Appendice E nell'articolo per i dettagli.ping I,E,R,AE --freebsd --full-reconnect: questo test può essere usato per verificare se un AP FreeBSD, o un driver che
prende in prestito codice da FreeBSD, è vulnerabile a un attacco cache. Vedere Appendice E nell'articolo per i dettagli su come funziona
questo test. Si dovrebbe anche provare questo test senza il parametro --full-reconnect. Il test funziona anche contro
i client, ma è improbabile che questi ne siano influenzati.
ping I,E,R,AP --freebsd --full-reconnect: questo test è una variante contro AP FreeBSD, o contro un driver che
prende in prestito codice da FreeBSD, in cui il secondo frammento viene inviato in chiaro dopo la riconnessione con l'AP. Contro alcuni
dongle su FreeBSD questo test è stato più affidabile e dimostra comunque che i vecchi frammenti rimangono nella memoria dell'AP dopo
la riconnessione. Si dovrebbe anche provare questo test senza il parametro --full-reconnect. Il test funziona anche contro
i client, ma è improbabile che questi ne siano influenzati.
ping I,E,R,AP [--full-reconnect]: in questo test il secondo frammento viene inviato in chiaro. Questo può essere utile se
il dispositivo testato non installa immediatamente la chiave dopo il 4-way handshake. Se questo test ha successo,
mostra che il dispositivo mantiene i frammenti in memoria dopo la (ri)connessione a una rete, il che significa che è vulnerabile agli attacchi
cache. A differenza dei due comandi precedenti, questo è utile anche da eseguire contro i client (oltre che contro gli AP).
ping I,E,E --amsdu: questo test invia un frame A-MSDU frammentato, che non tutti i dispositivi possono ricevere correttamente.
Non verifica una vulnerabilità. Invece, questo test è utile per determinare la sfruttabilità pratica
dell'attacco "Mixed plain/encrypt attack". In particolare, se questo test ha successo, è più facile attaccare il dispositivo se il
secondo frammento può essere inviato in chiaro (test ping I,E,P). Vedere Sezione 6.3 dell'articolo per i dettagli.
ping I,E,P,E e linux-plain 3: se tutti gli altri test dell'attacco misto plain/encrypt non hanno avuto successo, si possono
provare anche questi due test aggiuntivi. Penso che sia abbastanza improbabile che questo porti alla scoperta di una nuova vulnerabilità.
La maggior parte dei seguenti test invia frame broadcast, che non vengono ritrasmessi automaticamente, e pertanto si raccomanda di eseguirli più volte. Questo perché il rumore di fondo può impedire ai dispositivi testati di ricevere il frame broadcast iniettato. Nei miei esperimenti, sono stati principalmente i client a essere influenzati. La maggior parte dei client è vulnerabile solo durante la connessione alla rete (cioè durante l'esecuzione del 4-way handshake).
ping I,P --bcast-ra: questo invia una richiesta ICMP ping unicast all'interno di un frame Wi-Fi broadcast in chiaro (CVE-2020-26145).
Questo test può essere eseguito sia contro i client sia contro gli AP.
ping BP --bcast-ra: simile al test precedente ping I,P --bcast-ra, ma il ping viene inviato prima che il client si sia
autenticato con la rete, cioè durante l'esecuzione del 4-way handshake (CVE-2020-26145). È necessario eseguire tcpdump
o wireshark per verificare se il client accetta il frame. In tcpdump si può usare il filtro icmp e in wireshark
si può anche usare il filtro frame contains "test_ping_icmp" per rilevare più facilmente questa richiesta ping.
ping BP --bcast-ra --bcast-dst: questo test è uguale al precedente, ma è utile se non è possibile eseguire tcpdump
sull'AP di destinazione. Notare che questo test è significativo solo contro gli AP. Il parametro aggiuntivo --bcast-dst in questo test
fa sì che un AP vulnerabile trasmetta la richiesta ping iniettata a tutti i client connessi. In altre parole, per verificare se un
AP è vulnerabile, eseguire questo comando e ascoltare i frame Wi-Fi broadcast su un secondo dispositivo connesso
all'AP usando il filtro icmp o frame contains "test_ping_icmp".
ping BP [--bcast-dst]: questa è una variante dei due test precedenti ping BP --bcast-ra [--bcast-dst], tranne per il fatto che la richiesta
ping viene ora inviata in un frame unicast in chiaro invece che in uno broadcast (nessun CVE è stato ancora assegnato - è correlato a
CVE-2020-26145). Questo test deve essere eseguito sia contro i client sia contro gli AP. Il ping viene inviato prima che il client si sia autenticato
con la rete (cioè durante l'esecuzione del 4-way handshake), il che significa che è necessario eseguire tcpdump o wireshark per verificare se il
dispositivo accetta questo frame. In alternativa, quando si testano gli AP, si può aggiungere il parametro --bcast-dst come nel test precedente,
e quindi usare tcpdump o wireshark su un secondo dispositivo connesso all'AP usando il filtro icmp o
frame contains "test_ping_icmp".
eapfrag BP,BP: questa è una specializzazione dei test sui frammenti broadcast sopra descritti che viene eseguita prima che il client si sia
autenticato. È un attacco molto sperimentale basato sull'analisi di codice trapelato. Invia prima un frammento in chiaro
che inizia con un'intestazione EAPOL, che viene accettato perché il 4-way handshake è ancora in esecuzione. Poi invia un
secondo frammento broadcast con lo stesso numero di sequenza. Sulla base dell'analisi di codice trapelato, alcuni dispositivi potrebbero ora accettare
questo frammento (perché il frammento precedente è stato consentito), ma il codice successivo lo elaborerà come un frame normale
(perché il frammento viene trasmesso in broadcast). È necessario usare tcpdump o wireshark sulla vittima per determinare se il frame
viene ricevuto correttamente, ad esempio usando il filtro icmp o . Una variante alternativa
è nel caso in cui la variante normale non funzioni.
Questo test può essere usato nel caso in cui si vogliano eseguire i test eapol-amsdu[-bad] BP ma non sia possibile eseguire tcpdump o wireshark sull'
AP. Questo test è significativo solo contro gli AP: il comando eapol-amsdu[-bad] BP --bcast-dst fa sì che un AP vulnerabile
trasmetta la richiesta ping iniettata a tutti i client connessi. In altre parole, per verificare se un AP è vulnerabile, eseguire questo
comando e ascoltare i frame Wi-Fi broadcast su un secondo dispositivo connesso all'AP usando il filtro icmp o
frame contains "test_ping_icmp".
eapol-inject 00:11:22:33:44:55: questo test è significativo solo contro gli AP. Per eseguire questo test è necessario connettersi
alla rete usando un secondo dispositivo e sostituire l'indirizzo MAC 00:11:22:33:44:55 con l'indirizzo MAC di questo secondo
dispositivo. Prima dell'autenticazione, lo strumento di test invierà un frame EAPOL all'AP con come destinazione finale questo secondo
dispositivo. Se l'AP inoltra il frame EAPOL al secondo dispositivo, l'AP è considerato vulnerabile. Per confermare se l'AP inoltra
il frame EAPOL è necessario eseguire tcpdump o wireshark sul secondo dispositivo. Si può usare il filtro wireshark frame contains "forwarded_data"
quando si monitora il traffico decrittato sull'interfaccia wireless del secondo dispositivo (o il filtro tcpdump ether proto 0x888e
per monitorare tutti i frame EAPOL). Vedere Sezione 6.6 dell'articolo per i dettagli e l'impatto di questo.
eapol-inject-lage 00:11:22:33:44:55: nel caso in cui il test eapol-inject sopra abbia successo, si può anche provare eapol-inject-large per vedere
se questa vulnerabilità può essere abusata per forzare la trasmissione di frammenti crittografati. È necessario usare di nuovo tcpdump o wireshark
per verificarlo. Usare il filtro wireshark o tshark (wlan.fc.frag == 1) || (wlan.frag > 0) per rilevare i frame frammentati. Ho trovato
molto raro che questo attacco funzioni.
ping I,D,E: se questo test ha successo, il client o l'AP non supporta la (de)frammentazione, ma è comunque vulnerabile agli attacchi.
Il problema è che il ricevitore tratta l'ultimo frammento come un frame completo. Vedere Sezione 6.8 dell'articolo per i dettagli e come
questo può essere sfruttato.
ping I,E,D: se questo test ha successo, il client o l'AP tratta il primo frammento come un frame completo. Sebbene questo comportamento
non sia ideale, al momento non è noto se questo, da solo, possa essere sfruttato nella pratica.
Lo script test-injection.py può essere usato per verificare se i frame vengono iniettati correttamente quando
si usa la modalità di iniezione:
./test-injection.py wlan0 wlan1
Qui testiamo se la scheda di rete wlan0 inietta correttamente i frame e usiamo la scheda di rete wlan1
per monitorare se i frame vengono iniettati correttamente. Notare che entrambe le interfacce devono supportare
la modalità monitor affinché questo script di test funzioni.
Nel caso in cui non si disponga di una seconda scheda di rete, si può eseguire un test di iniezione parziale usando:
./test-injection.py wlan0
Sfortunatamente, il test sopra può solo verificare se il kernel sovrascrive campi dei frame iniettati, non può verificare se il firmware o il chip wireless stesso sovrascrive campi.
Per verificare se una scheda di rete inietta correttamente i frame in modalità mista, che è la modalità che raccomando di usare, si possono eseguire i seguenti due comandi:
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
Qui testiamo se wlan0 inietta correttamente i frame monitorando i frame iniettati usando la
seconda scheda di rete wlan1. Il primo comando verifica se i frame vengono iniettati correttamente quando si usa
la modalità mista agendo come client, e il secondo comando quando si usa la modalità mista agendo
come AP. Per avviare il test, il client deve essere in grado di connettersi a una rete, e l'
AP attende che un client si connetta prima di avviare i test di iniezione (vedere Prima di ogni utilizzo
per configurare il setup di connessione del client e dell'AP).
Se si vuole anche testare il comportamento di ritrasmissione di wlan0 in modalità mista si può eseguire:
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
Nel caso in cui non si disponga di una seconda scheda di rete, si può eseguire un test di iniezione parziale in modalità mista usando:
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
Sfortunatamente, i test sopra possono solo verificare se il kernel sovrascrive campi dei frame iniettati, non possono verificare se il firmware o il chip wireless stesso sovrascrive campi.
Lo script di test fornirà un output dettagliato su quali test hanno avuto successo o sono falliti, e concluderà emettendo
o ==> The most important tests have been passed successfully oppure un messaggio che indica che alcuni test importanti
sono falliti o che non è stato possibile catturare alcuni frame iniettati.
Notare che gli script di iniezione testano solo il comportamento più importante. Il modo migliore per confermare che l'iniezione funzioni correttamente è eseguire i test di vulnerabilità contro dispositivi noti per essere vulnerabili, e confermare che lo strumento identifichi correttamente il o i dispositivi come vulnerabili.
Quando alcuni frame iniettati non possono essere catturati, questo può essere dovuto al rumore di fondo, o perché la
scheda di rete testata non è in grado di iniettare correttamente alcuni frame (ad es. il firmware dell'Intel AX200 va in crash
quando si iniettano frame frammentati). Potrebbe anche essere che i frame vengano effettivamente iniettati correttamente, ma che la
scheda di rete usata per monitorare se i frame vengono iniettati correttamente (wlan1 negli esempi sopra) non sia affidabile e, ad
esempio, perda la maggior parte dei frame a causa del rumore di fondo. Provare anche a eseguire i test su un canale diverso.
Quando i test di iniezione funzionano, ma si hanno problemi a eseguire in modo affidabile i test di attacco, questo può essere dovuto al fatto che i dispositivi testati entrano in modalità sleep. Vedere Gestione della modalità sleep per note aggiuntive su questo problema.
Quando si usa wireshark per ispezionare il comportamento di iniezione di un dispositivo, si raccomanda di usare un secondo dispositivo in modalità monitor per vedere come vengono iniettati i frame.
Nel caso in cui si apra l'interfaccia usata per iniettare i frame, si dovrebbero vedere i frame iniettati due volte: (1) prima si vede il frame come iniettato dallo strumento che lo sta inviando, e poi (2) una seconda volta come il frame è stato iniettato dal driver. Questi due frame possono differire leggermente se il kernel ha sovrascritto alcuni campi. Se si vede un frame iniettato una sola volta, potrebbe essere stato eliminato dal kernel.
Nel caso in cui il dispositivo testato non supporti DHCP, è possibile specificare manualmente gli indirizzi IP che lo strumento di test dovrebbe usare. Ad esempio:
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
Qui lo strumento di test userà l'indirizzo IP 192.168.100.10 e inietterà una richiesta ping al peer con indirizzo IP 192.168.100.1.
Quando un test invia pacchetti IP prima di ottenere gli indirizzi IP tramite DHCP, userà l'indirizzo IP
predefinito 127.0.0.1. Per usare indirizzi IP (predefiniti) diversi, si possono anche usare i parametri --ip e -peerip.
La maggior parte dei test di attacco funziona inviando richieste ICMP ping in modi particolari e verificando se riceviamo
una risposta ICMP ping. Nel caso in cui il dispositivo testato non supporti i ping ICMP, si possono
invece usare richieste ARP aggiungendo il parametro --arp a tutti i test. Nel caso in cui un test non supporti l'invio
di richieste ARP, lo strumento mostrerà l'errore Cannot override request type of the selected test, nel
qual caso il test specifico può essere eseguito solo usando richieste ICMP ping.
TODO: Quando si agisce come client si possono anche iniettare richieste DHCP invece.
Nel caso in cui non si riesca ad accedere a una delle schede di rete wireless raccomandate, una seconda opzione è procurarsi una scheda di rete che usi gli stessi driver su Linux. In particolare, si può provare:
Raccomando le schede basate su ath9k_htc. Non tutte le schede che usano iwlmvm saranno compatibili. Quando
si usa una scheda di rete alternativa, raccomando vivamente di eseguire prima i test di iniezione
per confermare che la scheda di rete sia compatibile.
Per usare lo strumento di test sui 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 si possono iniettare frame, si può eseguire iw list e cercare sotto
Frequencies i canali che non sono marcati come disabilitati, no IR, o radar detection. Notare che queste
condizioni possono dipendere dalla scheda di rete, dal paese attualmente configurato e dall'AP a cui si è
connessi. Per maggiori informazioni vedere, ad esempio, la documentazione di Arch Linux.
Notare che un dispositivo può usare driver diversi per gestire la banda 2.4 e 5 GHz. Di conseguenza, è importante testare i dispositivi in entrambe queste bande, poiché un dispositivo può comportarsi diversamente a seconda della banda di frequenza utilizzata.
Notare che in modalità mista 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 rifiutarsi di
iniettare frame anche se questo è in realtà consentito. Far sì che cfg80211_reg_can_beacon restituisca true
nelle condizioni corrette previene questo bug.
In pratica, alcune persone hanno scoperto che è necessario prima impostare manualmente la scheda di rete wireless sul canale a 5GHz su cui opera l'AP. Vedere questo problema GitHub per i dettagli.
Dispositivi come telefoni cellulari o gadget IoT possono mettere la loro radio Wi-Fi in modalità sleep per ridurre il consumo energetico. Quando sono in modalità sleep, questi dispositivi non sono in grado di ricevere frame Wi-Fi, il che può interferire con i nostri test. Ci sono alcune opzioni per provare a mitigare questo problema:
Provare a disabilitare la modalità sleep sul dispositivo testato. Questa è la soluzione più affidabile, ma sfortunatamente non sempre possibile.
Eseguire lo strumento di test in modalità mista. La maggior parte delle schede di rete accoderà quindi i frame iniettati fino a quando il dispositivo testato non è di nuovo sveglio.
Provare una scheda di rete diversa per eseguire i test. Ho scoperto che diverse schede di rete iniettano i frame in momenti (leggermente) diversi, e questo può fare la differenza tra un frame iniettato che arriva correttamente o che viene perso. Ad esempio, contro un Pixel 4 XL lo strumento di test non era affidabile usando una TL-WN722N ma funzionava in modo affidabile con un Intel 8265.
Assegnare IP statici al dispositivo in test e far usare allo strumento di test IP statici (vedere Configurazione IP statica). Con molti test questo può essere più affidabile perché lo strumento di test può quindi inviare immediatamente il frame di test invece di dover prima usare/attendere il DHCP.
cioè quando esegue l'handshake a 4 vie. Questo le rende più difficili da testare automaticamente e in genere significa che tcpdump o simile deve essere usato sul dispositivo in test. Tuttavia, gli AP possono essere testati senza eseguire tcpdump su di essi. In particolare, i test dell'attacco di frammentazione broadcast (CVE-2020-26145) e i test dell'attacco A-MSDU EAPOL (CVE-2020-26144) possono essere eseguiti senza eseguire tcpdump sul dispositivo in test. Invece, tcpdump deve essere eseguito su un altro client connesso all'AP. Concretamente, è possibile usare i seguenti comandi:
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
Con questi comandi, puoi monitorare la richiesta ping su un altro client connesso all'AP. Se la richiesta ping viene ricevuta su questo client indipendente, l'AP in test è vulnerabile. Sfortunatamente, attualmente sembra difficile testare i client contro queste varianti di attacco senza eseguire tcpdump sul client.
Se per qualche motivo Linux non riconosce automaticamente questo dongle, esegui sudo modprobe mt76x2u
per caricare manualmente il driver. Questo dongle sembra affidabile con i nostri driver più recenti. Se il dongle non è affidabile,
crea il file /etc/modprobe.d/mt76.conf con il seguente contenuto:```
options mt76_usb disable_usb_sg=1
Quindi riavvia la macchina. Assicurati anche di usare un buon cavo USB con questo dongle! In precedenza ho riscontrato
comportamenti inaffidabili con questo dongle, causati da un cavo USB 3.0 difettoso. Quindi se riscontri problemi,
può aiutare collegare il dongle direttamente senza usare un cavo.
Quando usi VirtualBox, assicurati di abilitare USB3.0 così che il dongle venga riconosciuto. Vedi
[questo problema](https://github.com/vanhoefm/fragattacks/issues/22) per i dettagli.
L'AWUS036ACM usa internamente un chipset MT7612U. Ora esistono anche dongle con chipset MT7612UN che
sono affidabili con il nostro strumento di test. Un esempio è il [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).
### ath9k_htc
Il Technoethical N150 HGA, il TP-Link TL-WN722N v1.x e l'Alfa AWUS036NHA usano tutti il driver `ath9k_htc`.
Per me questi dispositivi hanno funzionato abbastanza bene in una macchina virtuale, anche se come con tutti i dispositivi sono
più affidabili quando usati in modo nativo. Quando usi una VM, consiglio di configurare la VM per usare un controller USB2.0,
poiché è apparso più stabile (almeno con VirtualBox).
Nei kernel recenti c'era una regressione ([ora corretta](https://www.spinics.net/lists/linux-wireless/msg200825.html))
con il driver `ath9k_htc` che ne impediva il funzionamento. Basta usare un kernel aggiornato o i nostri driver
patchati per evitare questo problema.
#### AWUS036ACH
Questo dispositivo generalmente non è supportato per impostazione predefinita nella maggior parte delle distribuzioni Linux e richiede l'installazione
manuale dei driver. Su Kali Linux puoi installare il driver usando `sudo apt install realtek-rtl88xxau-dkms`.
Per installare il driver su altre distribuzioni controlla il tuo gestore di pacchetti o segui le istruzioni
di installazione su [GitHub](https://github.com/aircrack-ng/rtl8812au). Prima di collegare il dispositivo,
è consigliato eseguire `modprobe 88XXau rtw_monitor_retransmit=1`.
Sfortunatamente, questo dispositivo non funziona in modalità mista, che è la modalità consigliata, ed è difficile
da usare in combinazione con i nostri driver modificati. In pratica, dovrai disinstallare i driver modificati
e poi eseguire lo strumento di test usando i parametri `--no-drivercheck` e usando `--inject wlan0`
dove wlan0 si riferisce alla scheda AWUS036ACH. A causa di queste limitazioni questo dispositivo non è consigliato.
### Intel AX200
Ho testato l'Intel AX200 e ho scoperto che _non_ è compatibile con lo strumento di test: il suo firmware si blocca
dopo l'iniezione di un frame con il flag More Fragments impostato. Se uno sviluppatore Intel sta leggendo questo, per favore
aggiorni il firmware e renda possibile iniettare frame frammentati.
### Chip basati su RT5572
Ho testato questo chipset usando il [CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20) generico.
Dopo aver disabilitato la decrittazione hardware eseguendo lo script `disable-hwcrypto.sh` sono riuscito a eseguire
un test ping di base (`ping`). Un test ping frammentato (`ping I,E,E`) era molto inaffidabile ma a volte funzionava.
La conclusione attuale è che i chip RT5572 _potrebbero_ funzionare con lo strumento di test dopo aver disabilitato
la crittografia hardware. Ma sono necessari esperimenti aggiuntivi per confermarlo (il feedback è benvenuto).
<a id="id-hwsim-details"></a>
## 9.9. Dettagli della modalità Hwsim
**Attenzione**: *questa è attualmente una modalità sperimentale, usala solo per scopi di ricerca.*
Questa modalità richiede solo una scheda di rete che supporti la modalità monitor e, a differenza della modalità mista, la
scheda di rete non deve supportare interfacce virtuali. Lo svantaggio è che in questa modalità i frame
vengono gestiti un po' più lentamente e non è affidabile quando la scheda di rete non conferma i frame:
- A causa del commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status") l'autenticazione
come client andrà in timeout immediatamente, il che significa che attualmente non possiamo usare la modalità hwsim come client.
_TODO: Dobbiamo patchare il kernel per evitare questo timeout._
- Se testiamo un client che usa il commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status")
noi (come AP) dobbiamo confermare i frame inviati verso di noi. Altrimenti il client in fase di test non sarà
in grado di connettersi.
_TODO: Testare quali dispositivi confermano i frame in modalità monitor e testare `iw set wlanX monitor active`._
- Alcuni AP richiederanno anche che i frame di autenticazione e associazione siano confermati dal client.
Questo significa che noi (come client) dobbiamo ancora una volta confermare i frame inviati verso di noi.
_TODO: Testare quali dispositivi confermano i frame in modalità monitor e testare `iw set wlanX monitor active`._
- Per qualche strana ragione, l'Intel/mvm non riesce a ricevere frame di dati da Android/iPhone/iPad
dopo il 4-way HS? Questo è un bug molto strano. _TODO: Investigare ulteriormente._
Prima di usare questa modalità, crea due schede di rete virtuali:
./hwsim.sh
Questo mostrerà le due interfacce "hwsim" virtuali create, ad esempio wlan1 e wlan2. Quando si testa
un AP in questa modalità, devi prima cercare il canale dell'AP e mettere la scheda di rete reale su
questo canale:
./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
Qui wlan0 si riferisce alla scheda di rete _reale_ (non un'interfaccia creata da `hwsim.sh`). Quando si testa un
client, non devi prima configurare il canale (viene preso da `hostapd.conf`). Ora puoi
avviare lo strumento di test come segue:
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
Dopo che lo strumento è stato eseguito, puoi eseguirlo di nuovo direttamente con un nuovo `$COMMAND`.
<a id="id-wpa3-sae"></a>
## 9.10. Testare dispositivi WPA3 e SAE
Puoi testare un AP WPA3/SAE includendo le seguenti due righe in `client.conf`:
key_mgmt=SAE
ieee80211w=1
Per testare client WPA3/SAE puoi modificare `hostapd.conf` e impostare i parametri:
wpa_key_mgmt=SAE
ieee80211w=2
Abbiamo testato quanto sopra con un Intel 8265, Intel 3160, Netgear WN111v2 (`carl9170`),
TP-Link TL-WN722N (`ath9k_htc`) e WNDA3200 (`ath9k_htc`). Con quei
dispositivi sono riuscito a connettermi all'AP ed eseguire alcuni test. Quindi
sembra che questo dovrebbe funzionare con tutti i dongle già supportati. Nota che
non ho testato questo in dettaglio: la mia ipotesi è stata che il fatto che un
dispositivo operi in modalità WPA2 o WPA3 non influisca sui risultati dei test.
Il `client.conf` fornito abilita per impostazione predefinita sia il metodo hunting-and-pecking che
il metodo hash-to-element. Per configurare un AP che supporti hash-to-element (e quindi
testare i client WPA3/SAE più recenti) puoi modificare `hostapd.conf` e impostare il parametro:
sae_pwe=2
Impostando questo valore l'AP accetterà sia il metodo hunting-and-pecking che
il metodo hash-to-element.
<a id="id-live-image"></a>
## 9.11. Immagine USB Live
Scarica l'[immagine USB Live](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)
e scrivila su USB usando:
# 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
Lo sha256sum dell'immagine è `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Sostituisci `/dev/sdb`
con la tua chiavetta USB. Se non stai usando Linux, cerca online come scrivere un'immagine ISO sulla tua chiavetta USB.
All'avvio dell'immagine live, fai clic su "Try Ubuntu" durante l'avvio. Apri un terminale facendo clic con il tasto destro sul
desktop e selezionando "Open in Terminal", quindi esegui:
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
Ora puoi eseguire `./fragattacks.py` e seguire le normali istruzioni in questo README.
Ricorda di disabilitare il Wi-Fi usando `nmcli radio wifi off` come mostrato sopra, altrimenti il
network manager di Ubuntu interferirà con lo strumento di test. Questo README è anche presente
sull'immagine live in `~/fragattacks/README.md`.
Nota che airmon-ng potrebbe essere inaffidabile sull'immagine live ed è meglio usare [iw](https://github.com/vanhoefm/fragattacks/issues/36).
<a id="id-design-notes"></a>
# 10. Note di progettazione
Gli argomenti passati al comando ping definiscono quali azioni lo strumento di test eseguirà
e quando queste azioni vengono eseguite. Ogni azione è separata da una virgola (`,`). Per impostazione predefinita
un'azione viene eseguita dopo che il client si è connesso e in quel caso una singola lettera rappresenta
quale azione viene eseguita. Nota che questo è implementato nella
funzione [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23).
Le possibili azioni sono:
- `I`: ottieni un indirizzo IP. Per impostazione predefinita viene fatto usando DHCP, a meno che un indirizzo IP non sia esplicitamente
fornito usando gli argomenti `--ip` e `--peerip`, nel qual caso non viene fatto nulla.
- `E`: inietta un pacchetto/frammento cifrato della richiesta ping.
- `P`: inietta un pacchetto/frammento in chiaro della richiesta ping.
- `F`: aggiorna la chiave di sessione avviando il 4-way handshake (come AP) o aspettando il
4-way handshake (come client).
- `R`: fai riconnettere il client alla rete.
- `D`: questa è una speciale "meta-azione". Trattala come un frammento vuoto della richiesta ping
che non viene effettivamente inviato.
Se c'è una sola azione `E` o `P`, la richiesta ping viene iniettata come un singolo frame.
Se ci sono più azioni `E`, `P`, la richiesta ping viene frammentata, dove il numero
di frammenti è uguale al numero di azioni `E` o `P`. Se c'è la speciale azione `D`, allora
la richiesta ping viene frammentata sulle restanti azioni `E` o `P` (vedi gli esempi nella tabella).
Questo comportamento di frammentazione è implementato nella classe [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).
Una lettera può essere messa davanti alle azioni precedenti per cambiare quando l'azione deve essere eseguita:
- `S`: l'azione viene eseguita sul 1° o 2° messaggio del 4-way handshake.
- `B`: l'azione viene eseguita sul 3° o 4° messaggio del 4-way handshake.
- `A`: l'azione viene eseguita immediatamente dopo il completamento del 4-way handshake.
- `C`: l'azione viene eseguita 1 secondo dopo il completamento del 4-way handshake. La quantità di secondi
da attendere può essere modificata usando il parametro `--connected-delay`.
Per esempio vedi le due tabelle sopra con i comandi.
<a id="id-change-log"></a>
# 11. Registro delle modifiche
**Versione 1.3.4 (in corso):**:
- Cifra sempre i frame di richiesta EAPOL (Rekey), anche quando viene usato --rekey-plaintext.
- Il client ora accetta frame EAPOL riprodotti. Questo assicura che i rekey funzionino anche quando l'AP in fase di test
implementa i rekey in modo errato.
- Aggiornato wpa_supplicant per riabilitare la connessione a reti Enterprise che usano MS-CHAPv2. In precedenza, quando
il sistema operativo usa OpenSSL 3.0 o superiore, MD4 era disabilitato per impostazione predefinita, il che significava che MS-CHAPv2 non poteva essere usato.
- Aggiunto il parametro `--pre-test-delay`. Questo aggiunge un ritardo tra l'ottenimento di un indirizzo IP e la trasmissione
dei primi frammenti/frame. Vedi la [pull request](https://github.com/vanhoefm/fragattacks/pull/44) di
Michael Trimarchi e Angelo Compagnucci.
- Aggiornati i driver modificati in modo che compilino anche sul kernel Linux 5.13. Questo è sperimentale.
- Reso il test di iniezione più affidabile attendendo più a lungo per i frame nel test di riordino.
- Apportate diverse modifiche minori per rendere il codice più facile da compilare su piattaforme meno recenti (che hanno versioni precedenti di Python
e librerie OpenSSL).
- Aggiornato il README con un esempio su come installare un kernel supportato meno recente su Ubuntu 20.04. Aggiunte
note di progettazione. Ora consigliamo l'AWUS036ACM.
**Versione 1.3.3 (11 maggio 2021)**:
- Aggiornati i driver modificati in modo che compilino sui kernel Linux 5.10, 5.11 e 5.12.
- Aggiornato il firmware per i dispositivi `ath9k_htc` (non dovrebbe avere impatto sui test).
- Ristrutturato il repository per la release pubblica. Rimossi documenti interni e slide per fare invece riferimento
alle versioni pubbliche di questi documenti.
- Supporto di base per canali a 40 MHz quando si usa il parametro `--inject-test[-postauth]` per testare l'iniezione. Nei test
di vulnerabilità reali, l'uso di canali a 40 MHz non è testato (usa `disable_ht40` in `client.conf` se necessario).
**Versione 1.3.2 (8 marzo 2021)**:
- Aggiunti [handout](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) della presentazione e un
[riepilogo](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)
della causa principale e dell'impatto di ogni vulnerabilità.
- Aggiornato questo README per [spiegare](#id-test-sanity) che il parametro `--icmp-size 100` o simile può essere aggiunto a
tutti i test che inviano frame frammentati se il dispositivo in test accetta solo frammenti di una certa dimensione minima.
- Corretti piccoli refusi in questo README.
**Versione 1.3.1 (1 marzo 2021)**:
- Aggiunto il test [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) a questo README. Inietta un ping in chiaro
durante la connessione (cioè durante il 4-way handshake). Sia i client che gli AP possono essere vulnerabili a questo attacco.
- Aggiornata la [panoramica degli attacchi](#id-paper-clarifications) con nuovi esempi su come le vulnerabilità di iniezione di pacchetti
possono essere sfruttate in pratica. Questo include tecniche per indurre i client solo IPv4 a usare un server DNS dannoso
e tecniche per comunicare direttamente con dispositivi dietro un NAT/firewall (ad es. per sfruttare servizi locali).
- Chiarito che i [test di frammenti broadcast](#id-extended-bcast-check) possono essere eseguiti sia contro client che AP.
- Lo strumento di test ora verificherà se è stata caricata la versione prevista della libreria Python Scapy.
- Corretti alcuni riferimenti all'articolo in questo README (ora fa riferimento correttamente alle sezioni 6.4, 6.6 e 6.8).
- Aggiornato alla bozza versione 3 dell'articolo. Non ci sono modifiche importanti rispetto alla bozza versione 2, solo piccole modifiche testuali
e strutturali. Dal punto di vista dei contenuti questa è ora la versione finale dell'articolo.
**Versione 1.3 (20 gennaio 2021)**:
- Questa versione è basata sul commit hostap `a337c1d7c` ("New TWT operations and attributes to TWT Setup and Nudge").
- Aggiunta una [panoramica](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) degli attacchi e delle loro precondizioni e create [queste slide](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf)
per illustrare meglio come funziona in pratica l'attacco di aggregazione (CVE-2020-24588).
- Aggiunte <a href="#id-wpa3-sae">istruzioni</a> su come testare dispositivi WPA3/SAE usando il metodo hunting-and-pecking
o hash-to-element. Questo implica anche che la Management Frame Protection (MFP) è supportata dallo strumento di test.
- Aggiunta una precisazione a questo README su come usare tcpdump per verificare il risultato di alcuni test.
- Aggiunto il test aggiuntivo `ping BP --bcast-ra --bcast-dst` a questo README per poter testare CVE-2020-26145
contro AP che non possono eseguire tcpdump (con questo test tcpdump deve essere eseguito su un client connesso indipendente).
- Aggiunti i test aggiuntivi `ping I,E,F,E [--rekey-pl] [--rekey-req]` a questo README per rilevare meglio gli attacchi
a chiave mista (CVE-2020-24587) su alcuni dispositivi.
- Corretta l'iniezione di frame frammentati quando si usano dongle ath9k_htc in combinazione con 802.11n.
- Lo script `pysetup.sh` è stato aggiunto per creare l'ambiente virtuale Python. Questo script corregge anche
[un bug](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) nella libreria scapy
quando usata con Python 3.9.
- I driver patchati sono stati aggiornati per compilare correttamente su Linux 5.9.0.
- Corretto il test `ping-frag-sep`. In precedenza si comportava come `ping-frag-sep --pn-per-qos`. Nota che questo test
non viene usato per rilevare vulnerabilità ma solo per comprendere meglio le implementazioni.
**Versione 1.2 (15 novembre 2020)**:
- Questa versione (e precedenti) è basata sul commit hostap `1c67a0760` ("tests: Add basic power saving tests for ap_open").
- Lo strumento uscirà automaticamente dopo che un test è stato completato o è andato in timeout.
- Lo strumento rileva se il 4-way handshake è in loop o se non c'è risposta a una richiesta di rekey (`--rekey-req`).
- Quando si usa un server DHCP esterno, lo strumento ora invierà sempre frame EAPOL con indirizzo di destinazione
l'AP (invece del server DHCP). Questo è importante nei test di attacco a chiave mista e cache quando si usa un
server DHCP esterno.
- Quando si testa un AP usando `--rekey-req`, lo strumento ora invierà EAPOL Rekey Request con un Replay Counter di
uno invece che zero.
- L'output di debug ora mostra la chiave (di gruppo) corretta quando cifra frame broadcast/multicast. Questo non
influenza alcun risultato di test, cambia solo l'output dello strumento di test.
- Chiarito che tutti i comandi in questo README possono testare sia client che AP salvo diversa indicazione.
- Chiarite le descrizioni degli attacchi cache, del frammento broadcast e dei test di attacco A-MSDU EAPOL in questo README.
- Chiarito che è importante testare sia la banda a 2,4 che a 5 GHz in questo README.
**Versione 1.1 (20 ottobre 2020)**:
- Corretto un bug per cui il comando `ping I,E,D` inviava una normale richiesta ping cifrata. Ora invia una
richiesta ping cifrata con il flag More Fragments impostato nell'intestazione.
- Spostati i comandi `amsdu-inject-[bad]` nella Sezione 7 di questo README. Questi simulano attacchi reali e possono
essere usati per verificare se le mitigazioni temporanee funzionano (vedi Sezione 7.2 nell'articolo).
- Corretta l'ortografia di A-MSDU SPP in questo README e nello strumento di test. Il nuovo argomento `--amsdu-spp` ora è un
sinonimo del vecchio argomento `--amsdu-ssp`.
**Versione 1.0 (11 agosto 2020)**:
- Preparata la release iniziale per l'uso durante l'embargo.
| Scheda di rete | USB | 5GHz | modalità mista | modalità di iniezione |
|---|
| Technoethical N150 HGA | Sì | No | driver/firmware patchato | driver/firmware patchato |
| TP-Link TL-WN722N v1.x | Sì | No | driver/firmware patchato | driver/firmware patchato |
| Alfa AWUS036NHA | Sì | No | driver/firmware patchato | driver/firmware patchato |
| Intel Wireless-AC 8265 | No | Sì | driver patchato | sì |
| Intel Wireless-AC 3160 | No | Sì | driver patchato | sì |
| Alfa AWUS036ACM | Sì | Sì | driver patchato | sì |
| Netgear WN111v2 | Sì | No | driver patchato | sì |
| Alfa AWUS036ACH | Sì | Sì | no | sì |
| Comando | Breve descrizione |
|---|
ping | Invia un ping normale. |
ping I,E,E | Invia un ping frammentato normale. |
ping I,E,E --delay 5 | Invia un ping frammentato normale con un ritardo di 5 secondi tra i frammenti. |
ping-frag-sep | Invia un ping frammentato normale con frammenti separati da un altro frame. |
ping-frag-sep --pn-per-qos | Come sopra, ma funziona anche se il target accetta solo PN consecutivi. |
ping I,E --amsdu | Invia un ping incapsulato in un frame A-MSDU normale (non protetto da SPP). |
amsdu-inject | Simula l'attacco: invia un frame A-MSDU il cui inizio è anche un header rfc1042 valido. |
amsdu-inject-bad | Come sopra, ma contro target che analizzano il frame in modo errato. |
ping I,F,BE,AE | Inietta due frammenti cifrati con una chiave diversa. |
ping I,F,BE,AE --pn-per-qos | Come sopra, ma funziona anche se il target accetta solo PN consecutivi. |
ping I,E,R,AE | Inietta un frammento, tenta di innescare una riassociazione e inietta il secondo frammento. |
ping I,E,R,E | Come sopra, ma con un ritardo più lungo prima di inviare il secondo frammento. |
ping I,E,R,AE --full-recon | Inietta un frammento, deautentica e riconnettiti, poi inietta il secondo frammento. |
ping I,E,R,E --full-recon | Come sopra, ma con un ritardo più lungo prima di inviare il secondo frammento. |
ping I,E,E --inc-pn 2 | Invia un ping frammentato con numeri di pacchetto non consecutivi. |
ping I,E,P | Invia un ping frammentato: primo frammento cifrato, secondo frammento in chiaro. |
ping I,P,E | Invia un ping frammentato: primo frammento in chiaro, secondo frammento cifrato. |
ping I,P | Invia un ping in chiaro. |
ping I,P,P | Invia un ping frammentato: entrambi i frammenti sono inviati in chiaro. |
linux-plain | Attacco di frammentazione misto plaintext/cifrato specifico di Linux. |
ping I,D,P --bcast-ra | Invia un ping unicast in un secondo frammento broadcast in chiaro una volta connessi. |
ping D,BP --bcast-ra | Come sopra, ma il frame viene inviato durante l'handshake a 4 vie (verificare con tcpdump). |
eapol-amsdu I,P | Invia un A-MSDU in chiaro contenente una richiesta ping mascherata da frame EAPOL. |
eapol-amsdu BP | Come sopra, ma il frame viene inviato durante l'handshake (verificare con tcpdump). |
eapol-amsdu-bad I,P | Invia un A-MSDU in chiaro malformato contenente una richiesta ping mascherata da frame EAPOL. |
eapol-amsdu-bad BP | Come sopra, ma il frame viene inviato durante la connessione (verificare con tcpdump). |
Nel complesso, testare se un dispositivo è vulnerabile agli attacchi alla cache può essere noioso. Pertanto raccomando anche di eseguire un audit del codice per verificare se i frammenti rimangono in memoria dopo la dissociazione o la deautenticazione da una rete o dopo la riassociazione (questo può essere verificato anche dinamicamente tramite stampe di debug). Se i frammenti rimangono in memoria, dovresti considerarlo un rischio, anche se non è noto se possa essere sfruttato. Questo è simile a sapere che un'implementazione ha un buffer overflow ma non (ancora) sapere come sfruttarlo.
Esegui lo strumento con il parametro aggiuntivo --debug 2 per ottenere un output di debug aggiuntivo da wpa_supplicant o
hostapd e dallo strumento di test stesso.
Conferma usando una seconda interfaccia di monitoraggio che non vengano inviati altri frame tra i frammenti. Ad esempio, ho scoperto che il mio dispositivo Intel a volte invia frame Block Ack Response Action tra i frammenti, e questo interferiva con il processo di deframmentazione del dispositivo in test.
Ricontrolla di stare usando firmware modificato se necessario per la tua scheda di rete wireless. Lo strumento
di test verifica già automaticamente questo per i dispositivi ath9k_htc. Lo strumento verifica anche automaticamente
se stai usando driver modificati, anche se potrebbe essere utile ricontrollarlo manualmente sulla tua
specifica distribuzione Linux.
Può essere utile aggiungere un ritardo tra l'ottenimento dell'indirizzo IP e la trasmissione del primo frammento/frame.
Fallo usando il parametro --pre-test-delay.
| Comando | Breve descrizione |
|---|
ping I,E --amsdu-fake | Se questo test riesce, il flag A-MSDU viene ignorato (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | Verifica se il flag A-MSDU viene autenticato ma poi ignorato (§3.5). |
ping I,F,BE,E | Nel caso in cui la nuova chiave venga installata relativamente tardi. |
ping I,E,F,AE | Variante se nessun frame di dati viene accettato durante l'handshake di rekey. |
ping I,E,F,AE --rekey-plain | Se il dispositivo esegue l'handshake di rekey in plaintext. |
ping I,E,F,AE --rekey-plain --rekey-req | Come sopra, e richiedi attivamente un rekey come client. |
ping I,E,F,AE --rekey-early-install | Installa la nuova chiave dopo l'invio del messaggio 3 del 4-way handshake. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | Come i 4 test precedenti, ma con un ritardo maggiore prima del secondo frammento. |
ping I,F,BE,AE --freebsd | Attacco a chiave mista contro FreeBSD o implementazioni simili. |
ping I,E,R,AE --freebsd [--full-reconnect] | Attacco alla cache specifico per le implementazioni FreeBSD. |
ping I,E,R,AP --freebsd [--full-reconnect] | Attacco alla cache specifico per le implementazioni FreeBSD. |
ping I,E,R,AP [--full-reconnect] | Test dell'attacco alla cache in cui il secondo frammento viene inviato in plaintext. |
ping I,E,E --amsdu | Invia un ping normale come frame A-MSDU frammentato. |
ping I,E,P,E | Ping con il primo frammento cifrato, il secondo plaintext, il terzo cifrato. |
linux-plain 3 | Come linux-plain ma il frammento esca viene inviato usando la priorità QoS 3. |
ping I,P --bcast-ra | Ping in un frame broadcast plaintext dopo il 4-way HS. |
ping BP --bcast-ra [--bcast-dst] | Ping in un frame broadcast plaintext durante il 4-way HS (usa tcpdump). |
ping BP [--bcast-dst] | Ping in un frame plaintext durante il 4-way handshake (usa tcpdump). |
eapfrag BP,BP | Attacco sperimentale ai frammenti broadcast (usa tcpdump). |
eapol-amsdu[-bad] BP --bcast-dst | Come eapol-amsdu BP ma più facile da verificare contro gli AP (usa tcpdump). |
eapol-inject 00:11:22:33:44:55 | Verifica se l'AP inoltra frame EAPOL prima dell'autenticazione (usa tcpdump). |
eapol-inject-large 00:11:22:33:44:55 | Fai sì che l'AP invii frame frammentati tramite iniezione EAPOL (usa tcpdump). |
ping I,D,E | Invia ping all'interno di un secondo frammento cifrato (nessun primo frammento). |
ping I,E,D | Invia ping all'interno di un primo frammento cifrato (nessun secondo frammento). |
--rekey-pl--rekey-plainframe contains "test_ping_icmp"eapfrag BP,AE