Are you struggling to find all the potentially compromised PuTTY SSH ECDSA NIST P-521 keys?

A critical vulnerability (CVE-2024-31497) was discovered some time ago in PuTTY SSH clients. Adversaries can exploit this vulnerability to recover the strongest ECDSA private keys (ECDSA NIST P-521 keys) to compromise authenticity in secure shell user authentication and other use cases where the vulnerable software has been used for signing. (You can find more technical details of the vulnerability here.)

Contents

How serious is the vulnerability?
Which SSH clients are affected?
Recommendations
How can SSH Communications Security help? 

How serious is the vulnerability? 

This is a critical vulnerability. An attacker may have the potential to perform supply-chain attacks on software maintained, for example, with Git, a widely used version control system. This vulnerability can also be exploited by an SSH server to which an unsuspecting user authenticates for remote login or secure file transfer.

Normally, the adversary would have no way of finding out the victim's private key. However, because of the vulnerable ECDSA NIST P-521 signature generation of the affected secure shell clients, determining the private key from a relatively small number of signatures is possible. What’s worse, the same compromised private key, that is in the possession of the user and often self-provisioned for remote access, can be exploited for unauthorized access very likely to multiple servers.

Which SSH clients are affected?  

• PuTTY versions from 0.68 to 0.80 

• FileZilla versions from 3.24.1 to 3.66.5 

• WinSCP versions from 5.9.5 to 6.3.2 

• TortoiseGit versions from 2.4.0.2 to 2.15.0 

• TortoiseSVN versions from 1.10.0 to 1.14.

Recommendations 

If you have ever used any of the vulnerable SSH client versions with an ECDSA NIST-P521 key, you cannot rely on the privacy of the compromised key. This is why it is not enough that users upgrade their software to a fixed version, but new keys should be created as well.

Also, administrators are strongly recommended to remove the authorization of potentially compromised keys. Any ECDSA NIST P-521 keys that may have been used with vulnerable SSH client versions, either directly or via vulnerable version of an authentication agent like Pagent, should be considered compromised – and be replaced.

A few weeks might be enough to update vulnerable PuTTY clients, but do you know where ECDSA NIST P-521 keys have been used and whether are they still authorized? 

How can SSH Communications Security help?

PuTTY is so popular that even if it is not an enterprise-grade SSH client, it can be found in all manner of critical infrastructure, both private and public. This is why it is important for organizations to be aware of and discover compromised ECDSA NIST P-521 keys.

As the inventors of the SSH protocol, it is important for us to raise overall SSH key infrastructure awareness in organizations. We did this already with the Terrapin vulnerability that was discovered about half a year ago.

Universal SSH Key Manager (UKM) for key discovery

Our UKM is an enterprise-grade key management solution for discovering, managing, and eliminating SSH keys. With our UKM, you can scan hosts in the environment to determine, for example: 

• The version of the currently installed PuTTY client 

• The type of keys found and their actual use for authorization 

• Additionally, UKM users can create a list of keys which are potentially vulnerable and act on those 

Tectia SSH Client for enterprise-grade use

If ECDSA keys are used in the environment, then chances are that there are compliance requirements that should be met. Our enterprise-grade Tectia SSH Client can be installed as a native application on a variety of platforms, including Windows, and it supports both plain ECDSA SSH user keys as well as X.509v3 certificates, for example, via MSCAPI or PKCS#11 interface from Hardware Security Modules, for example, government-issued Smart Cards. 

How to mitigate the risk with Tectia SSH Server 

To mitigate the vulnerable Secure Shell clients used in the environment that are not in your organization’s control, Tectia SSH Server 6.6 configuration can be changed by our professional services or customers themselves to: 

• either categorically deny connections if the Secure Shell client uses ecdsa-sha2-nistp521 for user public key authentication (system-wide or per group/user),

• or allow it but log it specifically,

• or require an additional authentication method or authorization if ecdsa-sha2-nistp521 is used.
  

Also, Tectia SSH Server can be configured to alert the user of vulnerable clients or potentially compromised key types upon authentication that they need to update their software and generate a new SSH key pair. Note that the Secure Shell client might not show the authentication phase banner message, or the connecting client itself might be updated but still use vulnerable software or compromised key via an authentication agent.

Or you could go keyless with Tectia Zero Trust 

For several years already, we have recommended passwordless and keyless authentication to targets. As great as our UKM technology is in taking back control and managing any number of SSH keys, we recommend our customers migrate to keyless, ephemeral access powered by PrivX. If a key doesn’t exist in the first place, it cannot be compromised.  

This is why our Tectia Zero Trust makes remote connections to targets without having to use SSH user keys at all. It establishes audited connections to the target just-in-time, using keyless authentication, leaving no keys to be misused by anyone.