Kilka dni temu pisaliśmy o zapowiedzi publikacji nowego ataku na SSL, umożliwiającego kradzież ciasteczek sesji użytkownika. Szczegóły ataku mają zostać ujawnione za kilka dni, ale w sieci pojawiły się już wiarygodne teorie opisujące możliwy przebieg ataku.
Pierwszy opis możliwego przebiegu ataku znaleźliśmy w serwisie StackExchange. Według jego autora atak CRIME, umożliwiający odgadnięcie zawartości zaszyfrowanego ciasteczka użytkownika, opracowany przez Juliano Rizzo i Thai Duonga, ma być oparty o funkcję kompresji przesyłanego komunikatu i jej podatność na zmianę długości szyfrogramu.
Jak działa CRIME
Protokół SSL/TLS umożliwia opcjonalne wykorzystanie kompresji. Jednym z algorytmów kompresji, które można wybrać w trakcie negocjacji połączenia, jest DEFLATE, używany chociażby w formacie ZIP. Algorytm ten zmniejsza objętość kompresowanych danych między innymi w taki sposób, że wykrywa identyczne fragmenty danych wejściowych i zastępuje je odwołaniem wskazującym, który fragment danych należy w danym miejscu powtórzyć.
W ataku CRIME zakładamy, że atakujący ma możliwość zarówno generowania ruchu (poprzez kod JavaScript, uruchomiony w przeglądarce ofiary), jak i jego podsłuchiwania (atak typu Man in the Middle). W trakcie np. sesji HTTPS z bankiem, przeglądarka wysyła pakiet, którego fragment może wyglądać tak:
POST / HTTP/1.1 Host: serwerbanku.pl […] Cookie: secret=7xc89f+94/wa […]
gdzie wartość 7xc89f+94/wa odpowiada za uwierzytelnienie użytkownika.
Atakujący, wykorzystując kod JavaScript, może nakłonić przeglądarkę atakowanego, by wysłała do banku żądanie, które będzie zawierać:
POST / HTTP/1.1 Host: serwerbanku.pl […] Cookie: secret=7xc89f+94/wa […] Cookie: secret=0
gdzie drugie wystąpienie ciągu „Cookie: secret” jest specjalnie dodane przez atakującego. Atakujący nie zna wartości 7xc89f+94/wa, ale zna ją przeglądarka i będzie jej używać tak długo, jak długo atakowany będzie zalogowany do swojego banku.
Algorytm DEFLATE przeanalizuje cały pakiet i kompresując go, wykorzysta powtórzenie ciągu Cookie: secret=. Spowoduje to, że rozmiar skompresowanego i następnie zaszyfrowanego pakietu będzie mniejszy, niż gdyby ciąg ten nie występował drugi raz. Jako że po znaku „=” występowała inna wartość, niż w oryginalnym ciągu, kolejny wygenerowany pakiet, o treści
POST / HTTP/1.1 Host: serwerbanku.pl […] Cookie: secret=7xc89f+94/wa […] Cookie: secret=1
będzie miał identyczny rozmiar, jak pierwszy. Jednak już pakiet
POST / HTTP/1.1 Host: serwerbanku.pl […] Cookie: secret=7xc89f+94/wa […] Cookie: secret=7
powinien być odrobinę mniejszy, ponieważ algorytm kompresji będzie mógł wykorzystać kolejny identyczny znak. Analiza rozmiaru zaszyfrowanego, skompresowanego pakietu umożliwi stwierdzenie tego faktu, odnotowanie „trafienia” i przejście do kolejnego znaku. Powtórzenie tego procesu dla kolejnych znaków ciągu niejawnego umożliwi odgadnięcie całej jego treści.
Problem ten dotyczy jedynie kompresji w protkole SSL. Protokół HTTP również obsługuje kompresję, jednak nie dotyczy ona nagłówków, a jedynie treści żądania HTTP, zatem analogiczny atak nie jest możliwy.
Skąd wiadomo, że chodzi właśnie o ten scenariusz ataku?
Po pierwsze, okazuje się, że ten atak jest faktycznie wykonalny. Kilku programistów (w tym Polak, Krzysztof Kotowicz), wspólnym wysiłkiem opracowało przykładowy kod, wykorzystujący opisany powyżej mechanizm do odczytywania zawartości ciasteczek.
Po drugie, miesiąc temu Chrome wyłączył obsługę kompresji w protokole SSL, jednocześnie wyłączając dostęp do opisu luki. Podobnie postąpiły pozostałe przeglądarki, zapewne poinformowane o problemie przez jego odkrywców.
Czy to poważna luka?
W naszej opinii nie jest to odkrycie wstrząsające posadami świata bezpieczeństwa. Przede wszystkim atak możliwy jest tylko i wyłącznie w sytuacji, gdy atakujący posiada pełen dostęp do całego ruchu sieciowego atakowanego. Bez wątpienia istnieją poważniejsze w skutkach i prostsze w implementacji ataki, które można przeprowadzić z takiej pozycji.
Nie da się jednak ukryć, ze z punktu widzenia samego pomysłu ataku, jest to ciekawa koncepcja. Co więcej, dotyczy ona protokołu, który jest przedmiotem wielu analiz, więc odkrycie nowego ataku stanowi pewnego rodzaju osiągnięcie. Nie będzie ono jednak zapewne miało większego znaczenia praktycznego – ot, taka sztuczka do pokazania na konferencji.
Aktualizacja: Został opublikowany film z demonstracja wykorzystania opisywanej przez nas powyżej luki.
