Kwesbaarhede is geïdentifiseer in die oop pakkette IWD (Intel inet Wireless Daemon) en wpa_supplicant, wat gebruik word om die verbinding van Linux-kliënt-stelsels aan 'n draadlose netwerk te organiseer, wat lei tot omseiling van verifikasiemeganismes:
- In IWD verskyn die kwesbaarheid (CVE-2023-52161) slegs wanneer toegangspuntmodus geaktiveer is, wat nie tipies is vir IWD nie, wat gewoonlik gebruik word om aan draadlose netwerke te koppel. Die kwesbaarheid laat jou toe om aan 'n geskepte toegangspunt te koppel sonder om die wagwoord te ken, byvoorbeeld wanneer die gebruiker uitdruklik die vermoë verskaf om toegang tot die netwerk deur hul toestel (Hotspot) te verkry. Die probleem is opgelos in IWD weergawe 2.14.
Die kwesbaarheid word veroorsaak deur die versuim om die volgorde van alle stappe behoorlik na te gaan tydens die 4-stap kommunikasiekanaal onderhandeling wat gebruik word wanneer die eerste keer aan 'n veilige draadlose netwerk gekoppel is. As gevolg van die feit dat IWD boodskappe vir enige stadiums van verbindingsonderhandeling aanvaar sonder om na te gaan of die vorige fase voltooi is, kan 'n aanvaller die stuur van die boodskap van die tweede fase omseil en onmiddellik 'n boodskap van die vierde fase stuur en toegang tot die netwerk verkry , slaan die stadium oor waarop verifikasie nagegaan word.
In hierdie geval probeer IWD om die MIC (Message Integrity Code)-kode vir die ontvangde vierde-fase-boodskap te verifieer. Aangesien die tweede fase boodskap met stawing parameters nie ontvang is nie, wanneer die vierde fase boodskap verwerk word, word die PTK (Pairwise Transient Key) sleutel op nul gestel. Gevolglik kan 'n aanvaller die MIC bereken deur 'n nul-PTK te gebruik, en hierdie verifikasiekode sal deur die IWD as geldig aanvaar word. Nadat hierdie gedeeltelike verbindingsonderhandeling voltooi is, sal die aanvaller volle toegang tot die draadlose netwerk hê, aangesien die toegangspunt die rame sal ontvang wat dit stuur, geïnkripteer met 'n nul PTK-sleutel.
- 'n Probleem wat in wpa_supplicant (CVE-2023-52160) geïdentifiseer is, stel 'n aanvaller in staat om 'n gebruiker na 'n fiktiewe draadlose netwerk te lok wat 'n kloon is van die netwerk waaraan die gebruiker wil koppel. As 'n gebruiker aan 'n vals netwerk koppel, kan die aanvaller die onderskepping van die gebruiker se ongeënkripteerde vervoerverkeer organiseer (byvoorbeeld toegang tot werwe sonder HTTPS).
As gevolg van 'n fout in die implementering van die PEAP (Protected Extensible Authentication Protocol) protokol, kan 'n aanvaller die tweede stadium van stawing oorslaan wanneer 'n verkeerd gekonfigureerde gebruikertoestel gekoppel word. Deur die tweede fase van verifikasie te omseil, kan 'n aanvaller 'n vals kloon van 'n vertroude Wi-Fi-netwerk skep en die gebruiker toelaat om aan die vals netwerk te koppel sonder om die wagwoord na te gaan.
Om 'n aanval in wpa_supplicant suksesvol uit te voer, moet verifikasie van die bediener se TLS-sertifikaat aan die gebruiker se kant gedeaktiveer word, en die aanvaller moet die draadlose netwerkidentifiseerder (SSID, Service Set Identifier) ken. In hierdie geval moet die aanvaller binne die bereik van die slagoffer se draadlose adapter wees, maar buite bereik van die toegangspunt van die gekloonde draadlose netwerk. Die aanval is moontlik op netwerke met WPA2-Enterprise of WPA3-Enterprise wat die PEAP-protokol gebruik.
Die wpa_supplicant-ontwikkelaars het gesê dat hulle nie die probleem as 'n kwesbaarheid beskou nie, aangesien dit slegs voorkom op swak gekonfigureerde draadlose netwerke wat EAP-verifikasie in samewerking met PEAP (EAP-TTLS) gebruik sonder om die bediener se TLS-sertifikaat te verifieer. Konfigurasies sonder sertifikaatverifikasie word nie teen aktiewe aanvalle beskerm nie. Diegene wat die kwesbaarheid ontdek het, beweer dat sulke verkeerde konfigurasies algemeen en wydverspreid is, wat baie Linux-, Android- en Chrome-bedryfstelselgebaseerde verbruikerstoestelle wat wpa_supplicant gebruik, in gevaar stel.
Om die probleem in wpa_supplicant te blokkeer, is 'n pleister vrygestel wat 'n modus vir verpligte deurgang van die tweede fase van verifikasie byvoeg, benewens die nagaan van die TLS-sertifikaat. Volgens die ontwikkelaars is die voorgestelde verandering slegs 'n oplossing wat aanvalle bemoeilik wanneer manuele verifikasie gebruik word en nutteloos is wanneer opsies soos EAP-GTC gebruik word. Om die probleem werklik op te los, moet netwerkadministrateurs hul konfigurasie in die regte vorm bring, d.w.s. stel 'n vertrouesketting op om die bedienersertifikaat te verifieer deur die ca_cert-parameter te gebruik.
Bron: opennet.ru