Compromising the security of cryptographic keys via PuTTY with CVE-2024-31497

2024-04-17 00:08:00

CVE-2024-31497 has emerged as a critical security flaw affecting PuTTY, a widely used SSH and Telnet client, from versions 0.68 to 0.80, and all have now been confirmed to have a serious vulnerability that compromises the security of the cryptographic keys. This vulnerability revolves around the generation of biased ECDSA nonces, which could allow an attacker to recover NIST P-521 secret keys used by clients.

Vulnerability explained

The core of the problem lies in how ECDSA (Elliptic Curve Digital Signature Algorithm) nonces are generated within these versions of PuTTY. The nonces, which should be random to ensure the security of the cryptographic process, were found to be “highly biased.” This bias in the nonce generation process means that it does not provide the required cryptographic randomness, thus exposing private keys to possible recovery by malicious entities.

The specific target of this vulnerability is the NIST P-521 elliptic curve, a standard commonly used to protect sensitive communications. The flaw was detailed in several security and database advisories, which highlighted the risk that attackers could exploit this vulnerability to gain unauthorized access to encrypted communications.

CVE-2024-31497 has identified a critical security flaw in versions 0.68 to 0.80 of PuTTY, a popular SSH and Telnet client, specifically targeting its ECDSA nonce generation process. This vulnerability exposes the possibility for attackers to recover NIST P-521 secret keys, posing serious risks to encrypted communications.

The mechanism of the feat

The vulnerability arises from the way PuTTY generates ECDSA nonces. In cryptographic protocols, nonces (numbers used once) are crucial to ensure the security of the encryption process. Ideally, these should be unpredictable and randomly generated. However, in affected versions of PuTTY, ECDSA nonces were found to be “highly biased,” meaning they do not offer the randomness needed to securely encrypt data.

This bias in nonce generation makes it theoretically possible for an attacker with sufficient resources and access to encrypted communications to use statistical methods to infer the private key associated with a particular set of communications. Specifically, the bias could allow attackers to conduct a side-channel attack where they could deduce private keys after observing a large number of cryptographic operations.

To exploit this vulnerability, an attacker would need to intercept cryptographic operations performed by a victim using compromised versions of PuTTY. The attacker could then apply advanced cryptanalytic techniques to exploit the biased nonce values. This would involve complex mathematical calculations and possibly significant computational resources to effectively “guess” the private key through patterns observed in the biased nonces.

EXPLOITATION EXAMPLE OF CVE-2024-31497: SIMULATED ATTACK SCENARIO

To illustrate how CVE-2024-31497 could be exploited, let’s consider a hypothetical attack scenario:

Background of the scenario:

Alice is an administrator who uses PuTTY version 0.70 to manage remote servers for her organization. She connects to these servers using an SSH key pair, where the private key is secured on her local machine.

Step 1: Information Gathering

An attacker, Bob, discovers that Alice’s organization is still using a vulnerable version of PuTTY. He decides to target her to gain unauthorized access to the secure servers. Bob begins by intercepting Alice’s SSH sessions on the server. This is typically done through a network sniffer on a compromised network or through a man-in-the-middle attack.

Step 2: Intercept crypto operations

During each of Alice’s SSH sessions, Bob captures the encrypted data packets and focuses on extracting the ECDSA nonce values ​​used in the cryptographic operations. Since this data is skewed (due to the CVE-2024-31497 vulnerability), it does not vary as randomly as it should.

Step 3: Exploit the bias

Bob uses a custom-developed script to parse the captured nonces. The script uses statistical algorithms to detect patterns and irregularities in nonces that should be random. These patterns indicate the biased nature of nonce generation in PuTTY, making the private key more predictable.

Step 4: Decrypt the private key

Using the observed patterns, Bob applies a series of advanced mathematical calculations designed to reverse engineer Alice’s private key. This type of cryptanalysis exploits the inherent weaknesses of biased nonces, gradually reducing the possible values ​​of the private key.

Step 5 – Gain Unauthorized Access

Once Bob successfully deduces Alice’s private key, he uses it to authenticate to the SSH server as if he were Alice. He can now execute commands, access sensitive information and potentially plant more malware to maintain access or affect other parts of the network.

DIGITAL SIGNATURE EXPLOITATION MECHANISM IN SSH AND GIT

Creation and verification of digital signature:

