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

08 lutego 2013, 16:44 | Aktualności | 1 komentarz
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

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).

Algorytm symetryczny służy przede wszystkim do zapewnienia poufności przesyłanych przez nas danych – najbardziej znanym nowoczesnym i bezpiecznym algorytmem tego typu jest AES (inne to choćby 3DES, czy od dawna niebezpieczny DES).
Tryb działania algorytmu blokowego to jeden ze sposobów pracy każdego z algorytmów blokowych. CBC to jeden z tych trybów – generalnie uznawany za bezpieczny.

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:

Szyfry blokowe działają w ten sposób, że szyfrują dane dopiero po „zebraniu” odpowiedniej ilości danych (tzw. bloku – np. 16 bajtów).

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:

MAC. Do zapewnienia integralności transmisji w TLS wykorzystywany jest tzw. MAC (Message Authentication Code). Przykład tego typu mechanizmu  wykorzystywanego w TLS: HMAC-SHA1 – można zobaczyć tutaj.

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

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

michal.sajdak<at>sekurak.pl

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



Komentarze

  1. No budzi się człowiek na kacu w sobotę i już czyta o dziurawym SSLu :P

    Odpowiedz

Odpowiedz