CVE-2024-6387: RegreSSHion Vulnerability in OpenSSH

Introduction

On July 1, 2024, the cybersecurity community was alerted to a significant vulnerability within OpenSSH, dubbed “regreSSHion” (CVE-2024-6387). This critical flaw, discovered by the Qualys Threat Research Unit (TRU), allows unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems. The vulnerability, which affects the default configuration of OpenSSH’s server (sshd), poses a severe security risk due to its potential for complete system compromise without user interaction.

What is regreSSHion?

regreSSHion
Credit: Qualys

RegreSSHion, tracked as CVE-2024-6387, is an unauthenticated RCE vulnerability in OpenSSH’s server (sshd). This flaw grants attackers full root access, making it a high-severity threat with a CVSS score of 8.1. The vulnerability affects versions 8.5p1 to 9.8p1 of OpenSSH, as well as versions earlier than 4.4p1 if not patched for previous vulnerabilities (CVE-2006-5051 and CVE-2008-4109). The issue arises from a signal handler race condition that can be exploited by failing to authenticate within a set time period (LoginGraceTime).

Background and Discovery

The Qualys TRU discovered that this vulnerability is a regression of a previously patched flaw, CVE-2006-5051, reported 18 years ago. A regression in this context means that a previously fixed issue has reappeared in a subsequent software release. This often occurs due to changes that inadvertently reintroduce the problem. The regression was introduced in October 2020 with OpenSSH version 8.5p1, highlighting the importance of thorough regression testing to prevent the reintroduction of known vulnerabilities.

Technical Details

The vulnerability involves a specific sequence of function calls and interactions between the signal handler and the main program logic. Here’s a breakdown of the critical components:

Function Call Chain:

  • __localtime64_r calls __tz_convert.
  • __tz_convert calls tzset_internal.
  • tzset_internal calls __tzfile_read.

Heap Allocation Issues:

  • __tzfile_read involves a call to fopen to read timezone files.
  • fopen allocates a FILE structure on the heap.

Exploit Strategy:

  • The attacker exploits the race condition by manipulating heap memory.
  • By carefully timing the SIGALRM signal, they can interrupt the malloc operation, leaving the heap in an inconsistent state.
  • This allows the attacker to control the FILE structure, leading to arbitrary code execution.

Impact and Exploitation Process

The regreSSHion vulnerability impacts glibc-based Linux systems running vulnerable versions of OpenSSH. Exploitation of this flaw can result in complete system takeover, allowing attackers to execute arbitrary code with root privileges. The attacker leverages the predictable heap layout and timing to achieve arbitrary code execution:

Heap Layout Manipulation:

  • The attacker creates a specific heap layout with controlled memory holes.
  • They send a series of crafted public-key packets to OpenSSH, forcing specific malloc and free operations.

Signal Timing:

  • The attacker sends a SIGALRM signal at a precise moment during the malloc operation.
  • This interrupts the malloc, leaving the heap in a vulnerable state.

Arbitrary Code Execution:

  • By overwriting parts of the FILE structure, the attacker redirects execution to their controlled function pointers.
  • This allows them to execute arbitrary code with the privileges of the OpenSSH process.

While successful exploitation has been demonstrated under lab conditions, it typically requires 6-8 hours of continuous connections. This makes mass exploitation challenging but not impossible.

Affected Versions

The vulnerability affects the following OpenSSH versions:

  • OpenSSH versions earlier than 4.4p1, if not patched for CVE-2006-5051 or CVE-2008-4109
  • OpenSSH versions from 8.5p1 up to, but not including, 9.8p1
Credit – PaloAlto

OpenBSD systems are not vulnerable due to their use of an async-signal-safe version of syslog(), which mitigates the race condition.

Mitigation and Recommendations

