I åbne pakkefiler til IWD (Intel inet Wireless Daemon) og wpa_supplicant, der bruges til at forbinde klient Linux-systemer til et trådløst netværk, er der opdaget sårbarheder, der kan omgå autentificeringsmekanismerne:
- I IWD manifesterer sårbarheden (CVE-2023-52161) sig kun, når der arbejdes i adgangspunktmode, hvilket ikke er typisk for IWD, da det normalt bruges til at forbinde til trådløse netværk. Sårbarheden gør det muligt at oprette forbindelse til et oprettet adgangspunkt uden at kende adgangskoden, for eksempel når en bruger aktivt giver mulighed for at få forbindelse til nettet gennem deres enhed (Hotspot). Problemet er løst i version IWD 2.14.
Sårbarheden skyldes manglende korrekt kontrol af rækkefølgen af alle trin under den 4-trins kommunikationsaftale, der anvendes ved den første forbindelse til et beskyttet trådløst netværk. Fordi IWD accepterer beskeder for alle trin i forbindelse, uden at kontrollere, om det foregående trin er bestået, kan en angriber springe det andet trins besked over og straks sende fjerde trins besked for at få adgang til netværket, mens det trin, der omfatter autentificeringskontrollen, ellers overses.
Samtidig forsøger IWD at verificere MIC-koden (Message Integrity Code) for den modtagne besked fra fjerde trin. Da beskeden fra andet trin med autentificeringsparametrene ikke er modtaget, bliver PTK-nøglen (Pairwise Transient Key) sat til nul under behandlingen af beskeden fra fjerde trin. Følgelig kan angriberen beregne MIC ved at bruge den nulstillede PTK, og denne verificeringskode vil blive accepteret af IWD som korrekt. Efter afslutningen af en sådan ufuldstændig forbindelsesforhandling vil angriberen få fuld adgang til det trådløse netværk, da adgangspunktet vil acceptere de rammer, der sendes af ham, og som er krypteret med den nulstillede PTK-nøgle.
- Den opdagede sårbarhed i wpa_supplicant (CVE-2023-52160) giver en angriber mulighed for at lokke brugeren ind i et falsk trådløst netværk, der fungerer som en klon af det netværk, som brugeren ønsker at oprette forbindelse til. Hvis brugeren opretter forbindelse til det falske netværk, kan angriberen organisere opsnapning af uforkodet transit trafik fra brugeren (for eksempel anmodninger til websteder uden HTTPS).
På grund af en fejl i implementeringen af PEAP (Protected Extensible Authentication Protocol) kan en angriber omgå den anden fase af autentificeringen, når de forbinder et forkert konfigureret brugerudstyr. At omgå den anden fase af autentificering gør det muligt for angriberen at oprette en falsk klon af et pålideligt Wi-Fi-netværk og sørge for, at brugeren forbindes til det falske netværk uden at tjekke adgangskoden.
For at udføre et angreb skal kontrollering i wpa_supplicant på brugerens side være deaktiveret. TLS certificate Angriberen skal kende det trådløse netværks id (SSID, Service Set Identifier). Desuden skal angriberen være inden for rækkevidden af offerets trådløse adapter, men uden for rækkevidden af adgangspunktsklonen. Angrebet er muligt på netværk med WPA2-Enterprise eller WPA3-Enterprise, hvor PEAP-protokollen anvendes.
Udviklerne af wpa_supplicant har udtalt, at de ikke betragter problemet som en sårbarhed, da det kun opstår i forkert konfigurerede trådløse netværk, hvor EAP-autentificering anvendes sammen med PEAP-protokollen (EAP-TTLS) uden TLS-certifikatkontrol. serverKonfigurationer uden certifikatkontrol er ikke beskyttet mod aktive angreb. Dem, der har opdaget sårbarheden, hævder, at sådanne forkert konfigurerede indstillinger er typiske og almindeligt forekommende, hvilket truer mange forbrugerenheder baseret på Linux, Android og Chrome OS, som anvender wpa_supplicant.
For at blokere problemet i wpa_supplicant er der udgivet en patch, der tilføjer et tvingende krav om, at den anden fase af autentificeringen skal gennemføres, ud over kontrol af TLS-certifikat. Ifølge udviklerne er den foreslåede ændring kun en omgåelse, der komplicerer angreb, når der anvendes manuel autentificering og er ubrugelig ved anvendelse af sådanne muligheder som EAP-GTC. For at løse problemet ordentligt bør netværksadministratorer tilpasse deres konfigurationer, dvs. opsætte en tillidskæde for kontrol af serverens certifikat ved hjælp af parameteren ca_cert.
Kilde: opennet.ru
