Sårbarhet i TLS som tillater nøkkelbestemmelse for tilkoblinger basert på DH-chiffer

Avslørt informasjon om det nye sårbarheter (CVE-2020-1968) i TLS-protokollen, kodenavn
Vaskebjørn og tillate, i sjeldne tilfeller, å bestemme en foreløpig primærnøkkel (pre-master), som kan brukes til å dekryptere TLS-forbindelser, inkludert HTTPS, ved avskjæring av transittrafikk (MITM). Det bemerkes at angrepet er svært vanskelig for praktisk gjennomføring og er mer av teoretisk karakter. For å utføre et angrep kreves det en spesifikk konfigurasjon av TLS-serveren og muligheten til å måle serverbehandlingstiden meget nøyaktig.

Problemet er tilstede direkte i TLS-spesifikasjonen og påvirker kun tilkoblinger som bruker chiffer basert på DH-nøkkelutvekslingsprotokollen (Diffie-Hellman, TLS_DH_*"). Med ECDH-chiffer oppstår ikke problemet, og de forblir sikre. Bare TLS-protokoller opp til versjon 1.2 er sårbare; TLS 1.3 påvirkes ikke av problemet. Sårbarheten oppstår i TLS-implementeringer som gjenbruker den hemmelige DH-nøkkelen på tvers av forskjellige TLS-tilkoblinger (denne oppførselen skjer på omtrent 4.4 % av Alexa Top 1M-servere).

I OpenSSL 1.0.2e og tidligere utgaver blir DH-primærnøkkelen gjenbrukt i alle servertilkoblinger med mindre alternativet SSL_OP_SINGLE_DH_USE er eksplisitt angitt. Siden OpenSSL 1.0.2f, blir DH-primærnøkkelen bare gjenbrukt ved bruk av statiske DH-chiffer ("DH-*", f.eks. "DH-RSA-AES256-SHA"). Sårbarheten vises ikke i OpenSSL 1.1.1, siden denne grenen ikke bruker en DH-primærnøkkel og ikke bruker statiske DH-chiffer.

Ved bruk av DH-nøkkelutvekslingsmetoden genererer begge sider av forbindelsen tilfeldige private nøkler (heretter nøkkel "a" og nøkkel "b"), basert på hvilke offentlige nøkler (ga mod p og gb mod p) beregnes og sendes. Etter at hver part mottar de offentlige nøklene, beregnes en felles primærnøkkel (gab mod p), som brukes til å generere øktnøkler. Raccoon-angrepet lar deg bestemme primærnøkkelen gjennom sidekanalanalyse, basert på det faktum at TLS-spesifikasjonene opp til versjon 1.2 krever at alle ledende nullbyte av primærnøkkelen forkastes før beregninger som involverer den.

Inkludering av den avkortede primærnøkkelen sendes til sesjonsnøkkelgenereringsfunksjonen, som er basert på hashfunksjoner med forskjellige forsinkelser ved behandling av forskjellige data. Nøyaktig måling av tidspunktet for nøkkeloperasjoner utført av serveren lar angriperen finne ledetråder (orakel) som gjør det mulig å bedømme om primærnøkkelen starter fra bunnen av eller ikke. For eksempel kan en angriper avskjære den offentlige nøkkelen (ga) sendt av klienten, overføre den til serveren og bestemme
om den resulterende primærnøkkelen starter fra null.

I seg selv gir det ikke noe å definere en byte av nøkkelen, men ved å avskjære "ga"-verdien som overføres av klienten under tilkoblingsforhandling, kan angriperen generere et sett med andre verdier assosiert med "ga" og sende dem til serveren i separate tilkoblingsforhandlingsøkter. Ved å generere og sende «gri*ga»-verdier kan en angriper, gjennom å analysere endringer i forsinkelser i serverresponsen, bestemme verdiene som fører til mottak av primærnøkler fra null. Etter å ha bestemt slike verdier, kan angriperen lage et sett med ligninger for løsninger problemer med skjulte tall og beregne den opprinnelige primærnøkkelen.

Sårbarhet i TLS som tillater nøkkelbestemmelse for tilkoblinger basert på DH-chiffer

OpenSSL-sårbarheter tildelt lavt farenivå, og rettelsen ble redusert til å flytte de problematiske chifferene "TLS_DH_*" i utgivelse 1.0.2w til kategorien chiffer med utilstrekkelig beskyttelsesnivå ("weak-ssl-ciphers"), som er deaktivert som standard . Mozilla-utviklerne gjorde det samme, slått av i NSS-biblioteket brukt i Firefox, DH- og DHE-chiffersuitene. Fra Firefox 78 er problematiske chiffer deaktivert. Chrome-støtte for DH ble avviklet tilbake i 2016. BearSSL-, BoringSSL-, Botan-, Mbed TLS- og s2n-bibliotekene er ikke berørt av problemet fordi de ikke støtter DH-chiffer eller statiske varianter av DH-chiffer.

Ytterligere problemer er notert separat (CVE-2020-5929) i TLS-stakken med F5 BIG-IP-enheter, noe som gjør angrepet mer realistisk. Spesielt er det identifisert avvik i oppførselen til enheter i nærvær av en null byte i begynnelsen av primærnøkkelen, som kan brukes i stedet for å måle den nøyaktige ventetiden til beregninger.

Kilde: opennet.ru

Legg til en kommentar