I SSH-klienterne OpenSSH og PuTTY ( i PuTTY og i OpenSSH), der fører til lækage af information i forbindelse med forbindelsens forhandlingsalgoritme. Sårbarheden tillader en angriber, der er i stand til at opsnappe klientens trafik (for eksempel når en bruger tilslutter sig via et trådløst adgangspunkt kontrolleret af angriberen), at identificere den oprindelige forbindelse, som klienten forsøger at etablere til værten, når klienten endnu ikke har cachet værtsnøglen.
Ved at vide, at klienten forsøger at oprette forbindelse for første gang og endnu ikke har værtsnøglen, kan angriberen lede forbindelsen gennem sig selv (MITM) og præsentere sin egen værtsnøgle, som SSH-klienten vil anse for at være målhostens nøgle, medmindre der udføres en kontrol af nøglefingeraftrykket. Dette muliggør, at angriberen kan udføre en MITM uden at vække brugerens mistanke og ignorere sessioner, hvor klienten allerede har cachet værtsnøgler, hvis forsøg på at ændre dem vil resultere i en advarsel om ændring af værtsnøglen. Angrebet er baseret på brugernes uforsigtighed, idet de ikke udfører manuel kontrol af værtsnøglefingeraftrykket ved første forbindelse. De, der kontrollerer fingeraftryk, er beskyttet mod sådanne angreb.
Som et tegn til at identificere den første forbindelse anvendes rækkefølgen af de understøttede algoritmer for værtsnøgler. Hvis det er den første forbindelse, sender klienten som standard en liste over algoritmer, og hvis værtsnøglen allerede er i cachen, placeres den tilknyttede algoritme øverst (algoritmer sorteres efter præference).
Problemet optræder i versioner af OpenSSH fra 5.7 til 8.3 og i PuTTY fra 0.68 til 0.73. Problemet i versionen gennem tilføjelse af muligheden for at deaktivere den dynamiske oprettelse af lister over algoritmer til behandling af værtsnøgler til fordel for en konstant rækkefølge af algoritmer.
OpenSSH-projektet har ikke planer om at ændre adfærden for SSH-klienten, da hvis algoritmen for den eksisterende nøgle ikke angives først, vil der blive forsøgt at anvende en algoritme, der ikke svarer til den cachede nøgle, hvilket resulterer i en advarsel om en ukendt nøgle. Det vil sige, der opstår et valg — enten informationslækage (OpenSSH og PuTTY) eller advarsler om nøgleændringer (Dropbear SSH), hvis den gemte nøgle ikke svarer til den første algoritme på listen som standard.
For at sikre beskyttelse i OpenSSH anbefales det at bruge alternative metoder til at kontrollere værtsnøglen ved hjælp af SSHFP-poster i DNSSEC og værtscertifikater (PKI). Det er også muligt at deaktivere den adaptive valg af algoritmer til værtsnøgler via indstillingen HostKeyAlgorithms og bruge indstillingen UpdateHostKeys til at få ekstra værtsnøgler efter autentificeringen.
Kilde: opennet.ru
