W klientach SSH OpenSSH i PuTTY ( w PuTTY i w OpenSSH), co prowadzi do wycieku informacji w algorytmie negocjacji połączenia. Ta podatność umożliwia atakującemu, który jest w stanie przechwycić ruch klienta (na przykład podczas łączenia użytkownika przez kontrolowany przez atakującego punkt dostępu Wi-Fi), zidentyfikowanie próby początkowego połączenia klienta z hostem, gdy klucz hosta nie został jeszcze zapisany w pamięci podręcznej klienta.
Wiedząc, że klient próbuje połączyć się po raz pierwszy i że nie ma jeszcze klucza hosta po swojej stronie, atakujący może przesłać połączenie przez siebie (MITM) i przedstawić klientowi swój klucz hosta, który klient SSH uzna za klucz docelowego hosta, jeśli nie przeprowadzi weryfikacji odcisku klucza. W ten sposób atakujący może zaaranżować MITM, nie wzbudzając podejrzeń u użytkownika i ignorując sesje, w których po stronie klienta znajdują się już zapisane klucze hostów, próba oszustwa w tych przypadkach doprowadzi do wyświetlenia ostrzeżenia o zmianie klucza hosta. Atak bazuje na naiwności użytkowników, którzy nie przeprowadzają ręcznej weryfikacji odcisku klucza hosta przy pierwszym połączeniu. Ci, którzy sprawdzają odciski kluczy, są chronieni przed tego rodzaju atakami.
W ramach oznaczenia służącego do określenia pierwszej próby połączenia używana jest zmiana kolejności wymieniania wspieranych algorytmów kluczy hosta. W przypadku gdy następuje pierwsze połączenie, klient przesyła domyślną listę algorytmów, a jeżeli klucz hosta jest już w pamięci podręcznej, to związany z nim algorytm jest umieszczany na pierwszym miejscu (algorytmy są sortowane według preferencji).
Problem występuje w wersjach OpenSSH od 5.7 do 8.3 oraz w PuTTY od 0.68 do 0.73. Problem w wersji przez dodanie opcji do wyłączenia dynamicznego budowania listy algorytmów przetwarzania kluczy hostów na rzecz stałej kolejności algorytmów.
Projekt OpenSSH nie planuje zmieniać działania klienta SSH, ponieważ, jeśli nie zostanie określony algorytm istniejącego klucza na pierwszym miejscu, nastąpi próba zastosowania nieodpowiadającego zbuforowanemu kluczowi algorytmu z wyświetleniem ostrzeżenia o nieznanym kluczu. Oznacza to, że istnieje wybór — albo wyciek informacji (OpenSSH i PuTTY), albo wyświetlanie ostrzeżeń o zmianie klucza (Dropbear SSH), jeśli zapisany klucz nie odpowiada pierwszemu algorytmowi na liście domyślnej.
Aby zapewnić bezpieczeństwo w OpenSSH, zaleca się użycie alternatywnych metod weryfikacji klucza hosta za pomocą rekordów SSHFP w DNSSEC oraz certyfikatów hosta (PKI). Można również wyłączyć adaptacyjny wybór algorytmów kluczy hostów za pomocą opcji HostKeyAlgorithms i skorzystać z opcji UpdateHostKeys, aby klient mógł uzyskać dodatkowe klucze hosta po uwierzytelnieniu.
Źródło: opennet.ru
