Lucky thirteen – nowy typ ataku na SSL / TLS. Nie panikuj?

Protokół SSL czy jego następca – TLS to zestawy protokołów będących podstawą bezpieczeństwa w Internecie. Łączysz się do swojego banku z wykorzystaniem https? Używasz zatem jednego z z nich. Na początku lutego 2013r. pokazano słabości tych protokołów umożliwiające rozszyfrowanie ruchu chronionego TLS (wszystkie wersje tego protokołu). Brzmi groźnie? Zobaczmy.

W największym skrócie, atak na ostatnią wersję SSLv3 oraz wszystkie wersje TLS (1.0, 1.1, oraz 1.2) polega na podsłuchu zaszyfrowanego ruchu oraz odpowiedniej modyfikacji przechwyconych pakietów i ponownym wysłaniu ich do celu. Po wysłaniu odpowiedniej liczby zmodyfikowanych szyfrogramów jesteśmy w stanie podsłuchać ofiarę.

Na szczęście żeby atak się powiódł, musi być spełnionych kilka warunków:

• Atakujący musi wykonać na nas atak man-in-the-middle (np. arp spoofing implementowany przez ettercap).
• Atakujący musi znajdować się blisko jednej ze stron szyfrowanego tunelu (LAN lub część serwerowa).
• Wymagane jest nawiązanie przez atakującego około 2^23 (=8388608) sesji SSL/TLS (rodzaj ataku bruteforce).

Sami badacze problemu z TLS stwierdzili, że jeśli chodzi o najbardziej ogólny wariant ataku (większość implementacji TLS, niewielkie lub żadne warunki dodatkowe), atak nie jest na dzień dzisiejszy do zrealizowania praktycznego:

Given its complexity, this full plaintext recovery
attack on TLS should, for now, be considered more of a theoretical
threat.

Jednak zaraz dodają, że zoptymalizowane ataki przeprowadzane w szczególnych warunkach można uznać za praktycznie przeprowadzalne –  w szczególności atakujące bardzo popularnego OpenSSL (wykorzystywanego np. w popularnym serwerze www Apache) w kontekście środowiska webowego (https):

We estimate that HTTP cookies can be recovered using 2^13
sessions per byte of cookie.

Czyli wystarczy nawiązać 2^13 = 8192 sesje TLS / per bajt cookie, aby analizując dalszą komunikację, odzyskać jeden bajt z zaszyfrowanego cookie. Czy to duży problem? Na razie tak, nawiązywanie ponad 8000 sesji TLS trwa dość długo, przemnożone przez liczbę bajtów które chcemy odzyskać…trwa jeszcze dłużej. W praktyce może to oznaczać nawet kilka dni aktywnego ataku na nas (a np. wylogowanie z bankowości elektronicznej – tj. unieważnienie ID sesji które chcemy odzyskać) najprawdopodobniej powoduje że trzeba zaczynać atak od nowa. Czym się więc przejmować? Zazwyczaj z czasem ataki podlegają pewnym optymalizacjom…

Spróbujmy dokładniej prześledzić kilka faktów o ataku „lucky thirteen„.

Po pierwsze, nasze szyfrowane połączenie musi wykorzystywać symetryczny szyfr blokowy w trybie CBC (Cipher Block Chaining) – to w zasadzie standard w komunikacji TLS (np. do szyfrowania często wykorzystywany jest algorytm AES, w trybie CBC).

Na razie mamy bezpieczny algorytm (np. AES) oraz bezpieczny tryb jego pracy – CBC. W czym więc problem? Otóż w samej architekturze TLS oraz wiążących się z nią konkretnych implementacjach (np. OpenSSL). Oto dwa kolejne fakty:

Ale nasze szyfrowane dane nie są zawsze wielokrotnością bloku 16. Aby algorytm działał, ostatni niepełny blok jest uzupełniany (padding) do długości bloku (np. 16 bajtów) i dopiero wtedy szyfrowany. W rzeczywistości TLS realizuje padding do wielokrotności bloku, tj. może zrealizować go np. do 32 bajtów.

Kolejny istotny element układanki:

Podsumowując, mając wiadomość M do zaszyfrowania, robimy tak (w małym uproszczeniu):

• wylicz MAC komunikatu M,
• dołącz MAC do komunikatu M,
• uzupełnij całość do długości bloku wykorzystanego szyfru blokowego (lub jej wielokrotności),
• na tym wyniku wykonaj szyfrowanie algorytmem symetrycznym w trybie CBC.

Całość można zobaczyć np. na filmie tutaj albo na diagramie poniżej:

Szyfrowanie TLS – fragment. Diagram inspirowany oryginalną pracą o lucky thirteen

Warto zauważyć jedną ciekawą rzecz – TLS nie sprawdza integralności paddingu (MAC jest stosowany tylko na zielony komunikat powyżej, bez białego paddingu).

Zarówno AES, tryb CBC jak i mechanizm HMAC-SHA1 (jeden z typów MAC) są uznawane za bezpieczne. Na razie wszystkie omawiane mechanizmy były bezpieczne…

Zmierzajmy już jednak do istoty problemu: okazuje się, że atakujący może modyfikować nasze przechwycone zaszyfrowane komunikaty (modyfikuje je bez odszyfrowywania) i wysyłać do serwera. W zależności od tego, które dane zmienił – po odszyfrowaniu wiadomości przez część serwerową raz wywołuje niezgodności MAC, raz wywołuje błąd nieprawidłowego paddingu. Skąd atakujący ma wiedzieć, w którą z tych opcji trafił, de facto „losowo”, zmieniając zaszyfrowaną wiadomość? Dowiaduje się tego pośrednio przez zerwanie sesji SSL/TLS połączone z wysłaniem komunikatu o błędzie. Komunikat sam nie zdradza szczegółów tego, co poszło nie tak (tego typu komunikaty były wykorzystywane historycznie w innych błędach dotykających TLS) – istotny jest tu czas, po jakim komunikat dociera do atakującego. Wykonując analizę statystyczną, możliwe jest rozróżnienie tych sytuacji (problem z MAC vs problem z paddingiem) i finalnie uzyskanie tekstu jawnego z komunikacji zaszyfrowanej. Na ogólnym poziomie całość jest zaawansowaną formą ataku padding oracle.

Jak się obronić?

Metod jest kilka, choć zasadnicza ochrona polega przede wszystkim na odpowiedniej implementacji SSL / TLS po stronie serwerowej. Przykładowo –  OpenSSL już dostępny jest w zaktualizowanej wersji. Inne możliwości:

• Nie używanie algorytmu blokowego – np. wykorzystanie algorytmu strumieniowego RC4 – algorytm ten jest dostępny w TLS, choć pewne obawy mogą budzić pewne „dziury” w samym algorytmie.
• Użycie innego trybu algorytmu blokowego (innego niż CBC) – np. AES w trybie GCM (dostępny jest tylko w TLS w wersji 1.2),który jeszcze nie jest zbytnio rozpowszechniony)

Bibliografia

• Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
• Orginala praca badawcza – Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
• Attack of the week: TLS timing oracles
• Poprzednie ataki na TLS – BEAST oraz CRIME

michal.sajdak<at>sekurak.pl