W otwartych pakietach IWD (Intel inet Wireless Daemon) oraz wpa_supplicant, u\u017cywanych do \u0142\u0105czenia system\u00f3w Linux z sieci\u0105 bezprzewodow\u0105, zidentyfikowano luki, kt\u00f3re umo\u017cliwiaj\u0105 obej\u015bcie mechanizm\u00f3w autoryzacji: <\/p>\n
Luka jest spowodowana brakiem odpowiedniej weryfikacji kolejno\u015bci wykonania wszystkich krok\u00f3w w 4-etapowym negocjowaniu po\u0142\u0105czenia, stosowanym przy pierwszym \u0142\u0105czeniu si\u0119 z chronion\u0105 sieci\u0105 bezprzewodow\u0105. Poniewa\u017c IWD akceptuje wiadomo\u015bci ze wszystkich etap\u00f3w negocjacji po\u0142\u0105czenia, nie weryfikuj\u0105c, czy wcze\u015bniejszy etap zosta\u0142 zako\u0144czony, atakuj\u0105cy mo\u017ce pomin\u0105\u0107 wys\u0142anie wiadomo\u015bci drugiego etapu i od razu wys\u0142a\u0107 wiadomo\u015b\u0107 czwartego etapu, uzyskuj\u0105c dost\u0119p do sieci, pomijaj\u0105c etap, na kt\u00f3rym przeprowadzana jest kontrola autoryzacji. <\/p>\n
W tym czasie IWD pr\u00f3buje zweryfikowa\u0107 kod MIC (Message Integrity Code) dla otrzymanej wiadomo\u015bci czwartego etapu. Poniewa\u017c wiadomo\u015b\u0107 drugiego etapu z parametrami autoryzacji nie zosta\u0142a odebrana, podczas przetwarzania wiadomo\u015bci czwartego etapu klucz PTK (Pairwise Transient Key) jest ustawiany na warto\u015b\u0107 zerow\u0105. W zwi\u0105zku z tym atakuj\u0105cy mo\u017ce obliczy\u0107 MIC, u\u017cywaj\u0105c zerowego PTK, a ten kod kontrolny zostanie zaakceptowany przez IWD jako poprawny. Po zako\u0144czeniu takiego niepe\u0142nego negocjowania po\u0142\u0105czenia atakuj\u0105cy uzyska pe\u0142ny dost\u0119p do sieci bezprzewodowej, poniewa\u017c punkt dost\u0119pu b\u0119dzie akceptowa\u0142 wysy\u0142ane przez niego ramki szyfrowane zerowym kluczem PTK. <\/p>\n
Z powodu niedoci\u0105gni\u0119cia w implementacji protoko\u0142u PEAP (Protected Extensible Authentication Protocol) napastnik mo\u017ce uczyni\u0107 tak, \u017ce druga faza uwierzytelniania zostanie pomini\u0119ta podczas \u0142\u0105czenia si\u0119 u\u017cytkownika z niew\u0142a\u015bciwie skonfigurowanym urz\u0105dzeniem. Pomini\u0119cie drugiej fazy uwierzytelniania pozwala napastnikowi stworzy\u0107 podszywaj\u0105cego si\u0119 klona zaufanej sieci Wi-Fi i zapewni\u0107 u\u017cytkownikowi \u0142\u0105czenie z fa\u0142szyw\u0105 sieci\u0105 bez sprawdzania has\u0142a. <\/p>\n
Aby atak w wpa_supplicant by\u0142 udany, na stronie u\u017cytkownika musi by\u0107 wy\u0142\u0105czone sprawdzanie certyfikatu TLS<\/a> serwera, a napastnik musi zna\u0107 identyfikator sieci bezprzewodowej (SSID, Service Set Identifier). W tym przypadku napastnik musi znajdowa\u0107 si\u0119 w zasi\u0119gu bezprzewodowego adaptera ofiary, ale poza zasi\u0119giem punktu dost\u0119powego klonowanej sieci bezprzewodowej. Atak jest mo\u017cliwy na sieciach z WPA2-Enterprise lub WPA3-Enterprise, w kt\u00f3rych stosowany jest protok\u00f3\u0142 PEAP. <\/p>\n Deweloperzy wpa_supplicant stwierdzili, \u017ce nie uwa\u017caj\u0105 tego problemu za luk\u0119 w zabezpieczeniach, poniewa\u017c wyst\u0119puje on tylko w niew\u0142a\u015bciwie skonfigurowanych sieciach bezprzewodowych, w kt\u00f3rych uwierzytelnianie EAP jest u\u017cywane razem z protoko\u0142em PEAP (EAP-TTLS) bez sprawdzania certyfikatu TLS. serwera<\/a>Konfiguracje bez sprawdzania certyfikatu nie maj\u0105 ochrony przed aktywnymi atakami. Osoby, kt\u00f3re wykry\u0142y luk\u0119, twierdz\u0105, \u017ce podobne niew\u0142a\u015bciwe konfiguracje s\u0105 typowe i szeroko rozpowszechnione, co stawia w niebezpiecze\u0144stwo wiele urz\u0105dze\u0144 konsumenckich dzia\u0142aj\u0105cych na systemach Linux, Android i Chrome OS, na kt\u00f3rych u\u017cywany jest wpa_supplicant. <\/p>\n Aby zablokowa\u0107 problem w wpa_supplicant, wydano \u0142atk\u0119, kt\u00f3ra dodaje tryb obowi\u0105zkowego przechodzenia drugiej fazy uwierzytelniania, opr\u00f3cz sprawdzania certyfikatu TLS. Wed\u0142ug deweloper\u00f3w proponowana zmiana to jedynie spos\u00f3b obej\u015bcia, kt\u00f3ry komplikuje przeprowadzenie atak\u00f3w przy u\u017cyciu r\u0119cznego uwierzytelniania i jest bezu\u017cyteczny przy u\u017cyciu takich opcji jak EAP-GTC. Aby naprawd\u0119 rozwi\u0105za\u0107 problem, administratorzy sieci powinni dostosowa\u0107 swoje konfiguracje, tj. skonfigurowa\u0107 \u0142a\u0144cuch zaufania do sprawdzania certyfikatu serwera za pomoc\u0105 parametru ca_cert. <\/ul>\n