Mathy Vanhoef wspólnie z Héloïse Gollier opublikowali raport z badań przeprowadzonych w ramach grantu od firmy Top10VPN. Wskazali dwie podatności, które narażają poufność danych w sieciach bezprzewodowych. Problem dotyka sieci zabezpieczonych najnowszymi standardami oraz wykorzystujących mechanizmy serwera uwierzytelniającego (WiFi Enterprise). W raporcie przedstawiono szczegółową analizę błędów oraz opisano dwie podatności:

• CVE-2023-52160 (Phase-2 bypass) – dotyczy wpa_supplicant v.2.10 i wcześniejszych,
• CVE-2023-52161 (4-way bypass) – odkryta w IWD v2.12 i wcześniejszych. 

Mathy Vanhoef to osoba znana między innymi z publikacji na temat FragAttacks oraz KRACK. 

CVE-2023-52160

Wpa_supplicant to otwartoźródłowe oprogramowanie, znane przede wszystkim użytkownikom systemów z rodziny Linux (w tym ChromeOS) oraz macOS. Wykorzystywany jest również przez urządzenia z systemem Android oraz w wielofunkcyjnych urządzeniach sieciowych, które oprócz pracy w trybie punktu dostępowego, oferują też działanie jako repeater. Wpa_supplicant odpowiada za obsługę sieci bezprzewodowych, a w szczególności za uwierzytelnianie. 

Sieci WiFi mogą korzystać z wielu mechanizmów bezpieczeństwa. Rozwiązaniem stosowanym w sieciach korporacyjnych czy uczelnianej sieci eduroam jest WPA/WPA2/WPA3-Enterprise. Mechanizm ten pozwala na zwiększenie bezpieczeństwa łączności bezprzewodowej np. poprzez wyeliminowanie współdzielonego między klientami i AP klucza (ang. Pre-Shared Key – PSK) oraz scentralizowanie zarządzania poświadczeniami. Dodatkowo klient może potwierdzić tożsamość serwera uwierzytelniającego przy pomocy certyfikatu. 

Poniższy diagram (rysunek 1) stanowi uproszczoną ilustrację procesu uwierzytelnienia stacji (klienta) w sieci WPA2/WPA3-Enterprise z wykorzystaniem protokołu PEAP (ang. Protected Extensible Authentication Protocol) oraz protokołu uwierzytelniania MS-CHAPv2 (ang. Microsoft Challenge Handshake Authentication Protocol version 2), który wykorzystuje poświadczenia w postaci nazwy użytkownika oraz hasła. Badacze podzielili cały proces na kilka faz. 

W etapie oznaczonym numerem 2 ustanawiany jest szyfrowany tunel przy pomocy TLS pomiędzy punktem dostępowym a klientem. Ma to na celu zabezpieczenie następnych kroków handshake przed podsłuchiwaniem, co jest sposobem na wyeliminowanie znanych podatności w protokołach takich jak MS-CHAPv2. 

W przypadku niezgodności poświadczeń handshake, trzeci etap zakończy się niepowodzeniem i połączenie nie zostanie nawiązane. Jeśli jednak nazwa użytkownika i hasło przedstawione przez klienta zgadzają się z tymi przechowywanymi przez serwer uwierzytelniający, to obydwie strony wymienią wiadomości EAP-TLV Success. Po pozytywnym zakończeniu tego procesu następuje etap negocjacji klucza sesji (ang. Pairwise Transient Key). 

Analiza kodu źródłowego wpa_supplicant wskazała, że druga faza uwierzytelniania (ang. Phase-2) może zostać pominięta (etap 3 na diagramie). W takim wypadku od razu po ustanowieniu tunelu TLS wymieniane są wiadomości TLV-Success. Podatność występuje tylko po stronie klienta, dlatego atak skupia się na wykorzystaniu możliwości przeskoczenia etapu sprawdzenia poświadczeń i skłonienia stacji do podłączenia się do fałszywego punktu dostępowego (ang. Rogue AP). Atakujący może wykorzystać podstawioną sieć WiFi. Klient spróbuje nawiązać połączenie do sieci o nazwie (SSID), z którą był już w przeszłości połączony (np. w pracy, szkole), w wyniku pominięcia etapu uwierzytelniania, zostanie nawiązane połączenie, a użytkownik nie zostanie w żaden sposób powiadomiony o połączeniu się do złośliwego AP. Dzięki temu atakujący może podsłuchiwać ruch sieciowy podłączonej ofiary. 

