Sono state trovate vulnerabilità nei pacchetti aperti di IWD (Intel inet Wireless Daemon) e wpa_supplicant, utilizzati per connettere i sistemi Linux client a reti wireless, che portano al bypass dei meccanismi di autenticazione:
- In IWD, la vulnerabilità (CVE-2023-52161) si manifesta solo quando è attivata la modalità access point, cosa non tipica per IWD, che di solito è utilizzato per connettersi a reti wireless. La vulnerabilità consente di connettersi a un access point creato senza conoscere la password, ad esempio, quando l'utente esplicitamente permette l'accesso alla rete tramite il proprio dispositivo (Hotspot). Il problema è stato risolto nella versione IWD 2.14.
La vulnerabilità è causata dall'assenza di una corretta verifica dell'ordine di esecuzione di tutti i passaggi durante il protocollo di handshake a 4 fasi, utilizzato alla prima connessione a una rete wireless protetta. Poiché IWD accetta messaggi per qualsiasi fase del processo di connessione, senza verificare il completamento della fase precedente, un attaccante può saltare l'invio del messaggio della seconda fase e inviare immediatamente il messaggio della quarta fase, ottenendo accesso alla rete, bypassando la fase in cui avviene la verifica dell'autenticazione.
In tal modo, IWD cerca di verificare il codice MIC (Message Integrity Code) per il messaggio della quarta fase ricevuto. Poiché il messaggio della seconda fase contenente 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 un PTK nullo, e questo codice di controllo verrà accettato da IWD come valido. Dopo il completamento di tale handshake incompleto, l'attaccante avrà accesso completo alla rete wireless, poiché l'access point accetterà i frame inviati da lui, crittografati con la chiave PTK nulla.
- Il problema identificato in wpa_supplicant (CVE-2023-52160) consente a un aggressore di ingannare un utente per connettersi a una rete wireless fasulla, che è un clone della rete a cui l'utente intende collegarsi. Se l'utente si connette alla rete fasulla, l'attaccante può intercettare il traffico transitato non crittografato dell'utente (ad esempio, visitando siti senza HTTPS).
A causa di una carenza nell'implementazione del protocollo PEAP (Protected Extensible Authentication Protocol), l'attaccante può ottenere il bypass della seconda fase dell'autenticazione quando si connette a un dispositivo dell'utente mal configurato. Il bypass della seconda fase dell'autenticazione consente all'attaccante di creare un clone fasullo di una rete Wi-Fi affidabile e garantire che l'utente si connetta alla rete fasulla senza controllare la password.
Per condurre con successo l'attacco in wpa_supplicant, la verifica del server deve essere disattivata sul lato dell'utente certificato TLS e l'attaccante deve conoscere l'identificatore della rete wireless (SSID, Service Set Identifier). L'attaccante deve trovarsi entro il raggio d'azione dell'adattatore wireless della vittima, ma al di fuori del raggio d'azione dell'access point della rete clone. L'attacco è possibile su reti con WPA2-Enterprise o WPA3-Enterprise, in cui viene utilizzato il protocollo PEAP.
Gli sviluppatori di wpa_supplicant affermano che non considerano il problema una vulnerabilità, poiché si manifesta solo su reti wireless mal configurate, dove l'autenticazione EAP è utilizzata insieme al protocollo PEAP (EAP-TTLS) senza verifica del certificato TLS. serverLe configurazioni senza verifica del certificato non offrono protezione contro attacchi attivi. Gli scopritori della vulnerabilità sostengono che tali configurazioni scorrette sono tipiche e diffuse, mettendo a rischio molti dispositivi consumer basati su Linux, Android e Chrome OS, che utilizzano wpa_supplicant.
Per bloccare il problema, è stato rilasciato un patch per wpa_supplicant che aggiunge la modalità di obbligo per il superamento della seconda fase dell'autenticazione, oltre alla verifica del certificato TLS. Secondo gli sviluppatori, la modifica proposta è solo una soluzione temporanea, che rende più difficile eseguire attacchi con l'autenticazione manuale ed è inutile quando si utilizzano opzioni come EAP-GTC. Per risolvere effettivamente il problema, gli amministratori di rete devono sistemare le loro configurazioni, quindi impostare una catena di fiducia per la verifica del certificato del server tramite il parametro ca_cert.
Fonte: opennet.ru
