I SSH-klienter OpenSSH og PuTTY ( i PuTTY og i OpenSSH), hvilket fører til informationslækage i forbindelsesforhandlingsalgoritmen. Sårbarheden gør det muligt for en hacker, der er i stand til at opsnappe klienttrafik (f.eks. når en bruger opretter forbindelse gennem et angriberstyret trådløst adgangspunkt) at registrere et forsøg på indledningsvis at forbinde klienten med værten, når klienten endnu ikke har cachelagret værtsnøglen.
Ved at vide, at klienten forsøger at oprette forbindelse for første gang og endnu ikke har værtsnøglen på sin side, kan angriberen udsende forbindelsen gennem sig selv (MITM) og give klienten sin værtsnøgle, som SSH-klienten vil overveje at være nøglen til målværten, hvis den ikke bekræfter nøglefingeraftrykket. En angriber kan således organisere MITM uden at vække brugermistanke og ignorere sessioner, hvor klientsiden allerede har cachelagrede værtsnøgler, et forsøg på at erstatte, hvilket vil resultere i en advarsel om ændringen af værtsnøglen. Angrebet er baseret på skødesløshed hos brugere, der ikke manuelt kontrollerer værtsnøglens fingeraftryk, når de første gang opretter forbindelse. De, der kontrollerer nøglefingeraftryk, er beskyttet mod sådanne angreb.
Som et tegn på at bestemme det første forbindelsesforsøg, bruges en ændring i rækkefølgen af liste over understøttede værtsnøglealgoritmer. Hvis den første forbindelse opstår, sender klienten en liste over standardalgoritmer, og hvis værtsnøglen allerede er i cachen, sættes den tilknyttede algoritme på førstepladsen (algoritmerne er sorteret i præferencerækkefølge).
Problemet opstår i OpenSSH udgivelser 5.7 til 8.3 og PuTTY 0.68 til 0.73. Problem i spørgsmålet ved at tilføje en mulighed for at deaktivere den dynamiske konstruktion af en liste over værtsnøglebehandlingsalgoritmer til fordel for at liste algoritmerne i en konstant rækkefølge.
OpenSSH-projektet planlægger ikke at ændre adfærden for SSH-klienten, da hvis du ikke angiver algoritmen for den eksisterende nøgle i første omgang, vil der blive forsøgt at bruge en algoritme, der ikke svarer til den cachelagrede nøgle og en advarsel om en ukendt nøgle vil blive vist. De der. et valg opstår - enten informationslækage (OpenSSH og PuTTY), eller advarsler om ændring af nøglen (Dropbear SSH), hvis den gemte nøgle ikke svarer til den første algoritme i standardlisten.
For at give sikkerhed tilbyder OpenSSH alternative metoder til værtsnøglebekræftelse ved hjælp af SSHFP-indgange i DNSSEC og værtscertifikater (PKI). Du kan også deaktivere adaptivt valg af værtsnøglealgoritmer gennem indstillingen HostKeyAlgorithms og bruge indstillingen UpdateHostKeys for at give klienten mulighed for at få yderligere værtsnøgler efter godkendelse.
Kilde: opennet.ru