Żeby atak był możliwy, wymagane jest aby konfiguracja wpa_supplicant nie wymuszała weryfikacji serwera uwierzytelniającego przy pomocy certyfikatu TLS. Jest to domyślne ustawienie w niektórych systemach operacyjnych. Dodatkowo, np. w ChromeOS, poprawne ustawienie takiego zachowania jest nieintuicyjne. Autorzy raportu wskazują, że użytkownikowi proponowane jest ustawienie „Do not check”, co pozostawia urządzenie podatne na atak oraz „Default”, które wymaga dodatkowego parametru określonego jako „Domain suffix match” lub „Subject alternative name match”. Połączenie zostanie nawiązane tylko w przypadku, gdy certyfikat przedstawiony przez serwer zawiera sufix podany przez użytkownika w polach Subject Common Name albo Subject Alternative Name. 

Uproszczony przebieg ataku został przedstawiony na rysunku 3.

Stosowne łatki zostały już opracowane i zostaną wydane w wersji 2.11. Poprawiony został sposób obsługi otrzymywanych pakietów. W momencie odebrania EAP-TLV Success, sprawdzane jest, czy handshake Phase-2 został w ogóle przeprowadzony i zakończył się sukcesem. 

CVE-2023-52161

Druga podatność w opublikowanym raporcie dotyczy iNet Wireless Daemon (IWD). Jest to alternatywa dla wpa_supplicanta zaproponowana przez firmę Intel, mająca na celu uproszczenie i poprawienie obsługi sieci bezprzewodowych w systemie Linux. Oferuje też pracę w dość uproszczonym trybie AP.

Luka została zlokalizowana w funkcji eapol_auth_key_handle, która jest wywoływana każdorazowo gdy otrzymywana jest wiadomość w procesie 4-way handshake. 

W linii 9 następuje sprawdzenie, czy proces 4-way handshake został rozpoczęty. Jednak w następnych liniach (12-16) nie następuje sprawdzenie, która z wiadomości jest wymagana na danym etapie. 

To powoduje, że atakujący może odpowiedzieć wiadomością nr 4, pomijając tym samym prawidłowy przepływ w tym procesie. Brak obsługi tego zdarzenia w kodzie IWD powoduje, że następuje obsługa otrzymanej wiadomości. Co ciekawe, wiadomość nr 4 zawiera MIC (Message Integrity Code), w której kluczem jest PTK. Ponieważ PTK nie zostało po stronie AP wywiedzione, to podatna implementacja użyje domyślnego – „zerowego” klucza (zawierającego same zera). Jeśli atakujący spreparował tę wiadomość, tak aby wykorzystać ten zerowy klucz, to weryfikacja się powiedzie, a klient połączy się do sieci Wi-Fi. Wymieniane z punktem dostępowym ramki będą zaszyfrowane przy użyciu tego samego PTK składającego się z samych zer. 

Podatność ta ma jednak pewne ograniczenia. W wiadomości nr 3 w procesie handshake, AP wysyła zaszyfrowany group key, który jest potrzebny do odszyfrowania pakietów broadcast. W momencie, gdy stacja rozsyła pakiety typu broadcast do wszystkich stacji w sieci, to tak naprawdę wykorzystuje unicast do AP, który następnie rozgłasza ten pakiet do wszystkich urządzeń. To powoduje, że atakujący jest w stanie przesyłać broadcast do sieci (wykorzystując „zerowy” PTK), ale nie może odszyfrować otrzymanego ruchu rozgłoszeniowego. 

Wprowadzona poprawka do wersji 2.14 IWD sprawia, że kolejność wiadomości w procesie handshake jest kontrolowana i nie jest możliwe wykorzystanie powyższego błędu logicznego.

Reasumując, znalezione podatności są całkiem poważne, ale nie ma powodów do nadmiernej paniki. Stosowane powszechnie mechanizmy, takie jak TLS w protokole HTTPS, HSTS czy certificate pinning, powodują, że pomimo otwarcia nowych wektorów ataku, pierwszy błąd dotyczący wpa_supplicanta nie wpłynie na poufność przesyłanych przez użytkownika danych i do poczynienia większej szkody atakujący będzie potrzebował dodatkowych podatności (np. w nasłuchujących usługach na urządzeniu podłączonym do rogue AP). 

~fc