Sono state trovate vulnerabilità nei pacchetti aperti di IWD (Intel inet Wireless Daemon) e wpa_supplicant, utilizzati per connettere i sistemi Linux client a una rete wireless, che portano all'aggiramento dei meccanismi di autenticazione:
- In IWD, la vulnerabilità (CVE-2023-52161) si manifesta solo quando il funzionamento è attivato nella modalità hotspot, che è atipica per IWD, normalmente utilizzato per la connessione a reti wireless. La vulnerabilità consente la connessione a un hotspot creato senza conoscenza della password, ad esempio quando un utente esplicitamente consente l'accesso tramite il proprio dispositivo (Hotspot). Il problema è stato risolto nella versione IWD 2.14.
La vulnerabilità è causata dalla mancanza di un'adeguata verifica dell'ordine di tutti i passaggi durante il protocollo di 4 fasi per la negoziazione del canale di comunicazione, utilizzato durante la prima connessione a una rete wireless protetta. Poiché IWD accetta messaggi per qualsiasi fase della negoziazione della connessione, senza controllare se il passaggio precedente è stato completato, un attaccante può saltare l'invio del messaggio della seconda fase e inviare direttamente il messaggio della quarta fase, ottenendo accesso alla rete, saltando il passaggio in cui si esegue la verifica dell'autenticazione.
In questo caso, IWD cerca di verificare il codice MIC (Message Integrity Code) per il messaggio della quarta fase ricevuto. Poiché il messaggio della seconda fase con i parametri di autenticazione non è stato ricevuto, durante l'elaborazione del messaggio della quarta fase la chiave PTK (Pairwise Transient Key) viene impostata su un valore nullo. Di conseguenza, l'attaccante può calcolare il MIC utilizzando una PTK nulla, e questo codice di verifica sarà accettato da IWD come valido. Dopo il completamento di tale negoziazione incompleta della connessione, l'attaccante otterrà accesso completo alla rete wireless, poiché l'hotspot accetterà i pacchetti inviati da lui, cifrati con una chiave PTK nulla.
- Il problema riscontrato in wpa_supplicant (CVE-2023-52160) consente a un malintenzionato di attirare un utente in una rete wireless falsa, che funge da clone della rete a cui l'utente intende connettersi. Se l'utente si connette alla rete fraudolenta, l'attaccante può intercettare il traffico non crittografato dell'utente (ad esempio, richieste a siti senza HTTPS).
A causa di un difetto nell'implementazione del protocollo PEAP (Protected Extensible Authentication Protocol), un attaccante può bypassare la seconda fase di autenticazione quando si connette a un dispositivo utente configurato in modo errato. Il bypass della seconda fase di autenticazione consente all'attaccante di creare un clone fasullo di una rete Wi-Fi fidata e di connettere l'utente a una rete fittizia senza la verifica della password.
Per condurre con successo l'attacco, in wpa_supplicant deve essere disabilitato il controllo del certificato TLS server, e l'attaccante deve conoscere l'identificatore della rete wireless (SSID, Service Set Identifier). Inoltre, l'attaccante deve trovarsi all'interno della portata dell'adattatore wireless della vittima, ma al di fuori della portata del punto di accesso della rete wireless clonata. L'attacco è possibile su reti con WPA2-Enterprise o WPA3-Enterprise, in cui viene utilizzato il protocollo PEAP.
Gli sviluppatori di wpa_supplicant hanno dichiarato di non considerare il problema una vulnerabilità, poiché si manifesta solo in reti wireless configurate in modo errato, in cui l'autenticazione EAP è utilizzata insieme al protocollo PEAP (EAP-TTLS) senza la verifica del certificato TLS. serverLe configurazioni senza verifica del certificato non offrono protezione contro attacchi attivi. Coloro che hanno identificato la vulnerabilità sostengono che tali configurazioni errate sono tipiche e ampiamente diffuse, il che mette a rischio molti dispositivi consumer basati su Linux, Android e Chrome OS, sui quali viene utilizzato wpa_supplicant.
Per affrontare il problema in wpa_supplicant è stato rilasciato un patch che aggiunge una modalità di obbligatoria esecuzione della seconda fase di autenticazione, oltre alla verifica del certificato TLS. Secondo gli sviluppatori, la modifica proposta è solo una misura arbitraria, che complica la realizzazione degli attacchi in caso di utilizzo di autenticazione manuale e risulta inutile quando si utilizzano opzioni come EAP-GTC. Per risolvere realmente il problema, gli amministratori di rete devono portare le loro configurazioni in uno stato adeguato, ossia impostare una catena di fiducia per la verifica del certificato del server mediante il parametro ca_cert.
Fonte: opennet.ru
