vanhoefm/macstealerMacStealer: Wi-Fi Client Isolation Bypass
Questo repository contiene MacStealer. Può testare le reti Wi-Fi per bypass dell'isolamento client (CVE-2022-47522). Il nostro attacco può intercettare (rubare) il traffico verso altri client a livello MAC, anche se ai client è impedito di comunicare tra loro. Questa vulnerabilità riguarda le reti Wi-Fi con addetti interni malintenzionati, dove il nostro attacco può aggirare l'isolamento client, talvolta noto anche come isolamento AP. L'attacco può essere usato anche per aggirare Dynamic ARP inspection (DAI), e probabilmente può essere usato anche per aggirare altri metodi che impediscono ai client di attaccarsi a vicenda. L'attacco è anche noto come security context override attack, vedi la Sezione 5 del nostro articolo USENIX Security '23 (repository).
Esempi concreti di possibili reti interessate sono:
Reti aziendali in cui gli utenti possono diffidare gli uni degli altri e in cui tecniche come l'isolamento client o l'ARP inspection vengono usate per impedire agli utenti di attaccarsi a vicenda. Ad esempio, reti aziendali con account sia per ospiti che per personale, reti come eduroam e govroam, ecc.
Hotspot pubblici protetti da Passpoint (in precedenza Hotspot 2.0). Sono hotspot a cui puoi connetterti in modo automatico e sicuro. Ad esempio, può autenticarti senza problemi usando la scheda SIM del tuo telefono.
Reti domestiche WPA2 o WPA3 che hanno l'isolamento client abilitato. Questo include reti con un SSID separato per gli ospiti o per dispositivi non sicuri (IoT). Include anche reti in cui vengono usate più password per isolare ulteriormente i dispositivi, nota anche come Multi-PSK, Identity PSK, per-station PSK, o EasyPSK. Vedi la discussione del modello di minaccia per maggiori informazioni.
Hotspot pubblici basati su WPA3 SAE-PK. Sono hotspot protetti da una password pubblica condivisa, ma dove un avversario non può abusare di questa password pubblicamente nota.
Notiamo che il nostro attacco non può aggirare le VLAN. In altre parole, sulla base degli esperimenti attuali, il nostro attacco non può essere usato per compromettere un dispositivo in un'altra VLAN.
È disponibile anche il repository degli altri risultati del nostro USENIX Security '23.
L'idea alla base dell'attacco è che il modo in cui i client vengono autenticati non è correlato a come i pacchetti vengono instradati al client Wi-Fi corretto. In particolare, l'autenticazione avviene in base a password, nomi utente, identità 802.1X e/o certificati, ma una volta che il client si è connesso, l'instradamento dei pacchetti avviene in base agli indirizzi MAC. Un addetto interno malintenzionato può abusarne per intercettare i dati verso un client Wi-Fi disconnettendo una vittima e poi connettendosi con l'indirizzo MAC della vittima (usando le credenziali dell'avversario). Eventuali pacchetti ancora in viaggio verso la vittima, come i dati di un sito web che la vittima stava ancora caricando, verranno ora ricevuti dall'avversario.
Più precisamente, l'attacco consiste in tre passaggi:
Far sì che la vittima richieda dati: L'avversario prima aspetta che la vittima (client)
stabilisca una connessione Wi-Fi con il punto di accesso (AP) vulnerabile. Supponiamo che la vittima
invii quindi una richiesta a un server su Internet. Ad esempio, la vittima può inviare una
richiesta HTTP al sito web (in chiaro) example.com. L'obiettivo dell'avversario è
intercettare la risposta che verrà inviata dal sito web.
Connettersi con l'indirizzo MAC della vittima: Dopo che la vittima ha richiesto dati, ad esempio
inviando un pacchetto di richiesta HTTP, l'avversario disconnette forzatamente la vittima dalla
rete prima che la risposta arrivi all'
AP vulnerabile. Nel nostro esempio, ciò significa che la vittima viene disconnessa prima che la risposta da
example.com arrivi all'AP. Una volta che la vittima è disconnessa, l'avversario spoofa
l'indirizzo MAC della vittima e si connette alla rete usando le proprie
credenziali. Ciò significa che l'avversario è un addetto interno malintenzionato che può connettersi alla rete usando le proprie
credenziali, ad esempio usando il proprio nome utente e password in una
rete Wi-Fi Enterprise.
Intercettare la risposta: Una volta che l'avversario si è connesso con l'indirizzo MAC della vittima,
l'AP assocerà le chiavi di cifratura appena generate dall'avversario all'indirizzo MAC della vittima.
Di conseguenza, quando la risposta dal server arriva alla rete Wi-Fi, o qualsiasi traffico in entrata
verso la vittima in generale, il router inoltrerà questi pacchetti in entrata all'indirizzo MAC della
vittima. Nel nostro esempio, ciò significa che la risposta da example.com viene inoltrata dal router
all'indirizzo MAC della vittima. Tuttavia, l'avversario sta ora usando questo indirizzo MAC. Questo significa che
l'AP cifrerà la risposta usando le chiavi dell'avversario. In altre parole, l'avversario
riceverà ora qualsiasi traffico pendente che è ancora in viaggio verso la vittima.
Notiamo che il traffico intercettato può essere protetto da crittografia di livello superiore, come TLS e HTTPS. Tuttavia, anche se viene usata una crittografia di livello superiore, il nostro attacco rivela comunque l'indirizzo IP con cui una vittima sta comunicando. Questo a sua volta rivela i siti web che una vittima sta visitando, che possono essere informazioni sensibili di per sé.
Per impostazione predefinita, l'attacco non intercetta il traffico inviato dalla vittima, ma può solo intercettare il traffico inviato verso la vittima. Tuttavia, un avversario può tentare attacchi successivi per intercettare anche il traffico inviato dalla vittima. In particolare, intercettando una risposta DNS destinata alla vittima, l'avversario può spoofare una risposta DNS e intercettare tutto il traffico IP sia inviato verso la vittima sia inviato dalla vittima.
Eseguire l'attacco sopra descritto ha senso solo quando l'isolamento client è abilitato nella rete di destinazione. Altrimenti, se l'isolamento client è disabilitato, un addetto interno malintenzionato può semplicemente attaccare direttamente altri client usando tecniche come ARP spoofing (vedi i test di isolamento client).
L'attacco è identico contro le reti Enterprise WPA1, WPA2 e WPA3. Questo perché l'attacco non sfrutta alcuna proprietà crittografica del Wi-Fi, ma abusa invece di come una rete determina a quale client i pacchetti devono essere inviati, cioè instradati.
Per ulteriori dettagli sull'attacco, vedi il security context override attack (Sezione 5) nel nostro articolo Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues.
Per mitigare il nostro attacco, un AP può impedire temporaneamente ai client di connettersi se stanno usando un indirizzo MAC che è stato connesso di recente all'AP. Questo impedisce a un avversario di spoofare un indirizzo MAC e intercettare frame pendenti o in coda verso una vittima. Quando si può garantire che l'utente dietro un indirizzo MAC non è cambiato, al client può essere consentito di riconnettersi immediatamente. Nota che questo controllo deve essere eseguito su tutti gli AP che fanno parte dello stesso sistema di distribuzione e, più specificamente, su tutti gli AP tra cui i client possono fare roaming mantenendo il loro attuale indirizzo IP.
Per riconoscere in modo sicuro gli utenti connessi di recente, un AP può memorizzare una mappatura tra l'indirizzo MAC di un client e le sue associazioni di sicurezza memorizzate nella cache (ad esempio, la PMK memorizzata nella cache). A un client può essere consentito di riconnettersi immediatamente usando un indirizzo MAC usato di recente dimostrando di possedere l'associazione di sicurezza memorizzata nella cache collegata a questo indirizzo MAC, ad esempio connettendosi usando la PMK corretta memorizzata nella cache.
Quando si usa multi-PSK, nota anche come per-station PSK o Identity PSK, l'AP può mantenere una mappatura degli indirizzi MAC connessi di recente e della password (unica) che hanno usato. Quando un client si connette, l'AP verifica se il suo indirizzo MAC è stato usato di recente. Se non lo è, o se lo è e il client sta usando la stessa password di prima, il client può connettersi normalmente. Tuttavia, se lo stesso indirizzo MAC viene usato con una password diversa, il client è costretto ad aspettare una quantità di tempo predefinita prima di poter completare la connessione.
Quando si usa SAE-PK per proteggere gli hotspot, l'unico metodo di cui siamo a conoscenza per riconoscere in modo sicuro che un indirizzo MAC viene riutilizzato dallo stesso utente di prima è fare affidamento sulle associazioni di sicurezza memorizzate nella cache (ad esempio, la PMK memorizzata nella cache collegata all'indirizzo MAC).
Le difese sopra descritte presuppongono che, dopo un certo ritardo, non arriveranno più pacchetti pendenti per la vittima. Per prevenire perdite oltre questo ritardo, i client possono usare crittografia end-to-end (come TLS) con i servizi con cui comunicano.
Quando si usa l'autenticazione 802.1X basata su EAP, un metodo alternativo migliore per riconoscere in modo sicuro gli utenti connessi di recente si basa sull'identità EAP che hanno usato durante l'autenticazione 802.1X. Un AP può apprendere in modo sicuro l'identità EAP dal server RADIUS che ha autenticato il client e può mantenere una mappatura degli indirizzi MAC connessi di recente e della loro corrispondente identità EAP. Quando un client si connette, l'AP verifica se il suo indirizzo MAC è stato usato di recente. Se non lo è, o se lo è e il client sta usando la stessa identità EAP di prima, il client può connettersi normalmente. Tuttavia, se lo stesso indirizzo MAC viene usato con un'identità EAP diversa, il client è costretto ad aspettare una quantità di tempo predefinita prima di poter completare la connessione con successo.
Una sfida è che l'AP potrebbe non conoscere sempre l'identità 802.1X di un client per problemi di privacy. Ad esempio, queste informazioni potrebbero essere disponibili solo presso il server AAA domestico, e l'AP riceverà solo una Chargeable User Identity dal server RADIUS. Questa identità non consente all'AP di riconoscere due associazioni dello stesso dispositivo/credenziali perché il suo valore può cambiare costantemente. L'AP riceve comunque l'identità anonima nella EAP-Response/Identity, come anonymous@realm, e può fare affidamento su di essa per riconoscere almeno gli utenti di realm diversi.
Per impedire agli utenti dello stesso realm di attaccarsi a vicenda, senza rivelare l'identità di un client all'AP, sono necessarie cooperazione e modifiche al server RADIUS. In particolare, il server RADIUS può essere aggiornato per aiutare a rilevare se l'indirizzo MAC è stato usato di recente da un altro utente dello stesso realm (nella data rete locale). Il server RADIUS dovrebbe quindi essere informato quando un client si disconnette, così sa quando un indirizzo MAC è stato usato l'ultima volta da uno dei suoi utenti, e deve essere informato dell'indirizzo MAC di qualsiasi client che sta tentando di connettersi.
Un'ultima nota è che, mentre questo approccio basato sull'identità EAP impedirebbe a utenti diversi di attaccarsi a vicenda, non impedirebbe a un dispositivo compromesso di attaccare un altro dispositivo dello stesso utente. Cioè, gli attacchi sarebbero prevenuti solo tra utenti diversi, ma non tra dispositivi diversi dello stesso utente.
È importante notare che il nostro attacco non si limita a intercettare pacchetti diretti ai client Wi-Fi. Un avversario potrebbe anche tentare di associarsi con l'indirizzo MAC di un gateway predefinito o di un altro server nella rete locale. Per prevenire tali attacchi, l'AP o il controller può vietare ai client di usare un indirizzo MAC uguale a quello del gateway predefinito. Più in generale, il rilevamento di indirizzi MAC duplicati può essere usato quando un client Wi-Fi si connette alla rete, per impedire ai client Wi-Fi di usare un indirizzo MAC che è in uso anche da altri dispositivi nella rete.
Usare la protezione dei frame di gestione (MFP) renderebbe l'attacco più difficile ma non impossibile. In lavori precedenti, abbiamo trovato alcuni modi in cui i client possono essere disconnessi/deautenticati anche quando viene usata la MFP. Sulla base di quella esperienza, sembra esserci sempre qualche metodo per disconnettere forzatamente un client dalla rete, anche quando viene usata la MFP. In altre parole, è difficile prevenire completamente gli attacchi di disconnessione e deautenticazione. Detto questo, la MFP sarebbe un ostacolo in più da superare quando si esegue l'attacco nella pratica, quindi può essere una mitigazione utile per rendere l'attacco più difficile (ma non impossibile) nella pratica.
Sulla base di esperimenti preliminari, l'attacco non funziona attraverso VLAN diverse. In altre parole, l'addetto interno malintenzionato che esegue l'attacco deve essere nella stessa VLAN della vittima. Una mitigazione è quindi quella di mettere diversi gruppi di utenti in VLAN diverse. Tuttavia, un addetto interno malintenzionato sarebbe comunque in grado di eseguire l'attacco (cioè aggirare l'isolamento client) contro altri utenti nella stessa VLAN.
Nota che quando si usa multi-PSK (noto anche come per-station PSK o identity PSK), puoi mettere i client in VLAN diverse a seconda della password che usano. In altre parole, puoi usare una VLAN per ogni password. Questo impedisce a client con password diverse di attaccarsi a vicenda.
Lo strumento MacStealer funziona con qualsiasi scheda di rete supportata da Linux. Abbiamo testato MacStealer su Ubuntu 22.04. Per installare le dipendenze richieste su Ubuntu 22.04 esegui:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential net-tools python3-venv \
aircrack-ng rfkill
Ora clona questo repository, compila gli strumenti e configura un ambiente virtuale python3:
git clone https://github.com/vanhoefm/macstealer.git macstealer
cd macstealer/research
./build.sh
./pysetup.sh
Le istruzioni sopra devono essere eseguite solo una volta.
Dopo aver scaricato nuovo codice usando git, devi eseguire di nuovo ./build.sh e ./pysetup.sh.
Vedi il registro delle modifiche per una panoramica dettagliata degli aggiornamenti a MacStealer
dall'inizio della divulgazione coordinata.
Ogni volta che vuoi usare MacStealer, devi prima caricare l'ambiente virtuale python3 come root. Puoi farlo usando:
cd research
sudo su
source venv/bin/activate
Ora dovresti disabilitare il Wi-Fi nel tuo gestore di rete
così non interferirà con MacStealer. Facoltativamente, controlla usando sudo airmon-ng check per vedere
quali altri processi potrebbero usare la scheda di rete wireless e interferire con MacStealer.
Il passo successivo è modificare client.conf con le informazioni della rete che vuoi testare.
Questa è una configurazione per wpa_supplicant
che deve contenere due blocchi di rete: uno che rappresenta la vittima e uno che rappresenta
l'attaccante. Un esempio di file di configurazione per testare la rete fittizia kuleuven è:
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test: fill in properties of the network to test
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Victim login: fill in login credentials representing the victim
identity="[email protected]"
password="SuperSecret"
}
network={
# Don't change this field, the script relies on it
id_str="attacker"
# Network to test: you can copy this from the previous block
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Attacker login: fill in login credentials representing the attacker
identity="[email protected]"
password="SomePassword"
}
Nella parte "network to test" devi fornire il nome della rete in esame e la sua configurazione di sicurezza. Vedi wpa_supplicant.conf per documentazione su come scrivere/modificare i file di configurazione e per esempi di blocchi di rete per vari tipi di reti Wi-Fi. Nel primo blocco di rete, sotto "victim login", devi specificare credenziali di accesso valide che rappresentano la vittima simulata. Nel secondo blocco di rete, puoi fornire esattamente le stesse informazioni sotto "network to test", ma devi fornire credenziali di accesso che rappresentano l'attaccante simulato.
Nell'esempio sopra, MacStealer testerà un attacco in cui l'avversario è [email protected]
e questo avversario cercherà di intercettare il traffico inviato verso la vittima [email protected].
Per impostazione predefinita lo script usa il file di configurazione client.conf. Puoi usare un file di
configurazione diverso fornendo il parametro --config network.conf, dove puoi sostituire
network.conf con il file di configurazione che vuoi usare.
Questo repository contiene anche i seguenti file di configurazione di esempio:
multipsk.conf: Un file di configurazione per testare una rete che
usa multi-PSK in cui una password è usata dai dispositivi fidati e una seconda password è
data agli ospiti.
saepk.conf: Un file di configurazione per testare un hotspot pubblico che
usa SAE-PK.
Nota che è anche possibile modificare il o i blocchi di rete per testare un AP/BSS specifico.
Per impostazione predefinita, MacStealer invierà un pacchetto TCP SYN a 8.8.8.8 sulla porta 443 in tutti i test, che è un
server DNS di Google. Se vuoi usare un server o una porta diversa, puoi fornirne uno usando
il parametro --server. Ad esempio:
./macstealer.py wlan0 --server 208.67.222.222
Puoi anche aggiungere la porta che deve essere usata nei pacchetti TCP SYN:
./macstealer.py wlan0 --server 208.67.222.222:80
Sostituisci wlan0 con il nome della tua interfaccia Wi-Fi e l'indirizzo IP con il server
che vuoi usare.
Questo server deve ritrasmettere le risposte TCP SYN/ACK e, idealmente, dovrebbe inviare ancora una
SYN/ACK ritrasmessa più di 10 secondi dopo che MacStealer ha trasmesso il SYN TCP iniziale. Puoi
testare questo comportamento di ritrasmissione usando il parametro --ping come segue:
./macstealer.py wlan0 --server 208.67.222.222 --ping
MacStealer produrrà il seguente output nel caso in cui il server abbia il comportamento di ritrasmissione richiesto:
[22:53:15] Received SYN/ACK 15.265095233917236 seconds after sending SYN.
[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.
Nel caso in cui il server fornito non invii risposte TCP SYN/ACK, o non le ritrasmetta abbastanza tardi, MacStealer produrrà il seguente output:[22:52:05] Received SYN/ACK 1.0727121829986572 seconds after sending SYN. [22:52:24] >>> Ping test done. Consider using a server that retransmits SYN/ACK for a longer time.
Il motivo per cui il server deve comunque ritrasmettere un SYN/ACK dopo più di 10 secondi è che a volte possono essere necessari diversi secondi per riconnettersi come attaccante simulato. Questo processo di riconnessione deve completarsi prima che il server invii l'ultimo pacchetto TCP SYN/ACK ritrasmesso.
La tabella seguente contiene i comandi più comuni che eseguirai quando testi una rete insieme a una breve descrizione di ciò che fa ciascun comando. Sotto la tabella vengono spiegati i dettagli di ciascun comando.
Se la rete in fase di test utilizza la Management Frame Protection (802.11w), lo strumento presume che l'avversario possa comunque scollegare con la forza la vittima dalla rete. Questa ipotesi si basa su ricerche recenti che hanno dimostrato che gli attacchi di disconnessione sono in genere ancora possibili, sebbene meno diretti e meno generali, quando si usa MFP.
Prima di testare le vulnerabilità, puoi usare i seguenti due comandi per confermare che MacStealer sia in grado di connettersi alla rete sia come vittima sia come attaccante:
./macstealer.py wlan0 --ping: si connette alla rete usando le credenziali della vittima.
Una volta connesso, viene inviato un SYN TCP al server (che per impostazione predefinita è 8.8.8.8 e può essere modificato).
MacStealer verifica se e quante volte il SYN/ACK viene (ri)trasmesso. Puoi usare
questo test per confermare che le credenziali della vittima siano corrette e per verificare
che il server configurato ritrasmetta correttamente le risposte SYN/ACK.
./macstealer.py wlan0 --ping --flip: come il test precedente, ma ora lo script si connette
usando le credenziali dell'avversario. Puoi usarlo per confermare che le credenziali
dell'avversario siano corrette.
./macstealer.py wlan0: testa la variante predefinita dell'attacco di furto dell'indirizzo MAC. L'attaccante
si riconnette allo stesso AP/BSS della vittima.
./macstealer.py wlan0 --other-bss: l'attaccante si connette a un AP/BSS diverso della stessa
rete. Una rete che è (anche) vulnerabile a questo test è più facile da sfruttare nella pratica. Se solo
un singolo AP/BSS è nel raggio radio, lo script andrà in timeout durante la connessione come attaccante.
Sfruttare la vulnerabilità del furto dell'indirizzo MAC ha senso solo se l'isolamento client è abilitato o quando vengono usate tecniche come l'ARP inspection per impedire ai client di attaccarsi a vicenda. Altrimenti, un avversario può usare attacchi più semplici come l'ARP poisoning per intercettare il traffico. Per verificare se l'isolamento client è abilitato o se la rete usa l'ARP inspection, puoi usare i seguenti comandi:
./macstealer.py wlan0 --c2c wlan1: con questi argomenti, MacStealer verifica se la rete
consente il traffico client-to-client di ARP poisoning dall'attaccante (wlan1) verso la vittima (wlan0).
Qui wlan1 è una seconda interfaccia di rete wireless. Lo script verifica quindi se è possibile
inviare pacchetti ARP dannosi dall'attaccante alla vittima.
./macstealer.py wlan0 --c2c-eth wlan1: simile al test precedente, ma invece di inviare
pacchetti ARP dannosi, l'attaccante invia pacchetti DNS alla vittima.
La vulnerabilità del furto dell'indirizzo MAC dovrebbe essere considerata un rischio nella pratica se il traffico client-to-client viene bloccato in uno dei due test precedenti (ovvero quando l'isolamento client è abilitato o quando vengono usate altre tecniche come l'ARP inspection per impedire agli utenti di attaccarsi a vicenda).
Per impostazione predefinita, MacStealer tenta di connettersi allo stesso AP/BSS usando entrambe le interfacce, quindi è
importante che entrambe le schede di rete possano vedere le stesse reti (cioè assicurati che entrambe le
interfacce di rete supportino le stesse bande di frequenza e gli stessi canali). Se vuoi che entrambi i client
si connettano a un AP/BSS diverso, puoi usare il parametro --other-bss.
Puoi usare il parametro --flip-id per verificare se il traffico dalla vittima (wlan0) è consentito
verso l'attaccante (wlan1).
Se MacStealer sembra non funzionare, controlla quanto segue:
Verifica che nessun altro processo stia usando la scheda di rete (ad es. termina il tuo network manager).
Potresti vedere l'output kernel reports: match already configured se un altro processo
sta usando la scheda di rete.
Se tutto funzionava in precedenza, prova a scollegare la chiavetta Wi-Fi, riavvia il computer o la macchina virtuale e poi riprova.
Conferma di connetterti alla rete corretta. Ricontrolla client.conf.
Se hai aggiornato il codice con git, esegui di nuovo ./build.sh e ./pysetup.sh (vedi Prerequisiti).
Se stai usando una macchina virtuale, prova invece a eseguire MacStealer da un'installazione Linux nativa.
Esegui MacStealer con il parametro aggiuntivo -dd per ottenere un output di debug aggiuntivo da wpa_supplicant
e da MacStealer stesso.
I test di isolamento client predefiniti verificano se il traffico a livello Ethernet è consentito tra i client. È anche possibile verificare se il traffico a livello IP è consentito tra i client usando il seguente comando:
./macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]
Quando il traffico a livello IP tra client è consentito, è ancora possibile che i client si attacchino a vicenda. Ad esempio, gli attacchi di reindirizzamento ICMP potrebbero essere ancora possibili. Tali attacchi sono più complessi dell'ARP spoofing, ma idealmente dovrebbero essere comunque prevenuti bloccando anche il traffico a livello IP tra i client.
I seguenti test possono essere eseguiti per verificare le proprietà generali di una rete. Questi test non sono direttamente collegati alle vulnerabilità ma possono essere usati per comprendere meglio il comportamento di una rete.
./macstealer.py wlan0 --same-id [--other-bss] [--flip]: verifica se le connessioni TCP restano attive dopo la
disconnessione e la riconnessione a un Access Point. Se le connessioni non restano attive dopo la riconnessione,
probabilmente la rete non è vulnerabile agli attacchi di furto dell'indirizzo MAC. Tuttavia, un grosso svantaggio
di questo comportamento è che i client legittimi devono aprire nuove connessioni TCP ogni volta che si riconnettono
a questa rete, rendendo la rete apparentemente lenta e inaffidabile (quindi dovrebbe essere usata una difesa migliore
invece).
Puoi usare il parametro --other-bss per riconnetterti a un AP/BSS diverso della stessa rete.
Puoi usare l'argomento --flip per eseguire questo test con l'identità dell'attaccante invece
di quella della vittima.
./macstealer.py wlan0 --flip: testa il normale attacco di furto dell'indirizzo MAC, ma inverte i
ruoli di attaccante e vittima. In altre parole, l'attaccante userà le "credenziali della vittima"
fornite nel file di configurazione, e la vittima userà le "credenziali dell'avversario".
./macstealer.py wlan0 --c2c wlan1 --same-id [--flid-id]: verifica se il traffico client-to-client è
consentito tra due dispositivi dello stesso utente. Vedi test di isolamento client per
la documentazione sul parametro wlan1.
Puoi usare l'argomento --flip per eseguire questo test con l'identità dell'attaccante invece
di quella della vittima.
--delay seconds: puoi usare il parametro --delay per specificare un ritardo, in secondi, prima di riconnettersi come
attaccante.
-d o -dd: l'aggiunta di uno di questi parametri aumenta la verbosità di debug dello script
e dell'istanza sottostante di wpa_supplicant.
Per impostazione predefinita, MacStealer seleziona automaticamente un AP/BSS della rete a cui connettersi e da testare.
Se hai una rete con più AP/BSS, puoi testarne uno specifico indicando questo
AP/BSS nel blocco di rete della vittima usando la parola chiave bssid. Ad esempio, puoi usare:
...
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test: fill in properties of the network to test
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Victim login: fill in login credentials representing the victim
identity="[email protected]"
password="SuperSecret"
# This a specific AP/BSS
bssid=00:11:22:33:44:55
}
...
Con la configurazione precedente, MacStealer testerà 00:11:22:33:44:55. Ciò significa che si connetterà
a questo AP sia come vittima sia come attaccante.
Puoi anche combinare questa impostazione con il parametro --other-bss. In tal caso, la vittima si
connetterà a 00:11:22:33:44:55, e l'attaccante si connetterà a un AP/BSS diverso della
stessa rete.
Un'altra opzione è specificare un BSS/AP esplicito nel blocco di rete della vittima e dell'attaccante.
Nota che MacStealer cercherà l'AP/BSS indicato per al massimo 30 secondi. Se non riesce a trovare l'AP/BSS specificato, lo strumento terminerà.
Puoi testare una rete SAE-PK usando il seguente file di configurazione. Nota che per le reti SAE-PK non c'è differenza nel modo in cui vittima e attaccante si autenticano, cioè entrambi usano la stessa password.
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl
# WPA3/SAE: support both hunting-and-pecking loop and hash-to-element
sae_pwe=2
network={
# Don't change this field, the script relies on it
id_str="attacker"
# Network to test - attacker login
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test - victim login
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
In pratica, l'isolamento client viene usato anche in reti protette da una password pre-condivisa. Ad esempio, diversi router offrono l'opzione di creare una rete per ospiti o dispositivi insicuri (IoT), in cui i client sono isolati così da non potersi attaccare a vicenda. Tuttavia, il vantaggio di sicurezza dell'uso dell'isolamento client in questo scenario può essere messo in discussione. L'isolamento client dovrebbe impedire a un insider malintenzionato di attaccare gli altri. Ma se l'insider malintenzionato conosce la password pre-condivisa, può semplicemente creare un clone rogue (evil twin), convincere le vittime a connettersi a questa copia maliziosa della rete e poi attaccare altri client! In altre parole, usare l'isolamento client in una rete protetta da password non fornisce una sicurezza forte: un client malintenzionato può creare un AP rogue per attaccare comunque altri client.
Detto questo, si può sostenere che la creazione di un AP rogue possa essere rilevata dall'amministratore di rete, il che significa che l'isolamento client rende gli attacchi più difficili. Inoltre, quando un dispositivo leggero viene compromesso (da remoto), potrebbe non avere le risorse per agire (facilmente) come AP rogue. Questo rende più difficile, ma non impossibile, eseguire attacchi quando è attivo l'isolamento client. Nel complesso, sebbene l'isolamento client non fornisca forti garanzie di sicurezza in una rete protetta da password, si può sostenere che aumenti la difficoltà pratica di eseguire attacchi.
Il nostro attacco MacStealing è più semplice da eseguire rispetto alla creazione di un AP rogue. Tutto ciò che l'insider malintenzionato, ad esempio un dispositivo IoT leggero compromesso, deve fare è spoofare un indirizzo MAC e (ri)connettersi alla rete. Un attacco di questo tipo è anche più difficile da rilevare. Sulla base di questa osservazione, il nostro nuovo attacco peggiora la situazione e quindi si può sostenere che il nostro attacco debba essere considerato rilevante anche nelle reti protette da una password pre-condivisa.
Conclusione: quando si usa l'isolamento client in una rete protetta da password, si assume che un insider malintenzionato non creerà un AP rogue. In caso contrario, l'uso dell'isolamento client è privo di significato dal punto di vista della sicurezza. L'attacco MacStealing può essere eseguito senza creare un AP rogue e quindi rende gli attacchi più semplici.
L'obiettivo del nostro attacco non è bypassare le liste di blocco/consentite degli indirizzi MAC sugli Access Point. Lo spoofing degli indirizzi MAC per bypassare il filtraggio degli indirizzi MAC è un attacco diverso e noto.
L'obiettivo del nostro attacco non è dirottare la connessione a pagamento di qualcuno negli hotspot Wi-Fi. Ad esempio, alcuni hotspot aperti (o protetti) richiedono all'utente di pagare prima di poter accedere a Internet. Spesso un abbonato pagante viene riconosciuto in base al suo indirizzo MAC, e un avversario può spoofare l'indirizzo MAC di una vittima per ottenere accesso a Internet. Questo non è lo scopo del nostro attacco; l'obiettivo di MacStealer è bypassare l'isolamento client.
Il nostro attacco colpisce anche le reti che si difendono dalla vulnerabilità Hole 196. Ad esempio, le reti Passpoint (precedentemente Hotspot 2.0) sono tenute a prevenire la vulnerabilità Hole 196, ma sono comunque vulnerabili al nostro attacco.
Il nostro attacco funziona in reti che si difendono dall'ARP spoofing. Nelle reti Wi-Fi scarsamente protette, un avversario può eseguire banalmente l'ARP spoofing per intercettare il traffico di una vittima, e il nostro attacco non è davvero pratico. Tuttavia, le reti moderne, che possono contenere insider malintenzionati, si affidano all'isolamento client o ad altri metodi per prevenire gli attacchi machine-in-the-middle. Il nostro attacco bypassa tutte queste difese moderne e consente comunque a un avversario di intercettare il traffico verso una vittima.
Per riassumere, il nostro attacco colpisce le reti Wi-Fi in cui ai client è impedito di attaccarsi a vicenda, consentendo a un avversario di intercettare il traffico verso un altro client.
La maggior parte dei vendor usa CVE-2022-47522 per riferirsi alla vulnerabilità di bypass dell'isolamento client Wi-Fi discussa in questo repository git. Questa vulnerabilità corrisponde all'attacco nella Sezione 5 del nostro articolo.
Purtroppo, altri vendor usano anche questo CVE per riferirsi alla vulnerabilità (strettamente parlando non correlata) discussa nella Sezione 3 del nostro articolo. In effetti, la descrizione effettiva del CVE che si trova su MITRE, a nostro parere, descrive solo l'attacco nella Sezione 3 del nostro articolo. Nella pratica, sembra che CVE-2022-47522 venga usato per riferirsi a tutti gli attacchi del nostro articolo, anche se tecnicamente sono diversi.
Versione 1.2 (in corso)
README migliorato: chiarito l'uso dell'identificativo CVE.
README migliorato: introduzione focalizzata sul bypass dell'isolamento client, aggiornate le difese con note su 802.1X e per prevenire il furto dell'indirizzo MAC del gateway predefinito.
Aggiunto il parametro --delay per specificare un ritardo in secondi prima di riconnettersi come attaccante.
Versione 1.1 (18 gennaio 2023)
Per impostazione predefinita usa 8.8.8.8 come server invece di 216.58.208.100 (entrambi sono server Google).
Aggiornati i test di isolamento client: per impostazione predefinita testa usando ARP poisoning a livello Ethernet. Fornisce anche l'opzione per inviare dati UDP con forwarding a livello Ethernet e un test con forwarding a livello IP.
README migliorato: aggiornati i tipi di rete che potrebbero essere interessati. Inclusa una discussione su se le reti WPA2 o WPA3 protette da password siano interessate. Spiegazione dei diversi comandi per testare il traffico client-to-client a livello Ethernet o IP.
README migliorato: discussione su MFP, discussione sulle VLAN come mitigazione, chiarimento su quali AP deve essere eseguita la verifica dell'identità, specifica della porta del server,
Migliorato l'output di MacStealer.
Versione 1.0 (3 gennaio 2023):
| Command | Short description |
|---|
./macstealer.py wlan0 --ping | Si connette come vittima e verifica il comportamento di ritrasmissione del server. |
./macstealer.py wlan0 --ping --flip | Si connette come attaccante e verifica il comportamento di ritrasmissione del server. |
./macstealer.py wlan0 | Testa la variante predefinita dell'attacco di furto dell'indirizzo MAC. |
./macstealer.py wlan0 --other-bss | Consente all'attaccante di connettersi a un AP diverso rispetto alla vittima. |
./macstealer.py wlan0 --c2c wlan1 | Testa il traffico client-to-client a livello Ethernet (ARP poisoning). |
./macstealer.py wlan0 --c2c-eth wlan1 | Testa il traffico client-to-client a livello Ethernet (DNS). |