Bezpieczeństwo sieci bezprzewodowych to przedmiot wielu gorących dyskusji. W czasach, gdy standard WiFi był jeszcze czymś nowym, badacze odkryli olbrzymie problemy związane z zabezpieczeniami protokołu WEP, który miał, według jego autorów, zapewniać prywatność komunikacji na poziomie połączenia kablowego – stąd jego nazwa Wired Equivalent Privacy.

Błędy projektowe algorytmów WEP skutkują tym, że przy odpowiednich warunkach, pokonanie jego zabezpieczeń zajmuje mniej niż minutę. Znacząco pomaga fakt, że możliwe jest ponowne wstrzykiwanie raz już zarejestrowanych pakietów (brak skutecznej ochrony przed powtórzeniami). Producenci szybko stworzyli tymczasowe rozwiązanie problemu, tak aby nie była konieczna natychmiastowa wymiana starych urządzeń, których moc obliczeniowa nie pozwalała na stosowanie bardziej wyrafinowanych metod szyfrowania. Powstały TKIP oraz standard WPA. Niezbędne było jednak zastosowanie nowej, znacznie bezpieczniejszej technologii. W 2004 r. komitet IEEE opublikował standard 802.11i, który naprawiał wszystkie znane problemy mechanizmów WEP, umożliwiając wykorzystanie bezpiecznego protokołu szyfrującego AES CCMP. Choć od tamtej pory odkryto nowe luki w bezpieczeństwie starszych protokołów (WEP oraz TKIP) żaden poważny atak na WPA2 z AES nie był znany, a sam protokół uważany był za wystarczająco bezpieczny, by wdrażać go nawet w sieciach wymieniających niezwykle ważne dane.

Ostatnie badania dotyczące ataków Key Reinstallation przeprowadzone przez Mathy’ego Vanhoef’a oraz Franka Piessens’a pokazały, że faktyczna implementacja standardu 802.11i w postaci kodu w systemie operacyjnym może generować niebezpieczne podatności. Odkryty problem dotyczy mechanizmów używanych do ustalania tymczasowych kluczy szyfrujących (4-way handshake). W trakcie tej wymiany informacji klient bezprzewodowy ustala ze swoim punktem dostępowym (AP) tymczasowe klucze szyfrujące (Pairwise Transient Key, PTK oraz GTK – Group Temporal Key), które będą używane do szyfrowania bieżącej transmisji (unicast oraz broadcast). Wymiana ta jest możliwa, gdy obie strony posiadają ten sam klucz główny (Pairwise Master Key, PMK). PMK używany jest niezależnie od tego, czy sieć wykorzystuje uwierzytelnianie przy pomocy hasła współdzielonego (PSK), czy korporacyjnych mechanizmów autentykacji opartych na protokole 802.1X. Klucz ten jest albo wyliczany z PSK albo negocjowany w trakcie uwierzytelniania przy pomocy innych metod. Podatność Key Reinstallation Attack dotyczy obu wymienionych sytuacji. Tymczasowe klucze sesji (PTK) powstają z klucza głównego (PMK), a także z wartości adresów fizycznych urządzeń (MAC) oraz losowych, jednorazowych liczb (nonce) ustalanych właśnie w czasie tej wymiany. Są unikalne dla danej sesji oraz dla danego urządzenia. Klucze grupowe (GTK) natomiast, używane do zabezpieczania ruchu do wszystkich klientów (broadcast), są odświeżane co jakiś czas przez bezprzewodowy punkt dostępu (AP), w miarę jak urządzenia odłączają się od sieci. 4-way hanshake pozwala uchronić się przed znaną z czasów WEP’a sytuacją, gdzie współdzielony klucz szyfrujący będzie za każdym razem używany bezpośrednio do szyfrowania danych (dla wszystkich urządzeń, dla wszystkich ich sesji), co znacząco ułatwia jego złamanie.

Badacze okryli jednak, że możliwe jest wymuszenie ponownego użycia ustalonego wcześniej klucza sesji (PTK) a także kluczy grupowych (GTK) w celu wyzerowania liczników pakietów, które chronią przed powtórzeniami. Znanym problemem w sieciach bezprzewodowych jest nie do końca przewidywalne, współdzielone medium transmisyjne. Właśnie dlatego standard przewiduje sytuację, w której pojedynczy pakiet może zostać uszkodzony „w locie” i konieczna będzie jego retransmisja. Niestety standard nie doprecyzował warunku, który musiałby być spełniony, aby ponownie przesłany pakiet z wrażliwego 4-way lub group handshake, wywołał wyzerowanie liczników oraz ponowną instalację kluczy szyfrujących. Obecnie dzieje się tak w każdym przypadku otrzymania takiego pakietu. Właśnie tę cechę wykorzystano do przeprowadzenia ataku key reinstallation. Atakujący jest w stanie podsłuchać oraz ponownie nadać wrażliwy pakiet, co będzie skutkowało możliwością obejścia mechanizmu kontroli sekwencji danych i ponownego użycia starych pakietów (replay).

Niestety niektóre implementacje standardu WPA, wspomniane w opracowaniu, zachowują się jeszcze gorzej. W przypadku najbardziej podatnych wersji Linux’a oraz Android’a 6.0 na skutek dodatkowego błędu programistycznego, nie zostanie użyty ponownie stary klucz PTK, ale taki, który składa się z samych zer.

Co to oznacza w praktyce? Realne zagrożenie różni się w zależności od atakowanej platformy (systemu operacyjnego). Należy pamiętać, że atak możliwy jest w stronę klienta bezprzewodowego (tabletu, telefonu, komputera, etc). Dzięki wyzerowaniu liczników pakietów możliwe jest ponowne wstrzykiwanie ruchu (replay), co może umożliwić deszyfrowanie komunikacji a nawet generowanie fałszywych, poprawnie zaszyfrowanych pakietów. W szczególnym przypadku (wspomniane wersje Linux’a oraz Androida) możliwy jest nawet skuteczny atak typu MiTM (Man in The Middle), który został zademonstrowany w ramach Proof-of-Concept przez autorów opracowania.

Odkryta podatność nie podważa jeszcze skuteczności działania algorytmu WPA2, gdyż dotyczy szczególnych błędów w jego implementacji a nie zaś samej idei działania. Badacze opisują także potencjalne rozwiązanie problemu sugerując metody załatania dziurawego kodu a producenci szybko starają się opublikować nowe wersje swojego oprogramowania.

Jak chronić się przed nowoodkrytymi podatnościami? Należy przede wszystkim zaktualizować oprogramowanie urządzeń klienckich WiFi – laptopów, smartfonów, tabletów oraz urządzeń IoT wyposażonych w karty sieciowe w standardzie 802.11. I właśnie z tymi ostatnimi może być pewien problem, ponieważ producenci nie zawsze publikują stosowne poprawki ich oprogramowania układowego. Problem może też pojawić się w przypadku urządzeń z Androidem, gdyż słabe wsparcie ze strony producentów sprzętu powoduje, że relatywnie duża ilość urządzeń może nadal działać w oparciu o podatny kod, ponieważ nie będą dostępne dla nich nowe wersje oprogramowania.

Materiał źródłowy: https://papers.mathyvanhoef.com/ccs2017.pdf

Autor: Andrzej Sawicki – Sales Engineer w Trend Micro