В SSH-клиентите OpenSSH и PuTTY ( в PuTTY и в OpenSSH), водеща до изтичане на информация при алгоритъма за съгласуване на връзката. Уязвимостта позволява на атакуващия, способен да прихване трафика на клиента (например, при свързване на потребителя през контролирана от атакуващия точка за достъп), да установи опит за първоначално свързване на клиента с хоста, когато ключът на хоста все още не е кеширан от клиента.
Знаейки, че клиентът се опитва да се свърже за първи път и все още не разполага със собствен ключ на хоста, атакуващият може да трансферира връзката през себе си (MITM) и да предостави на клиента своя ключ на хоста, който SSH-клиентът ще счита за ключ на целевия хост, освен ако не извърши проверка на отпечатъка на ключа. По този начин атакуващият може да организира MITM, без да предизвика подозрение у потребителя и да игнорира сесиите, при които от страната на клиента вече съществуват кеширани ключове на хостове, опит за подмяна на които ще предизвика предупреждение за промяна на ключа на хоста. Атаката се основава на безразличието на потребителите, които не извършват ръчна проверка на отпечатъка на ключа на хоста при първоначалното свързване. Тези, които проверяват отпечатъците на ключове, са защитени от подобни атаки.
Като признак за определяне на първата опит за свързване се използва промяна в реда на изброяване на поддържаните алгоритми за ключове на хоста. В случай че се извършва първоначално свързване, клиентът предава списък с алгоритми по подразбиране, а ако ключът на хоста вече е наличен в кеша, то свързаният с него алгоритъм се поставя на първо място (алгоритмите се сортират по предпочитание).
Проблемата се проявява в версиите на OpenSSH от 5.7 до 8.3 и в PuTTY от 0.68 до 0.73. Проблемът в изданието чрез добавяне на опция за деактивиране на динамичното изграждане на списъка с алгоритми за обработка на ключове на хоста в полза на изброяване на алгоритмите в постоянен ред.
Проектът OpenSSH не планира да променя поведението на SSH клиента, тъй като ако не е посочен алгоритъмът на съществуващия ключ на първо място, ще се опита да приложи неуместния за кеширания ключ алгоритъм, с предупреждение за неизвестен ключ. Т.е. възниква избор — или изтичане на информация (OpenSSH и PuTTY), или показване на предупреждения за смяна на ключа (Dropbear SSH) в случай, че запазеният ключ не съответства на първия алгоритъм в списъка по подразбиране.
За осигуряване на защита в OpenSSH се предлага да се използват алтернативни методи за проверка на ключа на хоста чрез записи SSHFP в DNSSEC и сертификати на хоста (PKI). Също така, можете да деактивирате адаптивния избор на алгоритми за хостови ключове чрез опцията HostKeyAlgorithms и да използвате опцията UpdateHostKeys за получаване на допълнителни ключове на хоста от клиента след автентикация.
Източник: opennet.ru
