
MacStealer: Bypass dell'isolamento del client Wi-Fi
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.