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

16 października 2017, 20:44 | Aktualności | komentarzy 15
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

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 zdaniempo 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:

There’s nothing the AP could do to change the way the client behaves.

(…) 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

 

 

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Eddie Murphy

    Dzięki za opis ;)

    Odpowiedz
  2. fyx

    „kiedy ostatni raz instalowaliście aktualizacje na Waszym Androidzie?”

    Myślę że sporo osób by chciało żeby producenci załatali ostatnie błędy w BT oraz WiFi, ale producentom na tym nie zależy, bo tylko liczy się sprzedaż nowych urządzeń.

    Odpowiedz
    • John Sharkrat

      W zeszły czwartek i pewnie w przyszły piątek.

      Odpowiedz
  3. Nowy atak na WiFi, błąd w generowaniu kluczy RSA i zapowiedź że OpenBSD ma dostawać później informacje o incydentach bezpieczeństwa robi się ciekawie w działce security :)

    Odpowiedz
  4. Tenfilip

    Dzięki za super opis. Przestańcie mówić „autorzy”, to jest jeden autor tylko używa liczby mnogiej, bo takie się przyzwyczaił :D

    Odpowiedz
    • On używamy, my trochę używamy zamiennie. A gość w sumie nawet napisał w FAQ osobny wpis o tym :P Też możesz pisać w drugiej osobie – bo autorem artka jest jedna osoba a nie „my” ;-))

      Odpowiedz
  5. Alojzy

    Synology RT2600ac też dostał już aktualizację z fixem.

    Odpowiedz
  6. Krzysztof Kozłowski

    A jak mówiłem ludziom że wifi w firmie to zło wcielone i jeśli nie jest niezbędne to trzeba nie stosować to się na mnie patrzyli jak na wariata :(

    Odpowiedz
  7. Bart

    Debian załatany, dd-wrt załatane. Dziękuję dobranoc :D

    Odpowiedz
    • Krzysztof Kozłowski

      I co z tego skoro kolega z androidem nie załatany?
      I pracownik z niezaktualizowaną 7 (bo aktualizacje to zło i szpiegostwo) nie załatany….
      Ciekawe co z wszystkimi drukarkami… Takie fajne bez kabli…. :D

      Odpowiedz
  8. Radek

    A w której aktualizacji Mikrotika jest ta poprawka?
    Nie mogę jakoś znaleźć w opisach na routerach.

    Odpowiedz
  9. John Sharkrat

    Moje Linuksy i androidy są już bezpieczne i odporne.

    Odpowiedz
  10. Art

    Mam pytanie odnośnie SmartTV, wie ktoś czy Samsung i LG będą łatać telewizory?

    Odpowiedz
  11. Piotr

    A jak sprawdzić czy dane urządzenia są podatne (lub załatane) ?

    Odpowiedz
  12. Adaś

    Najlepszy jest kabel

    Odpowiedz

Odpowiedz