Luka w TLS umożliwiająca określenie klucza dla połączeń w oparciu o szyfry DH

Ujawnił informacje o nowym luki w zabezpieczeniach (CVE-2020-1968) w protokole TLS o kryptonimie
Szop oraz umożliwienie, w rzadkich przypadkach, określenia wstępnego klucza podstawowego (pre-master), który może zostać użyty do odszyfrowania połączeń TLS, w tym HTTPS, podczas przechwytywania ruchu tranzytowego (MITM). Należy zauważyć, że atak jest bardzo trudny do praktycznego wdrożenia i ma raczej charakter teoretyczny. Do przeprowadzenia ataku wymagana jest specyficzna konfiguracja serwera TLS oraz możliwość bardzo dokładnego pomiaru czasu przetwarzania serwera.

Problem występuje bezpośrednio w specyfikacji TLS i dotyczy jedynie połączeń wykorzystujących szyfry oparte na protokole wymiany kluczy DH (Diffie-Hellman, TLS_DH_*"). W przypadku szyfrów ECDH problem nie występuje i pozostają one bezpieczne. Podatne są tylko protokoły TLS do wersji 1.2; problem nie dotyczy protokołu TLS 1.3. Luka występuje w implementacjach TLS, które ponownie wykorzystują tajny klucz DH w różnych połączeniach TLS (takie zachowanie występuje w około 4.4% serwerów Alexa Top 1M).

W OpenSSL 1.0.2e i wcześniejszych wersjach klucz podstawowy DH jest ponownie używany we wszystkich połączeniach z serwerem, chyba że opcja SSL_OP_SINGLE_DH_USE jest jawnie ustawiona. Od wersji OpenSSL 1.0.2f klucz podstawowy DH jest ponownie używany tylko w przypadku używania statycznych szyfrów DH („DH-*”, np. „DH-RSA-AES256-SHA”). Luka nie występuje w OpenSSL 1.1.1, ponieważ ta gałąź nie wykorzystuje klucza podstawowego DH i nie używa statycznych szyfrów DH.

W przypadku korzystania z metody wymiany kluczy DH obie strony połączenia generują losowe klucze prywatne (zwane dalej kluczem „a” i kluczem „b”), na podstawie których wyliczane i wysyłane są klucze publiczne (ga mod p i gb mod p). Po otrzymaniu przez każdą ze stron kluczy publicznych wyliczany jest wspólny klucz podstawowy (gab mod p), który służy do generowania kluczy sesyjnych. Atak Raccoon umożliwia określenie klucza podstawowego poprzez analizę kanału bocznego w oparciu o fakt, że specyfikacje TLS aż do wersji 1.2 wymagają odrzucenia wszystkich wiodących bajtów zerowych klucza podstawowego przed obliczeniami z nim związanymi.

Wraz ze skróconym kluczem podstawowym przekazywany jest do funkcji generowania klucza sesyjnego, która opiera się na funkcjach skrótu o różnych opóźnieniach przy przetwarzaniu różnych danych. Dokładny pomiar czasu kluczowych operacji wykonywanych przez serwer pozwala atakującemu na ustalenie wskazówek (wyroczni), które pozwalają ocenić, czy klucz podstawowy zaczyna się od zera, czy nie. Na przykład osoba atakująca może przechwycić klucz publiczny (ga) wysłany przez klienta, przesłać go ponownie na serwer i określić
czy wynikowy klucz podstawowy zaczyna się od zera.

Samo zdefiniowanie jednego bajtu klucza nic nie daje, ale przechwytując wartość „ga” przekazywaną przez klienta podczas negocjacji połączenia, atakujący może wygenerować zestaw innych wartości związanych z „ga” i wysłać je do serwerem w oddzielnych sesjach negocjacji połączenia. Generując i wysyłając wartości „gri*ga”, atakujący może, analizując zmiany opóźnień w odpowiedzi serwera, określić wartości, które prowadzą do otrzymania kluczy podstawowych zaczynając od zera. Po określeniu takich wartości atakujący może utworzyć zestaw równań Rozwiązania problemy z ukrytymi numerami i obliczyć oryginalny klucz podstawowy.

Luka w TLS umożliwiająca określenie klucza dla połączeń w oparciu o szyfry DH

Luki w zabezpieczeniach OpenSSL przydzielony niski poziom zagrożenia, a poprawka ograniczyła się do przeniesienia problematycznych szyfrów „TLS_DH_*” w wersji 1.0.2w do kategorii szyfrów o niewystarczającym poziomie ochrony („weak-ssl-ciphers”), która jest domyślnie wyłączona . Twórcy Mozilli zrobili to samo, wyłączony w bibliotece NSS używanej w przeglądarce Firefox, zestawy szyfrów DH i DHE. W przeglądarce Firefox 78 problematyczne szyfry są wyłączone. Obsługa Chrome dla DH została przerwana w 2016 roku. Problem nie dotyczy bibliotek BearSSL, BoringSSL, Botan, Mbed TLS i s2n, ponieważ nie obsługują one szyfrów DH ani statycznych wariantów szyfrów DH.

Dodatkowe problemy są odnotowane osobno (CVE-2020-5929) w stosie TLS urządzeń F5 BIG-IP, dzięki czemu atak jest bardziej realistyczny. W szczególności zidentyfikowano odchylenia w zachowaniu urządzeń w obecności bajtu zerowego na początku klucza podstawowego, który można wykorzystać zamiast pomiaru dokładnego opóźnienia obliczeń.

Źródło: opennet.ru

Dodaj komentarz