In SSH clients OpenSSH and PuTTY ( in PuTTY and in OpenSSH), leading to information leakage in the connection negotiation algorithm. The vulnerability allows an attacker who can intercept the client’s traffic (e.g., when a user connects through a wireless access point controlled by the attacker) to determine the client's initial connection attempt to the host when the host key has not yet been cached by the client.
Knowing that the client is trying to connect for the first time and does not yet have the host key on their side, the attacker can relay the connection through themselves (MITM) and present the client with their own host key, which the SSH client will consider the key of the target host if it does not verify the key fingerprint. Thus, the attacker can conduct a MITM attack without raising any suspicion from the user and ignore sessions where the client already has cached host keys, as attempting to spoof them would lead to a warning about the host key change. This attack relies on user complacency, not performing a manual verification of the host key fingerprint during the first connection. Those who check the key fingerprints are protected against such attacks.
The distinguishing feature for identifying the first connection attempt is the change in the order of listed supported host key algorithms. In the case of the first connection, the client sends the default list of algorithms, and if the host key is already cached, the associated algorithm is placed at the top (algorithms are sorted by preference).
The issue manifests in OpenSSH releases from 5.7 to 8.3 and in PuTTY from 0.68 to 0.73. The problem in the release by adding an option to disable dynamic construction of the host key algorithm list in favor of enumerating algorithms in a fixed order.
The OpenSSH project does not plan to change the behavior of the SSH client, as if the algorithm of the existing key is not specified first, there will be an attempt to apply a non-matching algorithm for the cached key with a warning about an unknown key. This means there’s a choice — either information leakage (OpenSSH and PuTTY), or warnings about the key change (Dropbear SSH) if the saved key does not match the first algorithm in the default list.
To ensure protection in OpenSSH, it is recommended to use alternative methods of host key verification using SSHFP records in DNSSEC and host certificates (PKI). It is also possible to disable adaptive selection of host key algorithms through the HostKeyAlgorithms option and use the UpdateHostKeys option to obtain additional host keys after client authentication.
Source: opennet.ru
