CVE-2020-14145

CVE-2020-14145
5.9 CVSS
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N https://nvd.nist.gov/vuln/detail/CVE-2020-14145

integrated in SSH-MITM server

The client side in OpenSSH 5.7 through 8.4 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.4

Description

A vulnerability in OpenSSH <= 8.4 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 vulnerability 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.

Mitigation

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.

Another way of mitigating this information leak is to only accept certificate based host key algorithms. 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.