r   e   k   l   a   m   a
r   e   k   l   a   m   a

Szczęśliwa trzynastka – nowe zagrożenie dla internetowych połączeń szyfrowanych TLS

Strona główna Aktualności

Protokół Transport Layer Security to od lat standard w dziedzinie zapewniania bezpiecznych połączeń w niezabezpieczonych sieciach. Korzystają z niego webowe aplikacje bankowe, sklepy internetowe, systemy płatności, aplikacje mobilne, a na rynku dostępne są zarówno jego implementacje własnościowe, jak i opensource'owe, takie jak OpenSSL czy PolarSSL. Protokół ten (a raczej zestaw protokołów) ma też bliskiego kuzyna – DTLS, który został przystosowany do połączeń po UDP, zamiast standardowego internetowego TCP. Jak widać, protokoły te stanowią kluczowy element infrastruktury bezpieczeństwa IT naszego świata, i nie można przecenić wagi badań nad nimi.

Dwóch badaczy z University of London i Information Security Group, Nadhem Al Fardan i Kenneth Paterson, opublikowało artykuł, w którym przedstawiają skuteczny atak przeciwko TLS/DTLS (włącznie z najnowszą wersją protokołu, 1.2), pozwalający odszyfrować zabezpieczone w ten sposób połączenia HTTP. Atak możliwy jest przeciwko wszystkim istniejącym implementacjom tych protokołów, wykorzystuje bowiem słabości w samej ich architekturze, a konkretnie opóźnienia czasowe podczas deszyfrowania.

Dane przesyłane przez TLS są przetwarzane zwykle w trybie CBC – wiązania bloków zaszyfrowanych (takim, w którym wynik szyfrowania zależy od poprzednich bloków). Bloki takie muszą mieć stałą długość, więc są uzupełniane do niej za pomocą bajtów dopełnienia (padding). Każdy taki bajt zawiera informację o tym, ile bajtów dopełnienia jest potrzebnych. Jest jednak jeden blok, który nie jest dopełniany, to tzw. kod uwierzytelnienia MAC, wykorzystywany do sprawdzenia poprawności danych.

Podobnie jak w ataku typu padding oracle, który został niegdyś wykorzystany do złamania szyfrowanych ciasteczek z frameworków takich jak Rails, ASP.NET czy JavaServer Faces, jeszcze do niedawna napastnik mógł skopiować poprawnie zaszyfrowane dane i odesłać je odbiorcy do odszyfrowania. Jeśli odbiorca zgłosił błąd dopełnienia zamiast błędu MAC, napastnik mógł to wykorzystać do odszyfrowania danych. Poprawki wprowadzone do TLS pozwoliły na wyeliminowanie tego zagrożenia – jeśli sprawdzenie MAC zakończy się niepowodzeniem, nie jest zwracana informacja o błędzie. Dzięki poprawkom nie można już też wykryć błędnych dopełnień – MAC wyliczany jest nawet wtedy, gdy dopełnienie jest nieprawidłowe.

Pozostaje jednak jedna jeszcze droga ataku. Podczas deszyfrowania wiadomości, nie jest z góry znana liczba bajtów dopełnienia, którą należy usunąć, pozostają więc różnice czasowe w tej operacji. W swoim artykule Al Fardan i Paterson pokazują, jak można te różnice czasowe wykorzystać do kompletnego odszyfrowania danych zabezpieczonych TLS. Oto ich sposób:

TLS wykorzystuje algorytm HMAC, czyli MAC uzupełniony o tajny klucz, pozwalający zabezpieczyć go przed sfałszowaniem, wyliczający funkcje skrótu dla co najwyżej 55 bajtów. W ataku wykorzystywane są wiadomości mające ponad 55 bajtów z dopełnieniem i poniżej 55 bajtów bez dopełnienia. Uszkodzenie dopełnienia oznacza, że proces deszyfrowania będzie działał nieco dłużej: musi wyliczyć wartości HMAC zarówno dla pierwszych 55 bajtów jak i dla tego, co pozostało. W dokumentacji protokołów TLS 1.1 i 1.2 można przeczytać, że różnice te są zbyt małe, by je wykorzystać do niecnych celów – ale najwyraźniej jest inaczej. Jak piszą autorzy, jeśli uda się uzyskać odpowiednie zestawienie takich czynników jak rozmiar tagów MAC, rozmiar szyfrowanego bloku i liczba bajtów nagłówka, to pojawią się w sieci różnice w czasie pojawiania się sygnałów o błędzie. Wówczas powiązanie danych z opóźnień czasowych z analizą statystyczną dla wielu próbek może pozwolić na uzyskanie danych w jawnej postaci.

Atak tego typu wymaga oczywiście naprawdę wielu pomiarów. Podczas prób przeprowadzonych w sieci LAN, udało się odszyfrować dane po 2^23 sesji. Jeśli wiadome było, że przesyłane dane są zakodowane w Base64 (tak jest w wypadku danych logowania i ciasteczek), liczbę sesji można było ograniczyć do 2^19. Szczęśliwie TLS zwykle przerywa sesje po wystąpieniu błędu, więc przeprowadzenie ataku w Internecie łatwe nie będzie (napastnik musi być w stanie uruchomić dużą liczbę sesji i znajdować się w pobliżu ofiary), ale już w wypadku DTLS jest inaczej – dane wysyłane po UDP mogą zostać w ten sposób ujawnione. Co gorsza, techniki te można wykorzystać w połączeniu z tymi, które znane są z ataku BEAST: działające w przeglądarce ofiary szkodliwe oprogramowanie może uruchamiać wszystkie potrzebne sesje TLS, umieszczając ciasteczko w przewidywalnych miejscach każdej sesji. W ten sposób można odzyskać ciasteczko za pomocą 2^13 sesji.

Badacze wykazali się dużą odpowiedzialnością – swoje odkrycie przekazali wszystkim ważnym twórcom oprogramowania, korzystającym z TLS/SSL w swoich produktach. Zabezpieczenia zostały już wprowadzone w OpenSSL, PolarSSL, Operze i GnuTLS, a Mozilla ogłosiła, że pracuje nad poprawkami w bibliotekach NSS.

A skąd nazwa „Szczęśliwa Trzynastka” (Lucky 13)? Chodzi tu o liczbę bajtów w nagłówku (13), wykorzystywanych do wyliczania wartości MAC. Szczęśliwsza byłaby, jak piszą autorzy, dwunastka – gdyby nagłówek miał 12 bajtów, wystarczyłoby 2^8 sesji przeciwko TLS z wiązaniem bloków zaszyfrowanych i HMAC z SHA1.

r   e   k   l   a   m   a
© dobreprogramy

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.