W otwartych pakietach IWD (Intel inet Wireless Daemon) oraz wpa_supplicant, używanych do łączenia systemów Linux z siecią bezprzewodową, zidentyfikowano luki, które umożliwiają obejście mechanizmów autoryzacji:
- W IWD luka (CVE-2023-52161) występuje tylko w trybie działania jako hotspot, co jest nietypowe dla IWD, który zazwyczaj służy do łączenia z sieciami bezprzewodowymi. Luka ta pozwala na połączenie z utworzonym punktem dostępu bez znajomości hasła, na przykład, gdy użytkownik świadomie umożliwia dostęp do sieci za pośrednictwem swojego urządzenia (Hotspot). Problem został naprawiony w wersji IWD 2.14.
Luka jest spowodowana brakiem odpowiedniej weryfikacji kolejności wykonania wszystkich kroków w 4-etapowym negocjowaniu połączenia, stosowanym przy pierwszym łączeniu się z chronioną siecią bezprzewodową. Ponieważ IWD akceptuje wiadomości ze wszystkich etapów negocjacji połączenia, nie weryfikując, czy wcześniejszy etap został zakończony, atakujący może pominąć wysłanie wiadomości drugiego etapu i od razu wysłać wiadomość czwartego etapu, uzyskując dostęp do sieci, pomijając etap, na którym przeprowadzana jest kontrola autoryzacji.
W tym czasie IWD próbuje zweryfikować kod MIC (Message Integrity Code) dla otrzymanej wiadomości czwartego etapu. Ponieważ wiadomość drugiego etapu z parametrami autoryzacji nie została odebrana, podczas przetwarzania wiadomości czwartego etapu klucz PTK (Pairwise Transient Key) jest ustawiany na wartość zerową. W związku z tym atakujący może obliczyć MIC, używając zerowego PTK, a ten kod kontrolny zostanie zaakceptowany przez IWD jako poprawny. Po zakończeniu takiego niepełnego negocjowania połączenia atakujący uzyska pełny dostęp do sieci bezprzewodowej, ponieważ punkt dostępu będzie akceptował wysyłane przez niego ramki szyfrowane zerowym kluczem PTK.
- Zidentyfikowany w wpa_supplicant problem (CVE-2023-52160) pozwala atakującemu na zwabienie użytkownika do fałszywej sieci bezprzewodowej, będącej klonem sieci, do której użytkownik zamierza się połączyć. W przypadku połączenia użytkownika z podszywającą się siecią atakujący może przechwytywać nieszyfrowany ruch użytkownika (na przykład, prośby o strony internetowe bez HTTPS).
Z powodu niedociągnięcia w implementacji protokołu PEAP (Protected Extensible Authentication Protocol) napastnik może uczynić tak, że druga faza uwierzytelniania zostanie pominięta podczas łączenia się użytkownika z niewłaściwie skonfigurowanym urządzeniem. Pominięcie drugiej fazy uwierzytelniania pozwala napastnikowi stworzyć podszywającego się klona zaufanej sieci Wi-Fi i zapewnić użytkownikowi łączenie z fałszywą siecią bez sprawdzania hasła.
Aby atak w wpa_supplicant był udany, na stronie użytkownika musi być wyłączone sprawdzanie certyfikatu TLS serwera, a napastnik musi znać identyfikator sieci bezprzewodowej (SSID, Service Set Identifier). W tym przypadku napastnik musi znajdować się w zasięgu bezprzewodowego adaptera ofiary, ale poza zasięgiem punktu dostępowego klonowanej sieci bezprzewodowej. Atak jest możliwy na sieciach z WPA2-Enterprise lub WPA3-Enterprise, w których stosowany jest protokół PEAP.
Deweloperzy wpa_supplicant stwierdzili, że nie uważają tego problemu za lukę w zabezpieczeniach, ponieważ występuje on tylko w niewłaściwie skonfigurowanych sieciach bezprzewodowych, w których uwierzytelnianie EAP jest używane razem z protokołem PEAP (EAP-TTLS) bez sprawdzania certyfikatu TLS. serweraKonfiguracje bez sprawdzania certyfikatu nie mają ochrony przed aktywnymi atakami. Osoby, które wykryły lukę, twierdzą, że podobne niewłaściwe konfiguracje są typowe i szeroko rozpowszechnione, co stawia w niebezpieczeństwo wiele urządzeń konsumenckich działających na systemach Linux, Android i Chrome OS, na których używany jest wpa_supplicant.
Aby zablokować problem w wpa_supplicant, wydano łatkę, która dodaje tryb obowiązkowego przechodzenia drugiej fazy uwierzytelniania, oprócz sprawdzania certyfikatu TLS. Według deweloperów proponowana zmiana to jedynie sposób obejścia, który komplikuje przeprowadzenie ataków przy użyciu ręcznego uwierzytelniania i jest bezużyteczny przy użyciu takich opcji jak EAP-GTC. Aby naprawdę rozwiązać problem, administratorzy sieci powinni dostosować swoje konfiguracje, tj. skonfigurować łańcuch zaufania do sprawdzania certyfikatu serwera za pomocą parametru ca_cert.
Źródło: opennet.ru
