Mathy Vanhoef, autorka ataku KRACK na sieci bezprzewodowe, ujawniła szczegóły 12 luk w zabezpieczeniach różnych urządzeń bezprzewodowych. Zidentyfikowane problemy noszą nazwę kodową FragAttacks i dotyczą prawie wszystkich używanych kart bezprzewodowych oraz punktów dostępowych – spośród 75 przetestowanych urządzeń każde zostało poddane co najmniej jednej z proponowanych metod ataku.
Problemy dzielą się na dwie kategorie: 3 luki są identyfikowane bezpośrednio w standardach Wi-Fi i obejmują wszystkie urządzenia obsługujące aktualne standardy IEEE 802.11 (problemy są śledzone od 1997 roku). 9 luk dotyczy błędów i wad w konkretnych implementacjach stosu bezprzewodowego. Główne niebezpieczeństwo należy do drugiej kategorii, ponieważ organizacja ataków na wady standardów wymaga określonych ustawień lub wykonania przez ofiarę określonych działań. Wszystkie luki występują niezależnie od stosowania protokołów bezpieczeństwa Wi-Fi, w tym podczas korzystania z WPA3.
Większość zidentyfikowanych metod ataku pozwala atakującemu na wykonanie podstawienia ramki L2 w bezpiecznej sieci, co umożliwia włamanie się do ruchu ofiary. Jako najbardziej realistyczny scenariusz ataku wymienia się fałszowanie odpowiedzi DNS w celu skierowania użytkownika do hosta atakującego. Podaje także przykład wykorzystania luk w celu ominięcia tłumacza adresów w routerze bezprzewodowym i zapewnienia bezpośredniego dostępu do urządzenia w sieci lokalnej lub zignorowania ograniczeń zapory ogniowej. Druga część luki, związana z przetwarzaniem pofragmentowanych ramek, umożliwia wyodrębnianie danych o ruchu w sieci bezprzewodowej i przechwytywanie danych użytkownika przesyłanych bez użycia szyfrowania.
Badacz przygotował demonstrację pokazującą, jak można wykorzystać luki w zabezpieczeniach do przechwytywania hasła przesyłanego podczas uzyskiwania dostępu do witryny za pośrednictwem protokołu HTTP bez szyfrowania. Pokazuje także, jak zaatakować inteligentną wtyczkę sterowaną przez Wi-Fi i wykorzystać ją jako odskocznię do kontynuowania ataków na urządzenia inne niż zaktualizowane urządzenia w sieci lokalnej z niezałatanymi lukami (na przykład możliwe było zaatakowanie nieaktualizowanego komputera z systemem Windows 7 w sieci wewnętrznej poprzez przejście NAT).
Aby wykorzystać luki, osoba atakująca musi znajdować się w zasięgu docelowego urządzenia bezprzewodowego, aby wysłać ofierze specjalnie spreparowany zestaw ramek. Problemy dotyczą zarówno urządzeń klienckich i kart bezprzewodowych, jak i punktów dostępowych i routerów Wi-Fi. Ogólnie rzecz biorąc, jako obejście wystarczy użycie protokołu HTTPS w połączeniu z szyfrowaniem ruchu DNS przy użyciu protokołu DNS przez TLS lub DNS przez HTTPS. Sieci VPN są również dobre do ochrony.
Najbardziej niebezpieczne są cztery luki w implementacjach urządzeń bezprzewodowych, które pozwalają trywialnymi metodami na podstawienie ich niezaszyfrowanych ramek:
- Luki CVE-2020-26140 i CVE-2020-26143 umożliwiają fałszowanie ramek w niektórych punktach dostępu i kartach bezprzewodowych w systemach Linux, Windows i FreeBSD.
- Luka VE-2020-26145 umożliwia traktowanie rozgłaszanych niezaszyfrowanych fragmentów jako pełnych klatek w systemach macOS, iOS oraz FreeBSD i NetBSD.
- Luka CVE-2020-26144 umożliwia przetwarzanie niezaszyfrowanych, ponownie złożonych ramek A-MSDU za pomocą EtherType EAPOL w Huawei Y6, Nexus 5X, FreeBSD i LANCOM AP.
Inne luki w implementacjach są związane głównie z problemami pojawiającymi się podczas przetwarzania pofragmentowanych ramek:
- CVE-2020-26139: Umożliwia przekierowywanie ramek oznaczonych flagą EAPOL wysyłanych od nieuwierzytelnionego nadawcy (dotyczy 2/4 zweryfikowanych punktów dostępowych, rozwiązań opartych na NetBSD i FreeBSD).
- CVE-2020-26146: Umożliwia ponowne składanie zaszyfrowanych fragmentów bez sprawdzania kolejności numerów sekwencyjnych.
- CVE-2020-26147: Umożliwia ponowne składanie mieszanych fragmentów zaszyfrowanych i niezaszyfrowanych.
- CVE-2020-26142: Umożliwia traktowanie pofragmentowanych klatek jako pełnych klatek (dotyczy modułu bezprzewodowego OpenBSD i ESP12-F).
- CVE-2020-26141: Brak kontroli TKIP MIC pod kątem pofragmentowanych ramek.
Problemy w specyfikacjach:
- CVE-2020-24588 — Atak na zagregowane ramki (flaga „jest zagregowana” nie jest chroniona i może zostać zastąpiona przez osobę atakującą w ramkach A-MSDU w WPA, WPA2, WPA3 i WEP). Jako przykład ataku wymienia się przekierowanie użytkownika na złośliwy serwer DNS lub przejście NAT.
- CVE-2020-245870 – Atak polegający na mieszaniu kluczy (dozwolone jest ponowne składanie fragmentów zaszyfrowanych przy użyciu różnych kluczy w standardach WPA, WPA2, WPA3 i WEP). Atak pozwala określić, jakie dane przesyłane są przez klienta, np. określić zawartość pliku cookie w przypadku dostępu za pośrednictwem protokołu HTTP.
- CVE-2020-24586 — Atak fragmentów na pamięć podręczną (standardy obejmujące WPA, WPA2, WPA3 i WEP nie wymagają czyszczenia fragmentów buforowanych po nowym połączeniu sieciowym). Pozwala ustalić, jakie dane przesyłane są przez Klienta i dokonać podstawienia Twoich danych.
Aby przetestować stopień podatności ich urządzeń na problemy, przygotowano specjalny zestaw narzędzi i gotowy obraz Live-image do utworzenia bootowalnego dysku USB. W systemie Linux problemy pojawiają się w sieci bezprzewodowej mac80211, w oddzielnych sterownikach sieci bezprzewodowej i oprogramowaniu sprzętowym załadowanym na karty sieci bezprzewodowej. W celu wyeliminowania podatności zaproponowano zestaw łatek obejmujących stos mac80211 oraz sterowniki ath10k / ath11k. W przypadku niektórych urządzeń, takich jak karty bezprzewodowe Intel, wymagana jest dodatkowa aktualizacja oprogramowania sprzętowego.
Testy typowych urządzeń:
Testy kart bezprzewodowych w systemie Linux i Windows:
Testy kart bezprzewodowych we FreeBSD i NetBSD:
Producenci zostali powiadomieni o problemach 9 miesięcy temu. Tak długi okres embarga wynika ze skoordynowanego przygotowania aktualizacji oraz opóźnień w przygotowaniu zmian w specyfikacjach przez ICASI i Wi-Fi Alliance. Początkowo planowano ujawnienie informacji 9 marca, jednak po rozważeniu ryzyka zdecydowano się przesunąć publikację o kolejne dwa miesiące, aby dać więcej czasu na przygotowanie poprawek, biorąc pod uwagę nietrywialność wprowadzanych zmian i trudności wynikające z pandemii Covid-19.
Warto zauważyć, że pomimo embarga Microsoft w marcowej aktualizacji Windowsa usunął część luk przed terminem. Ujawnienie opóźniło się o tydzień przed pierwotnie planowanym terminem, a Microsoft nie miał czasu lub nie chciał wprowadzić zmian w zaplanowanej aktualizacji gotowej do publikacji, co stworzyło zagrożenie dla użytkowników innych systemów, gdyż osoby atakujące mogły uzyskać informacje o lukach poprzez inżynieria wsteczna zawartości aktualizacji.
Źródło: opennet.ru