CVSS 5.9 CVE-2020-14002

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

PuTTY 0.68 through 0.73 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).

Description

A vulnerability in Putty 0.68-0.73 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 sshhostkeys file (or any other decentralized local database) when connecting for the first time.

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-14002: Putty 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

Known Fingerprint

ssh-ed25519

ssh-rsa

ecdsa-sha2-nistp256

ssh-ed25519

ecdsa-sha2-nistp384

ecdsa-sha2-nistp256

ecdsa-sha2-nistp521

ecdsa-sha2-nistp384

ssh-rsa

ecdsa-sha2-nistp521

ssh-dss

ssh-dss

With no prior knowledge of the remote host the Putty 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.

Note

Putty 0.74 added a new config option to disable PuTTY’s dynamic host key preference policy, if you prefer to avoid giving away to eavesdroppers which hosts you have stored keys for.

Test with SSH-MITM

The check against CVE-2020-14002 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-14002: Client connecting for the FIRST time!

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

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

Mitigation

Update Putty to version 0.74 or greater and enable the new config option.

You can find this setting “Connections -> SSH -> Host keys”. Uncheck “Prefer algorithms for which a host key is known”

When this option is unchecked, ssh-mitm is not able to figure out, if the client has a stored fingerprint.

Reference