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:
If a client has a already stored fingerprint, SSH-MITM will generate following log message:
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.