У SSH-кліентах OpenSSH і PuTTY ( у PuTTY і у OpenSSH), якая прыводзіць да ўцечкі звестак у алгарытме ўзгаднення злучэння. Уразлівасць дазваляе атакаваламу, здольнаму перахапіць трафік кліента (напрыклад, пры падлучэнні карыстача праз кантраляваную атакавалым кропку бесправаднога доступу), вызначыць спробу першапачатковага падлучэння кліента да хаста, калі кліентам яшчэ не пракэшаваны ключ хаста.
Ведаючы, што кліент спрабуе падлучыцца ў першы раз і яшчэ не мае на сваім боку ключ хаста, атакавалы можа трансляваць злучэнне праз сябе (MITM) і выдаць кліенту свой хаставы ключ, які SSH-кліент палічыць ключом мэтавага хаста, калі не выканае зверку адбітка ключа . Такім чынам, атакавалы можа арганізаваць MITM не выклікаўшы падазроны ў карыстача і ігнараваць сеансы, у якіх на боку кліента ўжо маюцца пракэшаваныя ключы хастоў, спроба падмены якіх прывядзе да высновы папярэджання аб змене ключа хаста. Атака будуецца на бестурботнасці карыстальнікаў, якія не выконваюць ручную праверку fingerprint-адбітка ключа хаста пры першым падключэнні. Тыя хто правяраюць адбіткі ключоў ад падобных нападаў абаронены.
У якасці прыкметы для вызначэння першай спробы падлучэння выкарыстоўваецца змена парадку пераліку падтрымліваемых алгарытмаў хостовых ключоў. У выпадку калі адбываецца першае падлучэнне кліент перадае спіс алгарытмаў па змаўчанні, а калі ключ хаста ўжо маецца ў кэшы, то злучаны з ім алгарытм выстаўляецца на першае месца (алгарытмы сартуюцца ў парадку перавагі).
Праблема выяўляецца ў выпусках з OpenSSH з 5.7 па 8.3 і ў PuTTY з 0.68 па 0.73. Праблема у выпуску праз даданне опцыі для адключэння дынамічнай пабудовы спісу алгарытмаў апрацоўкі хостовых ключоў у карысць пераліку алгарытмаў у пастаянным парадку.
Праект OpenSSH не плануе змяняць паводзіны SSH-кліента, бо калі не паказаць алгарытм наяўнага ключа на першым месцы, будзе ўжытая спроба ўжывання не які адпавядае прокэшированному ключу алгарытму з высновай папярэджання аб невядомым ключы. Г.зн. узнікае выбар - альбо ўцечка інфармацыі (OpenSSH і PuTTY), альбо выснова папярэджанняў аб змене ключа (Dropbear SSH) у выпадку, калі захаваны ключ не адпавядае першаму алгарытму ў спісе па змаўчанні.
Для забеспячэння абароны ў OpenSSH прапануецца выкарыстоўваць альтэрнатыўныя спосабы праверкі ключа хаста пры дапамозе запісаў SSHFP у DNSSEC і сертыфікатаў хаста (PKI). Таксама можна адключыць адаптыўны выбар алгарытмаў хостовых ключоў праз опцыю HostKeyAlgorithms і выкарыстоўваць опцыю UpdateHostKeys для атрымання кліентам дадатковых ключоў хаста пасля аўтэнтыфікацыі.
Крыніца: opennet.ru