• Digital signature creation: A digital signature is created using a user’s private key. This process involves signing data from the private key (in this case, a Git commit), which effectively “seals” the data with proof that it was signed by the holder of the private key.
• Digital signature verification: The corresponding public key, known to others, can be used to verify that the signing was performed using the matching private key without exposing the private key. This process confirms the identity of the user and guarantees the integrity and authenticity of the signed data.

EXPLOITATION EXPLAINED

Collection of signatures for exploitation:

• Via SSH server logs: If an attacker controls or compromises an SSH server, they can collect digital signatures generated during user logins. These signatures, when created using weak or compromised cryptographic methods, can be analyzed to reveal patterns or weaknesses.
• Via signed Git commits: A more practical approach, as mentioned, involves collecting signatures from signed Git commits. If Git is configured to use SSH keys to sign commits and these commits are pushed to a public repository (such as GitHub), anyone can easily access the signatures.

Exploitation of vulnerabilities in signature generation:

• In the context of PuTTY and Pageant, if there is a vulnerability in the way these tools generate signatures (such as the use of biased nonces as in CVE-2024-31497), an attacker can exploit this to deduce the private key used to sign .
• Private key calculation: Based on the information provided, attackers may need around 58 signatures to accurately calculate a target’s private key. This calculation is likely based on the ability to exploit flaws in the nonce generation process during signature creation.

SPECIFIC USE CASE: PUTTY AND PAGEANT WITH GIT

PuTTY and contest setup for Git:

• Setting: Users can configure Git to use Pageant as an SSH agent, where Pageant manages their SSH keys. When making Git commits, these commits are signed using the SSH key provided by Pageant.
• Vulnerability risk: If Pageant uses a version of PuTTY affected by CVE-2024-31497, the signatures it generates for Git commits could be vulnerable to exploitation, allowing attackers to recover the private key.

Implications of the feat

Recovery of NIST P-521 secret keys via this exploit could allow unauthorized parties to decrypt sensitive information, impersonate legitimate users, or conduct a variety of other malicious activities. Given the extensive use of PuTTY in managing secure communications for critical infrastructure, this vulnerability could have widespread implications, potentially affecting a wide range of sectors, including government, finance, and healthcare.

CVE-2024-31497 specifically affects PuTTY software versions 0.68 through 0.80. The vulnerability is tied to the implementation of the ECDSA nonce generation within these specific versions of PuTTY. As such, other software products are not directly affected by this CVE unless they somehow incorporate the same faulty code or similar nonce generation mechanisms that were used in PuTTY.

However, here’s a broader perspective on other types of software that could be affected by similar vulnerabilities:

SSH clients:

• Other SSH clients could also suffer similar vulnerabilities if they use flawed or biased ECDSA nonce generation methods. Users should ensure they use updated versions and apply patches regularly.

Cryptographic libraries:

• Libraries that implement ECDSA and other cryptographic algorithms could be vulnerable if they have similar problems with nonce generation. Examples include OpenSSL, Libgcrypt, and others that have previously had vulnerabilities related to cryptographic nonce handling.

Software VPN:

• VPNs that use custom or outdated cryptographic implementations may be vulnerable to similar problems if they do not use secure, random nonce generation methods in their cryptographic protocols.

Secure communication applications:

• Applications that facilitate the secure transmission of messages and data and that rely on ECDSA for encryption could be exposed if their nonce generation is biased or predictable.

Financial Transaction Systems:

• Systems that handle financial and e-commerce transactions that use ECDSA for transaction signing could be at risk if they inherit or do not properly implement secure nonce generation practices.

Best practices for prevention:

• Periodic updates and patches: It is essential to periodically update all software to the latest version. This not only applies to PuTTY but to all software that involves cryptographic operations.
• Security audits: Periodically perform security audits of the cryptographic practices and implementations used within your organization’s software stack.
• Vulnerability scanning: Use vulnerability scanners and penetration testing tools to identify and mitigate risks associated with cryptographic implementations.

By staying alert to updates related to cryptographic practices and implementing strong security measures, organizations can protect themselves against vulnerabilities similar to CVE-2024-31497 and protect the integrity and privacy of their data.

He is a well-known expert in mobile security and malware analysis. He studied Computer Science at NYU and started working as a cybersecurity analyst in 2003. He actively works as an antimalware expert. He also worked for security companies such as Kaspersky Lab. His daily work includes investigating new malware and cybersecurity incidents. He also has a deep level of knowledge in mobile security and mobile vulnerabilities.

Send news tips to [email protected] or www.instagram.com/iicsorg/

You can also find us on Telegram www.t.me/noticiasciberseguro