To protect against the regreSSHion vulnerability, it is recommended to:

  1. Update OpenSSH: Upgrade to the latest version, which is 9.8p1 or later.
  2. Network Controls: Limit SSH access through network-based controls to restrict unauthorised access.
  3. Micro Segmentation : Products like XShield by ColorTokens help in segmenting critical servers and containing access to them based on policies & detection of anomalies.

Workarounds

If you cannot apply the patch immediately, consider the following workarounds:

  1. Configuration Change:
    • Set LoginGraceTime to 0 in the OpenSSH configuration file. This eliminates the vulnerable window but may lead to denial of service by exhausting all available connections.
  2. Code Modification:
    • Temporarily comment out or remove the async-signal-unsafe code from the sshsigdie function in OpenSSH source code and recompile.

Current Status and Observations

As of July 2, 2024, there is no known activity in the wild exploiting this vulnerability. While proof-of-concept (PoC) code exists, it has not been successfully used to achieve remote code execution in testing environments. However, the potential for targeted attacks remains, and organizations are urged to apply patches and implement mitigation promptly.

Conclusion

The regreSSHion vulnerability in OpenSSH (CVE-2024-6387) underscores the critical need for rigorous regression testing and prompt security updates. By understanding the nature of this threat and taking proactive measures, organizations can mitigate the risks associated with this severe vulnerability and protect their systems from potential exploitation.

Stay informed and vigilant, and ensure your systems are updated to safeguard against this and other emerging cybersecurity threats.

Read More

Qualys Technical Paper

PuTTY Vulnerability Exposes Private Keys

Introduction: Understanding the PuTTY Vulnerability

PuTTY, a widely-used SSH and Telnet client, contains a critical vulnerability, tracked as CVE-2024-31497, affecting versions 0.68 through 0.80. This flaw allows threat actors to potentially recover private keys used for cryptographic signatures, posing significant security risks. 

Exploring the Vulnerability: How Attackers Exploit PuTTY

The vulnerability arises from the biased generation of ECDSA nonces for the NIST P-521 curve, used in SSH authentication. Attackers can leverage this flaw to recover private keys by collecting cryptographic signatures, enabling unauthorised access to SSH servers or the ability to sign commits masquerading as legitimate users.

PuTTY Vulnerability Exposes Private Keys

Expert’s Insights

“PuTTY’s technique worked by making a SHA-512 hash and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY’s technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later), it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.”

“In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.”

-PuTTY security advisory.

Impact and Implications: Risks Posed by the Flaw

The exploitation of this vulnerability can lead to severe consequences, including unauthorised access to sensitive systems, data breaches, and potential supply chain attacks. Affected software includes FileZilla, WinSCP, TortoiseGit, and TortoiseSVN, urging users to take immediate action.

The following software that uses the vulnerable PuTTY is confirmed as impacted:

  • FileZilla 3.24.1 – 3.66.5 (fixed in 3.67.0)
  • WinSCP 5.9.5 – 6.3.2 (fixed in 6.3.3)
  • TortoiseGit 2.4.0.2 – 2.15.0 (fixed in 2.15.0.1)
  • TortoiseSVN 1.10.0 – 1.14.6 (mitigation possible by configuring TortoiseSVN to use Plink from the latest PuTTY 0.81 release)

Mitigation and Resolution: Steps to Address the Vulnerability

In light of the vulnurability, users are advised do the following:

  1. Improved Randomness: Enhance the randomness of nonce generation by integrating a more robust cryptographic random number generator (RNG). This ensures nonces with sufficient entropy to prevent bias and enhances overall security.
  2. Different Hashing Algorithm: Consider utilising a different hashing algorithm or a combination of algorithms suitable for the NIST P-521 curve. Selecting a hash function compatible with curve parameters can mitigate bias introduced by modulo “q” reduction.
  3. Nonce Generation Scheme: Implement a nonce generation scheme independent of reducing the hash value modulo “q.” Develop a method to directly produce nonces within the defined range of “q” to preserve randomness and prevent bias.
  4. Comprehensive Review: Conduct a thorough review of the nonce generation process and cryptographic operations in PuTTY. Collaborate with security experts to identify and address any additional vulnerabilities or weaknesses, ensuring the fix is robust and effective.
  5. Update and Patch: Once a fix is developed, PuTTY would release a patch. Encourage users to upgrade to the latest version promptly to mitigate the vulnerability and enhance the security of their SSH connections.

