W pakietach open source IWD (Intel inet Wireless Daemon) i wpa_supplicant, służących do organizowania połączeń klientów Linux-систем к беспроводной сети, выявлены уязвимости, приводящие к обходу механизмов аутентификации:
- W IWD luka (CVE-2023-52161) pojawia się tylko wtedy, gdy włączony jest tryb punktu dostępu, co nie jest typowe dla IWD, który zwykle służy do łączenia się z sieciami bezprzewodowymi. Luka umożliwia połączenie się z utworzonym punktem dostępowym bez znajomości hasła, np. gdy użytkownik jawnie udostępni możliwość dostępu do sieci za pośrednictwem swojego urządzenia (Hotspot). Problem został rozwiązany w wersji IWD 2.14.
Luka wynika z nieprawidłowego sprawdzenia kolejności wszystkich kroków podczas 4-etapowej negocjacji kanału komunikacyjnego stosowanej przy pierwszym połączeniu z bezpieczną siecią bezprzewodową. Dzięki temu, że IWD przyjmuje komunikaty dla dowolnych etapów negocjacji połączenia bez sprawdzania, czy poprzedni etap został zakończony, atakujący może ominąć wysłanie komunikatu drugiego etapu i od razu wysłać komunikat czwartego etapu i uzyskać dostęp do sieci , pomijając etap sprawdzania autentyczności.
W tym przypadku IWD próbuje zweryfikować kod MIC (Message Integrity Code) dla odebranej wiadomości czwartego etapu. Ponieważ komunikat drugiego etapu z parametrami uwierzytelnienia nie został odebrany, podczas przetwarzania komunikatu czwartego etapu klucz PTK (Pairwise Transient Key) jest ustawiany na zero. W związku z tym osoba atakująca może obliczyć MIC przy użyciu zerowego PTK, a ten kod weryfikacyjny zostanie zaakceptowany przez IWD jako ważny. Po zakończeniu tej częściowej negocjacji połączenia atakujący będzie miał pełny dostęp do sieci bezprzewodowej, ponieważ punkt dostępowy otrzyma wysyłane ramki, zaszyfrowane zerowym kluczem PTK.
- Problem zidentyfikowany w wpa_supplicant (CVE-2023-52160) umożliwia osobie atakującej zwabienie użytkownika do fikcyjnej sieci bezprzewodowej, która jest klonem sieci, z którą użytkownik zamierza się połączyć. Jeśli użytkownik łączy się z fałszywą siecią, osoba atakująca może zorganizować przechwycenie niezaszyfrowanego ruchu tranzytowego użytkownika (na przykład dostępu do witryn bez protokołu HTTPS).
Ze względu na wadę w implementacji protokołu PEAP (Protected Extensible Authentication Protocol), atakujący może pominąć drugi etap uwierzytelnienia podczas podłączania nieprawidłowo skonfigurowanego urządzenia użytkownika. Pominięcie drugiego etapu uwierzytelniania umożliwia atakującemu utworzenie fałszywego klona zaufanej sieci Wi-Fi i umożliwienie użytkownikowi połączenia się z fałszywą siecią bez sprawdzania hasła.
Aby przeprowadzić skuteczny atak, po stronie użytkownika należy wyłączyć sprawdzanie wpa_supplicant. Certyfikat TLS Atakujący musi znać identyfikator sieci bezprzewodowej (SSID, czyli Service Set Identifier). Atakujący musi znajdować się w zasięgu karty sieciowej ofiary, ale poza zasięgiem punktu dostępowego sklonowanej sieci bezprzewodowej. Atak jest możliwy w sieciach WPA2-Enterprise lub WPA3-Enterprise, które korzystają z protokołu PEAP.
Twórcy narzędzia wpa_supplicant oświadczyli, że nie uważają tego problemu za lukę w zabezpieczeniach, ponieważ pojawia się on wyłącznie w nieprawidłowo skonfigurowanych sieciach bezprzewodowych, w których uwierzytelnianie EAP jest stosowane razem z protokołem PEAP (EAP-TTLS) bez sprawdzania certyfikatu TLS. serwer. Конфигурации без проверки сертификата не имеют защиты от активных атак. Выявившие уязвимость утверждают, что подобные некорректные конфигурации типичны и широко распространены, что ставит под угрозу многие потребительские устройства на базе Linux, Android и Chrome OS, на которых применяется wpa_supplicant.
Aby zablokować problem w wpa_supplicant, wypuszczono łatkę, która oprócz sprawdzania certyfikatu TLS dodaje tryb obowiązkowego przejścia drugiej fazy uwierzytelniania. Zdaniem twórców proponowana zmiana jest jedynie obejściem, które komplikuje ataki przy użyciu ręcznego uwierzytelniania i jest bezużyteczna w przypadku korzystania z opcji takich jak EAP-GTC. Aby rzeczywiście rozwiązać problem, administratorzy sieci powinni doprowadzić swoją konfigurację do właściwej postaci, tj. skonfiguruj łańcuch zaufania w celu weryfikacji certyfikatu serwera za pomocą parametru ca_cert.
Źródło: opennet.ru
