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

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

Protokół Transport Layer Security to od lat standard wdziedzinie zapewniania bezpiecznych połączeń w niezabezpieczonychsieciach. Korzystają z niego webowe aplikacje bankowe, sklepyinternetowe, systemy płatności, aplikacje mobilne, a na rynkudostępne są zarówno jego implementacje własnościowe, jak iopensource'owe, takie jak OpenSSL czy PolarSSL. Protokół ten (araczej zestaw protokołów) ma też bliskiego kuzyna – DTLS, któryzostał przystosowany do połączeń po UDP, zamiast standardowegointernetowego TCP. Jak widać, protokoły te stanowią kluczowyelement infrastruktury bezpieczeństwa IT naszego świata, i niemożna przecenić wagi badań nad nimi.[img=aa]Dwóch badaczy z University of London i Information SecurityGroup, Nadhem Al Fardan i Kenneth Paterson, opublikowało artykuł,w którym przedstawiają skuteczny atak przeciwko TLS/DTLS (włączniez najnowszą wersją protokołu, 1.2), pozwalający odszyfrowaćzabezpieczone w ten sposób połączenia HTTP. Atak możliwy jestprzeciwko wszystkim istniejącym implementacjom tych protokołów,wykorzystuje bowiem słabości w samej ich architekturze, akonkretnie 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 szyfrowaniazależy od poprzednich bloków). Bloki takie muszą mieć stałądługość, więc są uzupełniane do niej za pomocą bajtówdopełnienia (padding). Każdy taki bajt zawiera informację otym, ile bajtów dopełnienia jest potrzebnych. Jest jednak jedenblok, który nie jest dopełniany, to tzw. kod uwierzytelnienia MAC,wykorzystywany do sprawdzenia poprawności danych.Podobnie jak w ataku typu paddingoracle, który został niegdyś wykorzystany do złamaniaszyfrowanych ciasteczek z frameworków takich jak Rails, ASP.NET czyJavaServer 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. Poprawkiwprowadzone do TLS pozwoliły na wyeliminowanie tego zagrożenia –jeśli sprawdzenie MAC zakończy się niepowodzeniem, nie jestzwracana informacja o błędzie. Dzięki poprawkom nie można jużteż wykryć błędnych dopełnień – MAC wyliczany jest nawetwtedy, gdy dopełnienie jest nieprawidłowe.[img=tlscrypt]Pozostaje jednak jedna jeszcze droga ataku. Podczas deszyfrowaniawiadomości, nie jest z góry znana liczba bajtów dopełnienia,którą należy usunąć, pozostają więc różnice czasowe w tejoperacji. W swoim artykule Al Fardan i Paterson pokazują, jak możnate różnice czasowe wykorzystać do kompletnego odszyfrowania danychzabezpieczonych TLS. Oto ich sposób:TLS wykorzystuje algorytm HMAC,czyli MAC uzupełniony o tajny klucz, pozwalający zabezpieczyć goprzed sfałszowaniem, wyliczający funkcje skrótu dla co najwyżej55 bajtów. W ataku wykorzystywane są wiadomości mające ponad 55bajtów z dopełnieniem i poniżej 55 bajtów bez dopełnienia.Uszkodzenie dopełnienia oznacza, że proces deszyfrowania będziedziałał nieco dłużej: musi wyliczyć wartości HMAC zarówno dlapierwszych 55 bajtów jak i dla tego, co pozostało. W dokumentacjiprotokołó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 – alenajwyraźniej jest inaczej. Jak piszą autorzy, jeśli uda sięuzyskać odpowiednie zestawienie takich czynników jak rozmiar tagówMAC, rozmiar szyfrowanego bloku i liczba bajtów nagłówka, topojawią się w sieci różnice w czasie pojawiania się sygnałów obłędzie. Wówczas powiązanie danych z opóźnień czasowych zanalizą statystyczną dla wielu próbek może pozwolić na uzyskaniedanych 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 223 sesji. Jeśli wiadome było, że przesyłane dane sązakodowane w Base64 (tak jest w wypadku danych logowania iciasteczek), liczbę sesji można było ograniczyć do 219.Szczęśliwie TLS zwykle przerywa sesje po wystąpieniu błędu, więcprzeprowadzenie ataku w Internecie łatwe nie będzie (napastnik musibyć w stanie uruchomić dużą liczbę sesji i znajdować się wpobliżu ofiary), ale już w wypadku DTLS jest inaczej – danewysyłane po UDP mogą zostać w ten sposób ujawnione. Co gorsza,techniki te można wykorzystać w połączeniu z tymi, które znanesą z atakuBEAST: działające w przeglądarce ofiary szkodliweoprogramowanie może uruchamiać wszystkie potrzebne sesje TLS,umieszczając ciasteczko w przewidywalnych miejscach każdej sesji. Wten sposób można odzyskać ciasteczko za pomocą 213 sesji.Badacze wykazali się dużą odpowiedzialnością – swojeodkrycie przekazali wszystkim ważnym twórcom oprogramowania,korzystającym z TLS/SSL w swoich produktach. Zabezpieczenia zostałyjuż wprowadzone w OpenSSL,PolarSSL, Operze i GnuTLS, a Mozilla ogłosiła, że pracuje nadpoprawkami w bibliotekach NSS.A skąd nazwa „Szczęśliwa Trzynastka” (Lucky 13)? Chodzi tuo liczbę bajtów w nagłówku (13), wykorzystywanych do wyliczaniawartości MAC. Szczęśliwsza byłaby, jak piszą autorzy, dwunastka– gdyby nagłówek miał 12 bajtów, wystarczyłoby 28 sesjiprzeciwko TLS z wiązaniem bloków zaszyfrowanych i HMAC z SHA1.

Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Udostępnij:
Wybrane dla Ciebie
Komentarze (10)