I SSH-klienter OpenSSH og PuTTY ( i PuTTY og i OpenSSH), som fører til informasjonslekkasje i algoritmen for tilkoblingsforhandling. Sårbarheten lar en angriper som er i stand til å avskjære klienttrafikk (for eksempel når en bruker kobler seg til gjennom et angriperkontrollert trådløst tilgangspunkt) oppdage et forsøk på å koble klienten til verten i utgangspunktet når klienten ennå ikke har bufret vertsnøkkelen.
Ved å vite at klienten prøver å koble seg til for første gang og ennå ikke har vertsnøkkelen på sin side, kan angriperen kringkaste tilkoblingen gjennom seg selv (MITM) og gi klienten sin vertsnøkkel, som SSH-klienten vil vurdere å være nøkkelen til målverten hvis den ikke bekrefter nøkkelfingeravtrykket. Dermed kan en angriper organisere MITM uten å vekke brukermistanke og ignorere sesjoner der klientsiden allerede har bufrede vertsnøkler, et forsøk på å erstatte som vil resultere i en advarsel om endring av vertsnøkkelen. Angrepet er basert på uforsiktighet til brukere som ikke manuelt sjekker fingeravtrykket til vertsnøkkelen når de først kobler til. De som sjekker nøkkelfingeravtrykk er beskyttet mot slike angrep.
Som et tegn for å bestemme det første tilkoblingsforsøket, brukes en endring i rekkefølgen på listestøttede vertsnøkkelalgoritmer. Hvis den første tilkoblingen oppstår, sender klienten en liste over standardalgoritmer, og hvis vertsnøkkelen allerede er i hurtigbufferen, settes den tilknyttede algoritmen på første plass (algoritmene er sortert i preferanserekkefølge).
Problemet dukker opp i OpenSSH utgivelser 5.7 til 8.3 og PuTTY 0.68 til 0.73. Problem i saken ved å legge til et alternativ for å deaktivere den dynamiske konstruksjonen av en liste over vertsnøkkelbehandlingsalgoritmer til fordel for å liste algoritmene i en konstant rekkefølge.
OpenSSH-prosjektet planlegger ikke å endre oppførselen til SSH-klienten, siden hvis du ikke spesifiserer algoritmen til den eksisterende nøkkelen i utgangspunktet, vil det bli forsøkt å bruke en algoritme som ikke samsvarer med den hurtigbufrede nøkkelen og en advarsel om en ukjent nøkkel vil vises. De. et valg oppstår - enten informasjonslekkasje (OpenSSH og PuTTY), eller advarsler om endring av nøkkel (Dropbear SSH) hvis den lagrede nøkkelen ikke samsvarer med den første algoritmen i standardlisten.
For å gi sikkerhet tilbyr OpenSSH alternative metoder for vertsnøkkelverifisering ved å bruke SSHFP-oppføringer i DNSSEC og vertssertifikater (PKI). Du kan også deaktivere adaptivt utvalg av vertsnøkkelalgoritmer gjennom HostKeyAlgorithms-alternativet og bruke UpdateHostKeys-alternativet for å la klienten få flere vertsnøkler etter autentisering.
Kilde: opennet.ru