Mathy Vanhoef, l'autore dell'attacco KRACK alle reti wireless, ha divulgato informazioni su 12 vulnerabilità che colpiscono vari dispositivi wireless. I problemi identificati vengono presentati sotto il nome in codice FragAttacks e riguardano quasi tutte le schede wireless e i punti di accesso in uso: dei 75 dispositivi testati ciascuno era suscettibile ad almeno uno dei metodi di attacco proposti.
I problemi si dividono in due categorie: 3 vulnerabilità sono state individuate direttamente negli standard Wi-Fi e riguardano tutti i dispositivi che supportano gli attuali standard IEEE 802.11 (i problemi sono rintracciati dal 1997). 9 vulnerabilità riguardano errori e difetti in implementazioni specifiche di stack wireless. Il pericolo principale è rappresentato dalla seconda categoria, poiché organizzare attacchi contro carenze normative richiede la presenza di contesti specifici o il compimento di determinate azioni da parte della vittima. Tutte le vulnerabilità si verificano indipendentemente dai protocolli utilizzati per garantire la sicurezza Wi-Fi, anche quando si utilizza WPA3.
La maggior parte dei metodi di attacco identificati consentono all’aggressore di sostituire i frame L2 in una rete protetta, consentendo così di incunearsi nel traffico della vittima. Lo scenario di attacco più realistico è lo spoofing delle risposte DNS per indirizzare l'utente all'host dell'aggressore. Viene anche fornito un esempio dell'utilizzo delle vulnerabilità per aggirare il traduttore di indirizzi su un router wireless e organizzare l'accesso diretto a un dispositivo su una rete locale o ignorare le restrizioni del firewall. La seconda parte delle vulnerabilità, associata all'elaborazione di frame frammentati, consente di estrarre dati sul traffico su una rete wireless e di intercettare i dati dell'utente trasmessi senza crittografia.
Il ricercatore ha preparato una dimostrazione che mostra come sfruttare le vulnerabilità per intercettare una password trasmessa quando si accede a un sito tramite HTTP senza crittografia e come attaccare una presa intelligente controllata tramite Wi-Fi e usarla come trampolino di lancio per continuare l'attacco su dispositivi non aggiornati in una rete locale che presentano vulnerabilità non corrette (ad esempio, è stato possibile attaccare un computer non aggiornato con Windows 7 nella rete interna tramite NAT traversal).
Per sfruttare le vulnerabilità, l'aggressore deve trovarsi nel raggio d'azione del dispositivo wireless bersaglio per inviare alla vittima una serie di frame appositamente predisposti. I problemi riguardano sia i dispositivi client che le schede wireless, nonché gli access point e i router Wi-Fi. In generale, l'utilizzo di HTTPS in combinazione con la crittografia del traffico DNS utilizzando DNS su TLS o DNS su HTTPS è sufficiente come soluzione alternativa. Anche l’uso di una VPN è adatto per la protezione.
Le più pericolose sono quattro vulnerabilità nell'implementazione dei dispositivi wireless, che consentono metodi banali per ottenere la sostituzione dei frame non crittografati:
- Le vulnerabilità CVE-2020-26140 e CVE-2020-26143 consentono il frame stuffing su alcuni punti di accesso e schede wireless su Linux, Windows e FreeBSD.
- La vulnerabilità VE-2020-26145 consente di elaborare frammenti trasmessi non crittografati come fotogrammi completi su macOS, iOS e FreeBSD e NetBSD.
- La vulnerabilità CVE-2020-26144 consente l'elaborazione di frame A-MSDU riassemblati non crittografati con EtherType EAPOL in Huawei Y6, Nexus 5X, FreeBSD e LANCOM AP.
Altre vulnerabilità nelle implementazioni sono principalmente legate ai problemi riscontrati durante l'elaborazione di frame frammentati:
- CVE-2020-26139: consente il reindirizzamento dei frame con il flag EAPOL inviati da un mittente non autenticato (interessa 2/4 punti di accesso attendibili, nonché le soluzioni basate su NetBSD e FreeBSD).
- CVE-2020-26146: consente il riassemblaggio di frammenti crittografati senza controllare l'ordine del numero di sequenza.
- CVE-2020-26147: consente il riassemblaggio di frammenti misti crittografati e non crittografati.
- CVE-2020-26142: consente di trattare i frame frammentati come frame completi (influenza OpenBSD e il modulo wireless ESP12-F).
- CVE-2020-26141: controllo TKIP MIC mancante per i frame frammentati.
Problemi di specifica:
- CVE-2020-24588 - attacco ai frame aggregati (il flag "è aggregato" non è protetto e può essere sostituito da un utente malintenzionato nei frame A-MSDU in WPA, WPA2, WPA3 e WEP). Un esempio di attacco utilizzato è il reindirizzamento di un utente a un server DNS dannoso o a un NAT trasversale.
- CVE-2020-245870 è un attacco di key mixing (che consente di riassemblare frammenti crittografati utilizzando chiavi diverse in WPA, WPA2, WPA3 e WEP). L'attacco consente di determinare i dati inviati dal client, ad esempio, determinare il contenuto del cookie durante l'accesso tramite HTTP.
- CVE-2020-24586 è un attacco alla cache dei frammenti (gli standard WPA, WPA2, WPA3 e WEP non richiedono la rimozione dei frammenti già depositati nella cache dopo una nuova connessione alla rete). Ti consente di determinare i dati inviati dal cliente e sostituire i tuoi dati.
Per testare il grado di suscettibilità dei tuoi dispositivi ai problemi, sono stati preparati uno speciale toolkit e un'immagine Live già pronta per la creazione di un'unità USB avviabile. Su Linux, si verificano problemi nella mesh wireless mac80211, nei singoli driver wireless e nel firmware caricato sulle schede wireless. Per eliminare le vulnerabilità è stato proposto un set di patch che copre lo stack mac80211 e i driver ath10k/ath11k. Alcuni dispositivi, come le schede wireless Intel, richiedono un aggiornamento firmware aggiuntivo.
Test di dispositivi tipici:
Test delle schede wireless in Linux e Windows:
Test delle schede wireless in FreeBSD e NetBSD:
I produttori sono stati informati dei problemi 9 mesi fa. Un periodo di embargo così lungo si spiega con la preparazione coordinata degli aggiornamenti e con i ritardi nella preparazione delle modifiche alle specifiche da parte delle organizzazioni ICASI e Wi-Fi Alliance. Inizialmente si prevedeva di divulgare le informazioni il 9 marzo, ma, dopo aver confrontato i rischi, si è deciso di posticipare la pubblicazione di altri due mesi per dare più tempo alla preparazione delle patch, tenendo conto della natura non banale delle modifiche. in corso e le difficoltà derivanti dalla pandemia di COVID-19.
È interessante notare che, nonostante l'embargo, Microsoft ha risolto prima del previsto alcune vulnerabilità con l'aggiornamento Windows di marzo. La divulgazione delle informazioni è stata posticipata una settimana prima della data originariamente prevista e Microsoft non ha avuto il tempo o non ha voluto apportare modifiche all'aggiornamento pianificato pronto per la pubblicazione, il che ha creato una minaccia per gli utenti di altri sistemi, poiché gli aggressori potrebbero ottenere informazioni su vulnerabilità attraverso il reverse engineering del contenuto degli aggiornamenti.
Fonte: opennet.ru