Mathy Vanhoef, autore dell'attacco KRACK alle reti wireless, ha rivelato informazioni su 12 vulnerabilità che interessano vari dispositivi wireless. I problemi identificati sono conosciuti con il nome in codice FragAttacks e riguardano praticamente tutte le schede wireless e i punti di accesso attualmente in uso: dei 75 dispositivi testati, ognuno era vulnerabile ad almeno uno dei metodi di attacco proposti.
I problemi sono suddivisi in due categorie: 3 vulnerabilità sono state individuate direttamente negli standard Wi-Fi e interessano tutti i dispositivi che supportano gli attuali standard IEEE 802.11 (i problemi persistono dal 1997). 9 vulnerabilità riguardano errori e mancanze nelle implementazioni specifiche degli stack wireless. La seconda categoria rappresenta il principale pericolo, poiché organizzare attacchi su difetti degli standard richiede impostazioni specifiche o l'esecuzione di determinate azioni da parte della vittima. Tutte le vulnerabilità si manifestano indipendentemente dall'uso di protocolli per garantire la sicurezza del Wi-Fi, incluso l'uso di WPA3.
La maggior parte dei metodi di attacco identificati consente a un aggressore di effettuare sostituzioni di frame L2 in una rete protetta, il che consente di infiltrarsi nel traffico della vittima. Uno degli scenari di attacco più realistici menziona la sostituzione delle risposte DNS per reindirizzare l'utente verso l'host dell'attaccante. Viene anche fornito un esempio di utilizzo delle vulnerabilità per aggirare il traduttore degli indirizzi su un router wireless e organizzare un accesso diretto a un dispositivo nella rete locale o ignorare le restrizioni del firewall. La seconda parte delle vulnerabilità, legata alla gestione dei frame frammentati, consente di estrarre dati sul traffico in una rete wireless e di intercettare i dati dell'utente trasmessi senza crittografia.
Un ricercatore ha preparato una dimostrazione che mostra come è possibile utilizzare le vulnerabilità per intercettare una password trasmessa durante la navigazione su un sito tramite il protocollo HTTP non crittografato. Viene anche mostrato come attaccare una presa intelligente controllata via Wi-Fi e usarla come trampolino per continuare l'attacco su dispositivi non aggiornati nella rete locale, che presentano vulnerabilità non corrette (ad esempio, è stato possibile attaccare un computer non aggiornato con Windows 7 sulla rete interna bypassando il NAT).
Per sfruttare le vulnerabilità, un attaccante deve trovarsi a portata di un dispositivo wireless di destinazione per inviare alla vittima un set di pacchetti appositamente formattati. I problemi riguardano sia i dispositivi client che le schede wireless, così come i punti di accesso e i router Wi-Fi. In generale, come misure di protezione alternative è sufficiente utilizzare HTTPS insieme alla crittografia del traffico DNS attraverso DNS over TLS o DNS over HTTPS. È possibile applicare anche VPN.
Le quattro vulnerabilità che si considerano più pericolose nelle implementazioni dei dispositivi wireless consentono di ottenere facilmente l'inserimento dei propri pacchetti non crittografati:
- Le vulnerabilità CVE-2020-26140 e CVE-2020-26143 consentono l'inserimento di pacchetti su alcuni punti di accesso e schede wireless in Linux, Windows e FreeBSD.
- La vulnerabilità VE-2020-26145 consente il trattamento dei frammenti broadcast non crittografati come pacchetti completi in macOS, iOS, FreeBSD e NetBSD.
- La vulnerabilità CVE-2020-26144 consente il trattamento dei pacchetti ricompattati A-MSDU non crittografati con EtherType EAPOL in Huawei Y6, Nexus 5X, FreeBSD e LANCOM AP.
Altre vulnerabilità nelle implementazioni sono principalmente legate a problemi che si verificano durante l'elaborazione dei pacchetti frammentati:
- CVE-2020-26139: consente il reindirizzamento dei pacchetti con il flag EAPOL, inviati da un mittente non autenticato (riguarda 2/4 punti di accesso verificati, così come le soluzioni basate su NetBSD e FreeBSD).
- CVE-2020-26146: consente la ricompattazione di frammenti crittografati senza controllare l'ordine dei numeri di sequenza.
- CVE-2020-26147: consente la ricompattazione di frammenti crittografati e non crittografati misti.
- CVE-2020-26142: consente di trattare i pacchetti frammentati come pacchetti completi (riguarda OpenBSD e il modulo wireless ESP12-F).
- CVE-2020-26141: manca un controllo TKIP MIC per i pacchetti frammentati.
Problemi nelle specifiche:
- CVE-2020-24588 è un attacco ai frame aggregati (il flag 'is aggregated' non è protetto e può essere sostituito dall'attaccante nei frame A-MSDU in WPA, WPA2, WPA3 e WEP). Come esempio di applicazione dell'attacco si menziona il reindirizzamento dell'utente a un server DNS malevolo o il bypass del NAT.
- CVE-2020-245870 è un attacco alla miscelazione delle chiavi (è consentita la ricostruzione dei frammenti crittografati utilizzando diverse chiavi in WPA, WPA2, WPA3 e WEP). L'attacco consente di determinare i dati inviati dal client, ad esempio, identificare il contenuto dei Cookie durante la navigazione HTTP.
- CVE-2020-24586 è un attacco alla cache dei frammenti (gli standard che coprono WPA, WPA2, WPA3 e WEP non richiedono la rimozione dei frammenti già memorizzati nella cache dopo una nuova connessione alla rete). Questo consente di determinare i dati inviati dal client e di sostituire i propri dati.
Per testare il grado di vulnerabilità dei propri dispositivi, è stato preparato un set di strumenti e un'immagine Live pronta per creare un'unità flash USB avviabile. In Linux, i problemi si manifestano nella rete wireless mac80211, in alcuni driver wireless e nei firmware caricati sulle schede wireless. Per risolvere le vulnerabilità è stato proposto un insieme di patch che copre lo stack mac80211 e i driver ath10k/ath11k. Per alcuni dispositivi, come le schede wireless Intel, è necessaria l'installazione di un aggiornamento del firmware.
Test di dispositivi standard:
Test di schede wireless in Linux e Windows:
Test di schede wireless in FreeBSD e NetBSD:
I produttori sono stati informati dei problemi già 9 mesi fa. Questo lungo periodo di embargo è spiegato da una preparazione coordinata degli aggiornamenti e dai ritardi nella preparazione delle modifiche delle specifiche da parte delle organizzazioni ICASI e Wi-Fi Alliance. Inizialmente era previsto rivelare i dati il 9 marzo, ma, valutando i rischi, si è deciso di posticipare la pubblicazione di altri due mesi per dare più tempo alla preparazione delle patch, considerando la complessità delle modifiche apportate e le difficoltà derivanti dalla pandemia di COVID-19.
È interessante notare che, nonostante l'embargo, Microsoft ha risolto anticipatamente alcune vulnerabilità nell'aggiornamento di marzo di Windows. La divulgazione delle informazioni è stata rinviata di una settimana rispetto alla scadenza inizialmente prevista e Microsoft non è riuscita o non ha voluto apportare modifiche all'aggiornamento programmato per la pubblicazione, creando una minaccia per gli utenti di altri sistemi, poiché i malintenzionati avrebbero potuto ottenere informazioni sulle vulnerabilità attraverso l'ingegneria inversa del contenuto degli aggiornamenti.
Fonte: opennet.ru
