Sårbarhet i TLS som tillåter nyckelbestämning för anslutningar baserade på DH-chiffer

Avslöjat information om det nya sårbarheter (CVE-2020-1968) i TLS-protokollet, kodnamn
Raccoon och tillåta, i sällsynta fall, att fastställa en preliminär primärnyckel (pre-master), som kan användas för att dekryptera TLS-anslutningar, inklusive HTTPS, vid avlyssning av transittrafik (MITM). Det noteras att attacken är mycket svår för praktiskt genomförande och är mer av teoretisk karaktär. För att utföra en attack krävs en specifik konfiguration av TLS-servern och förmågan att mycket exakt mäta serverns bearbetningstid.

Problemet finns direkt i TLS-specifikationen och påverkar endast anslutningar som använder chiffer baserade på DH-nyckelutbytesprotokollet (Diffie-Hellman, TLS_DH_*"). Med ECDH-chiffer uppstår inte problemet och de förblir säkra. Endast TLS-protokoll upp till version 1.2 är sårbara; TLS 1.3 påverkas inte av problemet. Sårbarheten uppstår i TLS-implementeringar som återanvänder den hemliga DH-nyckeln över olika TLS-anslutningar (detta beteende inträffar på cirka 4.4 % av Alexa Top 1M-servrarna).

I OpenSSL 1.0.2e och tidigare versioner återanvänds DH-primärnyckeln i alla serveranslutningar såvida inte alternativet SSL_OP_SINGLE_DH_USE är uttryckligen inställt. Sedan OpenSSL 1.0.2f återanvänds DH-primärnyckeln endast vid användning av statiska DH-chiffer ("DH-*", t.ex. "DH-RSA-AES256-SHA"). Sårbarheten visas inte i OpenSSL 1.1.1, eftersom den här grenen inte använder en DH-primärnyckel och inte använder statiska DH-chiffer.

När du använder DH-nyckelutbytesmetoden genererar båda sidor av anslutningen slumpmässiga privata nycklar (hädanefter nyckel "a" och nyckel "b"), baserat på vilka publika nycklar (ga mod p och gb mod p) beräknas och skickas. Efter att varje part tagit emot de publika nycklarna, beräknas en gemensam primärnyckel (gab mod p), som används för att generera sessionsnycklar. Raccoon-attacken låter dig bestämma primärnyckeln genom sidokanalanalys, baserat på det faktum att TLS-specifikationerna fram till version 1.2 kräver att alla ledande noll-bytes av primärnyckeln kasseras innan beräkningar som involverar den.

Inklusive den trunkerade primärnyckeln skickas till sessionsnyckelgenereringsfunktionen, som är baserad på hashfunktioner med olika fördröjningar vid bearbetning av olika data. Att noggrant mäta timingen av nyckeloperationer som utförs av servern gör att angriparen kan fastställa ledtrådar (oracle) som gör det möjligt att bedöma om primärnyckeln börjar från början eller inte. Till exempel kan en angripare fånga upp den publika nyckeln (ga) som skickas av klienten, återsända den till servern och fastställa
om den resulterande primärnyckeln börjar från noll.

Att definiera en byte av nyckeln ger i sig ingenting, men genom att fånga upp "ga"-värdet som överförs av klienten under anslutningsförhandling, kan angriparen generera en uppsättning andra värden associerade med "ga" och skicka dem till servern i separata anslutningsförhandlingssessioner. Genom att generera och skicka "gri*ga"-värden kan en angripare, genom att analysera förändringar i förseningar i serversvaret, bestämma de värden som leder till mottagning av primärnycklar från noll. Efter att ha bestämt sådana värden kan angriparen skapa en uppsättning ekvationer för lösningar dolda nummerproblem och beräkna den ursprungliga primärnyckeln.

Sårbarhet i TLS som tillåter nyckelbestämning för anslutningar baserade på DH-chiffer

OpenSSL-sårbarheter tilldelas låg risknivå, och korrigeringen reducerades till att flytta de problematiska chiffern “TLS_DH_*” i release 1.0.2w till kategorin chiffer med en otillräcklig skyddsnivå (”weak-ssl-ciphers”), som är inaktiverad som standard . Mozilla-utvecklarna gjorde samma sak, avstängd i NSS-biblioteket som används i Firefox, DH- och DHE-chiffersviterna. Från och med Firefox 78 är problematiska chiffer inaktiverade. Chrome-stöd för DH avbröts redan 2016. BearSSL, BoringSSL, Botan, Mbed TLS och s2n-biblioteken påverkas inte av problemet eftersom de inte stöder DH-chiffer eller statiska varianter av DH-chiffer.

Ytterligare problem noteras separat (CVE-2020-5929) i TLS-stacken av F5 BIG-IP-enheter, vilket gör attacken mer realistisk. I synnerhet har avvikelser i beteendet hos enheter i närvaro av en nollbyte i början av primärnyckeln identifierats, som kan användas istället för att mäta den exakta latensen av beräkningar.

Källa: opennet.ru

Lägg en kommentar