Chyba zabezpečení v TLS umožňující určení klíče pro připojení na základě DH šifer

Odhaleno informace o novém zranitelnosti (CVE-2020-1968) v protokolu TLS s kódovým označením
Mýval a umožňující, ve vzácných případech, určit předběžný primární klíč (pre-master), který lze použít k dešifrování TLS spojení, včetně HTTPS, při zachycování tranzitního provozu (MITM). Je třeba poznamenat, že útok je velmi obtížný pro praktickou realizaci a je spíše teoretického charakteru. K provedení útoku je nutná specifická konfigurace TLS serveru a schopnost velmi přesně měřit dobu zpracování serveru.

Problém je přítomen přímo ve specifikaci TLS a týká se pouze připojení pomocí šifer založených na protokolu výměny klíčů DH (Diffie-Hellman, TLS_DH_*"). U šifer ECDH k problému nedochází a šifry zůstávají bezpečné. Zranitelné jsou pouze protokoly TLS do verze 1.2, TLS 1.3 se problém netýká. K této chybě zabezpečení dochází v implementacích TLS, které opakovaně používají tajný klíč DH napříč různými připojeními TLS (k tomuto chování dochází na přibližně 4.4 % serverů Alexa Top 1M).

V OpenSSL 1.0.2e a dřívějších verzích je primární klíč DH znovu použit ve všech připojeních k serveru, pokud není explicitně nastavena možnost SSL_OP_SINGLE_DH_USE. Od OpenSSL 1.0.2f je primární klíč DH znovu použit pouze při použití statických DH šifer ("DH-*", např. "DH-RSA-AES256-SHA"). Tato chyba zabezpečení se v OpenSSL 1.1.1 neobjevuje, protože tato větev nepoužívá primární klíč DH a nepoužívá statické šifry DH.

Při použití metody výměny DH klíčů obě strany spojení generují náhodné soukromé klíče (dále klíč „a“ a klíč „b“), na základě kterých jsou vypočítány a odeslány veřejné klíče (ga mod p a gb mod p). Poté, co každá strana obdrží veřejné klíče, je vypočítán společný primární klíč (gab mod p), který se používá ke generování klíčů relace. Útok Raccoon vám umožňuje určit primární klíč pomocí analýzy postranních kanálů na základě skutečnosti, že specifikace TLS až do verze 1.2 vyžadují, aby všechny úvodní prázdné bajty primárního klíče byly před výpočty, které se ho týkají, zahozeny.

Včetně zkráceného primárního klíče je předáno funkci generování klíče relace, která je založena na hashovacích funkcích s různým zpožděním při zpracování různých dat. Přesné měření načasování klíčových operací prováděných serverem umožňuje útočníkovi určit stopy (věštec), které umožňují posoudit, zda primární klíč začíná od nuly nebo ne. Útočník by například mohl zachytit veřejný klíč (ga) zaslaný klientem, znovu jej přenést na server a určit
zda výsledný primární klíč začíná od nuly.

Definování jednoho bajtu klíče samo o sobě nic nedává, ale zachycením hodnoty „ga“ přenášené klientem během vyjednávání o připojení může útočník vygenerovat sadu dalších hodnot spojených s „ga“ a odeslat je server v samostatných relacích vyjednávání o připojení. Generováním a odesíláním hodnot „gri*ga“ může útočník pomocí analýzy změn zpoždění v odpovědi serveru určit hodnoty, které vedou k příjmu primárních klíčů počínaje nulou. Po určení takových hodnot může útočník vytvořit sadu rovnic pro řešení skryté problémy s čísly a vypočítat původní primární klíč.

Chyba zabezpečení v TLS umožňující určení klíče pro připojení na základě DH šifer

Chyby zabezpečení OpenSSL přiděleno nízká úroveň nebezpečí a oprava byla omezena na přesunutí problematických šifer „TLS_DH_*“ ve verzi 1.0.2w do kategorie šifer s nedostatečnou úrovní ochrany („slabé-ssl-šifry“), která je ve výchozím nastavení zakázána . Vývojáři Mozilly udělali to samé, vypnutý v knihovně NSS používané ve Firefoxu, šifrovacích sadách DH a DHE. Od Firefoxu 78 jsou problematické šifry zakázány. Podpora Chrome pro DH byla ukončena již v roce 2016. Knihovny BearSSL, BoringSSL, Botan, Mbed TLS a s2n nejsou tímto problémem ovlivněny, protože nepodporují DH šifry ani statické varianty DH šifer.

Další problémy jsou uvedeny samostatně (CVE-2020-5929) v zásobníku TLS zařízení F5 BIG-IP, díky čemuž je útok realističtější. Zejména byly identifikovány odchylky v chování zařízení v přítomnosti nulového bytu na začátku primárního klíče, které lze použít místo měření přesné latence výpočtů.

Zdroj: opennet.ru

Přidat komentář