Conclusion: Ensuring Security in SSH Environments

The PuTTY vulnerability underscores the importance of robust security measures in SSH environments. By staying informed and implementing necessary updates and precautions, organizations can bolster their defence against potential threats.

Read Also

Unveiling Terrapin: A New Threat to SSH Security

Unveiling Terrapin: A New Threat to SSH Security

SSH (Secure Shell) has long been hailed as a reliable protocol for secure network access, widely used for remote terminal logins and file transfers. However, the fortress of secure online connections now faces a dilemma – the Terrapin attack. In this blog, we delve into the intricacies of Terrapin, its potential impact on existing password-based authentication systems, and how organizations can safeguard against this insidious attack. Ready to plunge into the chaos? Buckle up, and let’s explore!

Understanding Terrapin

Terrapin is not your average security vulnerability; it’s a prefix truncation attack specifically designed to exploit weaknesses in the SSH protocol. By manipulating sequence numbers during the handshake process, an attacker can selectively remove messages from the beginning of the secure channel without detection. Imagine a hacker manipulating the building blocks of your messages, pulling them out one by one without you even batting an eye!

The Attack in Action

The Terrapin attack is not just theoretical; it has real-world implications. Attackers can downgrade connection security by truncating essential messages, such as the extension negotiation message (RFC8308). This truncation can lead to the use of less secure client authentication algorithms and the deactivation of specific countermeasures in OpenSSH 9.5.

The vulnerability has been assigned following CVEs

  • CVE-2023-48795 (CVSSv3 : 5.9 MEDIUM) – General Protocol Flaw
  • CVE-2023-46445 (CVSSv3 : 5.9 MEDIUM) – Rogue Extension Negotiation Attack in AsyncSSH
  • CVE-2023-46446 (CVSSv3 : 6.8 MEDIUM) – Rogue Session Attack in AsyncSSH

Downsides for Password-Based Authentication

Password-based authentication systems are particularly vulnerable to the Terrapin attack. The attack allows an adversary to compromise the integrity of the secure channel, potentially leading to unauthorized access and exploitation of implementation flaws. Picture this: attackers downgrade your connection security by snipping crucial messages. Your passwords might be waltzing into the wrong hands. This could result in attackers signing victims into other accounts without detection, paving the way for sophisticated phishing attacks. Just beware that Terrapin’s not a party crasher; it’s the DJ changing the beats!

Mitigating the Threat

To perform the Terrapin attack, a Man-in-the-Middle attacker is required, along with a cozy spot in local networks, making it challenging on the open internet. However, within local networks, where MITM attacks are plausible, the threat becomes more significant. Furthermore, the attack focuses on SSH connections that use widely adopted encryption modes like ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.

Vulnerability Scanner

To assist organizations in determining vulnerability, a simple console application is developed in Go. This tool helps identify if an SSH server or client is susceptible to the Terrapin attack based on the offered encryption modes and support for strict key exchange countermeasures.

Conclusion: A Safer Alternative at PureID

With Certificate-based authentication, the risk of MITM is mitigated as certificates are bound with IP addresses. Any man-in-the middle will not be able to replay the client certificate, manipulate the handshake & successfully establish TLS connection.

PureID’s ZITA (Just in Time Access) fully eliminates the risk of Terrapin along with any MITM attack. This approach, unlike outdated password-based systems, stands resilient against Terrapin. As the threat landscape evolves, prioritizing advanced authentication mechanisms becomes paramount for ensuring a secure network environment. Forget passwords; they’re so yesterday! Join the secure squad – it’s the future!