CVSS 5.9 CVE-2020-14145

CVSS 5.9 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

The client side in OpenSSH 5.7 through 8.6 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client).

Affected Software:

OpenSSH 5.7-8.6

integrated in SSH-MITM

Description

An information leak in OpenSSH <= 8.6 allows a man in the middle attack to determine, if a client already has prior knowledge of the remote hosts fingerprint.

Using this information leak it is possible to ignore clients, which will show an error message during an man in the middle attack, while new clients can be intercepted without alerting them of the man in the middle attack.

SSH Host Keys

According to RFC-4251, SSH clients keep track of trusted servers by verifying a fingerprint with the user, storing identity and public key material in the known_hosts file (or any other decentralized local database) when connecting for the first time.

Warning

The ssh trust on first use concept is an artifact dating back to a more simpler time. Then it was considered a definite step up to its counterparts in terms of security. Now it is frowned upon by many people who value their security dearly. With the now readily available Public Key Infrastructure (PKI) of the internet, there is no need to verify the identity of the server against fingerprints.

This way of handling trust can have multiple implications for an operating mitm server which is trying to audit ssh connections:

the mitm server wants the user to associate his public key with the identity of the actual remote host

OR if the remote host is already known

it wants to pass through the connection to the remote host and not alert the user of the mitm operation

CVE-2020-14145: OpenSSH Client Information Leak

Using this information leak a ssh server can figure out if a connecting client has prior knowledge of the remote hosts public key fingerprint during algorithm negotiations.

The reasoning behind this ability to extract information about client to server association lies in the algorithm negotiation itself. Particularly in the way the server_host_key_algorithms are sent. The official SSH Transport RFC 4253 requires each named list in the algorithm negotiation to make the first item a guessed preference. This is understandable for Key Exchange, Crypto or MAC algorithms but leads to exactly this information leak when also applied to the server_host_key_algorithms. This named list is used to negotiate which public key associated with the corresponding key generation algorithm should be used to authenticate the identity of the server.

Following comparison will make the described anomaly in question more clear:

New Fingerprint
server key:
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
rsa-sha2-512
rsa-sha2-256
ssh-rsa

Known Fingerprint
server key:
rsa-sha2-512
rsa-sha2-256
ssh-rsa
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519

Note

This is a shortened list of the actual output when using the default host key algorithms list.

With no prior knowledge of the remote host the OpenSSH Client will send a pre-defined default list of server host key algorithms to choose from. If the remote host is known i.e. an entry in the local database matches the remote, the key information of the entry will be used to change the order of the list being sent.

Knowing this a mitm server can simply compare the list of server host key algorithms to a default list and determine if the client is connecting for the first time or not, then process them accordingly.

OpenSSH 8.4 has implemented a patch that will not alter the named list of server host key algorithms if the default algorithm (ecdsa-sha2) is locally stored for the remote host, this can partially be worked around by not actively choosing that algorithm as option on the ssh server.

Test with SSH-MITM

The check against CVE-2020-14145 will be executed as soon, as a client connects.

When the client connects for the first time or the first time it will be show in the log output:

[INFO]  CVE-2020-14145: Client connecting for the FIRST time!

If a client has a already stored fingerprint, SSH-MITM will generate following log message:

[INFO]  CVE-2020-14145: Client has a locally cached remote fingerprint!

Response from Damien Miller

On 2021-05-27 Damien Miller answered a question in the OpenSSH Bugtracker , regarding this information leak.

Note

First, we consider the automatic ordering of host key algorithms an important feature for security. It provides continuity of trust by clients across changes in default algorithm preference in ssh and servers offering hostkeys of different types.

Disabling this feature wholesale would IMO result in a net loss of security as it would force more connections that already have learned a hostkey to accept a new one of a different algorithm, thereby needlessly exposing them to MITM risk.

That being said, commit b3855ff (shipped in openssh-8.4) adjusted the ordering to always use the default if the client has learned a hostkey matching the best-preference algorithm. openssh-8.5 enabled UpdateHostkeys by default (with some restrictions) so most users will automatically learn a best-preference hostkey if one is available at the server. Between these, most users should end up using the default algorithm list.

Speaking for myself - I plan to relax the restrictions around UpdateHostkeys’ activation, but do not plan to take other action around this “vulnerability”. In particular, I do not intend to offer an option to force the use of the default cipher list. IMO too many users would flip it thinking it solved a security problem when the situation is actually far more subtle and the reverse is likely the case.

Mitigation

Mitigation of this information leak is a risk assessment. As Damien Miller stated, due to changes in the order, a client could get another public key from the server, which might result in a key changed warning. Most SSH servers have different keys (RSA, elliptic curve, …) and the server will respond with your preferred algorithm.

If you want to mitigate the described behavior and you are aware of possible changing host keys due to different algorithms, there are two recommended methods:

Certificate based host key algorithms (recommended)

Using certificate based host key algorithms are not always possible, but they are the recommended way of mitigating this information leak.

According to research done by the FZI this will not alter the order of the server host key algorithms and therefore no information will be leaked.

Manually setting `HostKeyAlgorithms`

Warning: Only use this method, if the risk of the information leak is higher than the risk of accepting different fingerprints types.

When setting HostKeyAlgorithms as an ssh option manually this described anomaly will not occur because the given list of algorithms will always be used as-is. This can be used to mitigate the information leak.

You should use the default order matching your client version. If you use a default order with unknown algorithms, this could break your ssh client.

To get the client version, simply run: ssh -V

The default order four your ssh client version can be found in ssh-mitm/ssh-mitm