În pachetele deschise IWD (Intel inet Wireless Daemon) și wpa_supplicant, folosite pentru conectarea sistemelor Linux client la rețele wireless, au fost identificate vulnerabilități care permit ocolirea mecanismelor de autentificare:
- În IWD, vulnerabilitatea (CVE-2023-52161) se manifestă doar atunci când este activat modul de punct de acces, ceea ce este neobișnuit pentru IWD, care este de obicei utilizat pentru conectarea la rețele wireless. Vulnerabilitatea permite conectarea la punctul de acces creat fără a cunoaște parola, de exemplu, atunci când utilizatorul oferă explicit posibilitatea de a accesa rețeaua prin dispozitivul său (Hotspot). Problema a fost rezolvată în versiunea IWD 2.14.
Vulnerabilitatea este cauzată de absența unei verificări adecvate a ordinii de parcurgere a tuturor pașilor în timpul negocierii pe 4 etape a canalului de comunicație, utilizată la prima conectare la o rețea wireless protejată. Deoarece IWD acceptă mesaje pentru orice etapă a negocierii de conectare, fără a verifica parcurgerea etapei anterioare, un atacator poate sări din trimiterea mesajului etapei a doua și să trimită direct mesajul etapei a patra pentru a obține acces la rețea, ocolind etapa în care se efectuează verificarea autentificării.
În acest context, IWD încearcă să verifice codul MIC (Message Integrity Code) pentru mesajul primit în etapa a patra. Deoarece mesajul etapei a doua cu parametrii de autentificare nu a fost primit, la procesarea mesajului etapei a patra cheia PTK (Pairwise Transient Key) este setată la valoarea zero. Prin urmare, atacatorul poate calcula MIC folosind PTK-ul zero, iar acest cod de verificare va fi acceptat de IWD ca fiind corect. După finalizarea unei astfel de negocieri incomplete de conectare, atacatorul va obține acces complet la rețeaua wireless, deoarece punctul de acces va accepta cadrele trimise de el, criptate cu cheia PTK zero.
- Problema identificată în wpa_supplicant (CVE-2023-52160) permite unui atacator să atragă utilizatorul într-o rețea wireless falsă, care este un clon al rețelei la care utilizatorul intenționează să se conecteze. Dacă utilizatorul se conectează la rețeaua falsă, atacatorul poate organiza interceptarea traficului de tranzit necriptat al utilizatorului (de exemplu, accesând site-uri fără HTTPS).
Din cauza unei deficiențe în implementarea protocolului PEAP (Protected Extensible Authentication Protocol), un atacator poate obține o ocolire a celei de-a doua etape de autentificare atunci când se conectează un dispozitiv al utilizatorului configurat incorect. Ocolirea celei de-a doua etape de autentificare permite atacatorului să creeze un clon de încredere al rețelei Wi-Fi și să asigure conectarea utilizatorului la o rețea falsă fără a verifica parola.
Pentru a efectua cu succes atacul, verificarea serverului în wpa_supplicant trebuie să fie dezactivată pe partea utilizatorului. certificat TLS Atacatorul trebuie să cunoască identificatorul rețelei wireless (SSID, Service Set Identifier). În plus, atacatorul trebuie să fie în raza de acoperire a adaptorului wireless al victimei, dar în afara razei de acoperire a punctului de acces al rețelei wireless clonated. Atacul este posibil în rețelele cu WPA2-Enterprise sau WPA3-Enterprise, în care se aplică protocolul PEAP.
Dezvoltatorii wpa_supplicant au declarat că nu consideră problema o vulnerabilitate, deoarece aceasta apare doar în rețele wireless configurate incorect, în care autentificarea EAP este folosită împreună cu protocolul PEAP (EAP-TTLS) fără a verifica certificatul TLS. serverConfigurările fără verificarea certificatului nu oferă protecție împotriva atacurilor active. Cei care au descoperit vulnerabilitatea susțin că aceste configurări incorecte sunt tipice și răspândite, ceea ce pune în pericol multe dispozitive consumator pe bază de Linux, Android și Chrome OS, care utilizează wpa_supplicant.
Pentru a bloca problema în wpa_supplicant, a fost lansat un patch care adaugă un mod de obligatoriu de a trece prin cea de-a doua fază de autentificare, pe lângă verificarea certificatului TLS. Potrivit dezvoltatorilor, schimbarea propusă este doar o soluție temporară, complicând realizarea atacurilor în cazul utilizării autentificării manuale și fiind inutilă în cazul utilizării unor opțiuni precum EAP-GTC. Pentru a rezolva problema efectiv, administratorii de rețea ar trebui să-și ajusteze configurările corespunzător, adică să configureze lanțul de încredere pentru a verifica certificatul serverului folosind parametrul ca_cert.
Sursa: opennet.ro
