KRACK – nowy atak potrafiący rozszyfrować/złamać każde WiFi

Atak dotyka wszystkich nowoczesnych implementacji WPA2, a jest szczególnie niebezpieczny na Androidzie 6+ / Linuksie – można zmusić połączenie WiFi  do użycia klucza sesyjnego składającego się z samych zer… A to wszystko przez to, że te platformy chciały być bardziej bezpieczne, ale o tym trochę dalej.

W zależności od używanego modelu zabezpieczeń można: deszyfrować komunikację, fałszować komunikację (czyli podszywać się pod wysyłającego pakiety), wstrzykiwać pakiety.

Istota ataku

Na czym polega atak? Przede wszystkim na odpowiednim, ponownym odtworzeniu pewnych komunikatów wysyłanych pomiędzy klientem a AP, podczas tzw. 4-way handshake, czyli procesu komunikacji dwóch stron, w którym m.in. udowadniają że znają klucz dzielony (taki który ustawiacie zabezpieczając sieć WiFi), bez ujawniania tego klucza. W wyniku procesu tworzony jest tu też dodatkowy klucz (Temporal Key), który szyfruje komunikację (tj. zapewnia jej poufność).

Przy ponownym odtworzeniu jednego z komunikatów z 4-way handshake, raz ustalonego klucza sesyjnego nie da się zmienić, ale – i tu leży duży problem – resetowane są tzw. nonce (arbitrary number that may only be used once) używane w szyfrowaniu komunikacji. Nonce – który z założenia ma być używany tylko raz, jest teraz używany taki sam (bo został zresetowany do wartości początkowej) – to nie wygląda dobrze i prowadzi do możliwości deszyfracji komunikacji. W oryginale autorzy tłumaczą to tak:

As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.

Android i Linux – chciały być bezpieczniejsze – są mniej bezpieczne

Uważni czytelnicy zauważyli może pewną sprzeczność w paragrafach powyżej, piszemy przecież że „raz ustalonego klucza sesyjnego nie da się zmienić”, a z drugiej strony że na Androidzie czy Linuksie udało się ustalić klucz z samych zer.

No więc powyższe systemy, zgodnie z zaleceniami stojącymi w standardzie WiFi – czyszczą klucz sesyjny z pamięci po jego tzw. instalacji.

This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.

Więc w momencie replay fragmentu komunikacji z 4-way handshake, brany jest ten sam klucz (miał być nie zmieniany!) – ale teraz w pamięci siedzą tam same zera ! Więc ustalane są zera.

Dla uczciwości warto zaznaczyć, że podatne są nie Linux czy Android jako taki, ale wykorzystywany w nich bardzo często komponent –  WPA Supplicant.

Rodzaj wykorzystanych algorytmów a skutki ataku

Najmniej podatny jest tryb AES-CCMP – można tu „tylko” deszyfrować oraz jeszcze raz odgrywać (replay) wcześniej zaszyfrowaną komunikację. W przypadku z kolei WPA-TKIP oraz GCMP można również fałszować pakiety z obu stron.

(…) , against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged.

Warto też wspomnieć że nie udało się pokazać ataku, który odtworzy główny shared-key (ten który ustawiacie konfigurując sieć WiFi).

Co jest podatne?

Niemal wszystko (choć na niektórych systemach ataki są znacznie ograniczone) – np. Windows czy iOS z racji, że nie koniecznie trzymają się standardu 802.11:

Windows and iOS do not accept retransmissions of message 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnerable to our attack against the group key handshake (see Section 4).

są podatne na inny, mniej niebezpieczny, wariant (wskazany powyżej). Tutaj prawdopodobnie można „tylko” ponownie odgrywać (replay) pakiety wysłane multicastem i broadcastem.

Tabela podsumowująca różne warianty ataku / platformy – poniżej:

WiFi – ataki

Jak się chronić?

Na szczęście wystarczy aktualizacja softwareowa – która w uproszczeniu polega na uniemożliwieniu replay odpowiedniego komunikatu z 4-way handshake, co więcej po aktualizacji naszego Access Pointa,  niespatchowani klienci mogą nadal poprawnie się łączyć.

Ale czy wystarczy patchowanie AP ? Niekoniecznie, a nawet bardziej wskazane jest patchowanie klientów (atak zostały przeprowadzony właśnie z celowaniem w klientów nie AP)!

Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. (…)  For ordinary home users, your priority should be updating clients such as laptops and smartphones.

Co więcej AP są podatne, jeśli używane są w trybie klienckim (np. jako repeatery) czy korzystające z 802.11r, więc jeszcze raz powtórzymy, że lepiej jest załatać klienta (kiedy ostatni raz instalowaliście aktualizacje na Waszym Androidzie?).

Czy zapatchowany AP a niezapatchowany klient pomoże? Naszym zdaniem – po analizie źródłowego materiału – niekoniecznie, szczególnie tak wcześnie po ogłoszeniu szczegółów ataku.

Wydają się to też potwierdzać komentatorzy na Reddicie:

(…) Nope. I see a lot of confusion on /r/sysadmin and other places where they think just patching the AP fixes this. AP patches are for when APs act like clients, like with bridging.

The client has to be patched for this to be fixed. The exploit happens due to client action: the 4 way handshake. The AP can’t work around a client behavior.

Lista producentów, którzy wydali aktualizacje.

Ostanie smaczki

OpenBSD wydał „cichego” patcha znacznie wcześniej niż skoordynowane ujawnienie, które odbyło się dzisiaj (przez co można było wcześniej  uzyskać informację o podatności). Autorzy zaproponowali więc że podczas przyszłym aktualizacji, team OpenBSD otrzyma informacje znacznie później (bliżej czasu ujawnienia).

Trochę wcześniej wydał też aktualizacje Mikrotik (w zeszłym tygodniu), ale chyba umknęło to uwadze autora badań – z drugiej strony ~tydzień wcześniej to jeszcze nie tragedia ;-)

–Michał Sajdak