Researchers from the Qualys Threat Research Unit recently published details of their discovery of a critical vulnerability in OpenSSH’s server ‘sshd, ’ dubbed ‘regreSSHion’ and assigned the CVE-2024-6387 identifier.
The vulnerability affects the default configuration of certain sshd versions on glibc-based Linux systems. If exploited successfully, it allows an unauthenticated threat actor to achieve remote code execution (RCE) with root privileges.
What does this mean for my organization?
While Qualys has responsibly disclosed details of this vulnerability including a working exploit to OpenSSH, multiple third parties have been observed publishing their own proof-of-concept exploits, including tools to automate scanning for potentially vulnerable hosts.
Although currently time-consuming to exploit, the severity of this vulnerability is considered ‘high’ with a Common Vulnerability Scoring System (CVSS) v3.1 score of 8.1.
It is important to note that this vulnerability is currently exploitable on 32-bit Linux/glibc systems. Although exploitation on 64-bit systems has not been definitively proven, it is believed to be possible.
Given the severity of the vulnerability, all users of OpenSSH should familiarize themselves with how it works and mitigate the risk to their organizations.
How regreSSHion works
This recently identified vulnerability arises from a signal handler race condition present in specific versions of OpenSSH server (sshd) and is a regression of a previously patched denial-of-service vulnerability (CVE-2006-5051) from nearly two decades ago.
Although an initial fix addressed CVE-2006-5051 in September 2006, subsequent code changes appeared to reintroduce the vulnerability in the October 2020 release of OpenSSH version 8.5p1.
This vulnerability stems from how client authentication is handled by sshd and the subsequent asynchronous handling. When a client attempts to connect to sshd, the server waits for a specific duration, the ‘LoginGraceTime’.
During this period, the server determines if the client can successfully authenticate. If the client fails to authenticate within the specified time, an asynchronous signal handler ‘SIGALRM’ is triggered, allowing the server to perform other tasks.
In the case of vulnerable versions, the 'SIGALRM' signal handler calls an ‘async-signal-unsafe’ function, which does not behave well asynchronously and can introduce the race condition.
While exploiting the original vulnerability resulted in a denial-of-service attack, the latest discovery indicates that it could now lead to remote code execution as the ‘root’ user. This is because sshd runs privileged code with full permissions.
What versions of OpenSSH are vulnerable?
The following versions of OpenSSH are reportedly vulnerable:
- Versions v4.4p1 and earlier (unless patched for CVE-2006-5051 and/or CVE-2008-4109)
- Versions v8.5p1 to v9.8p1 (after the regression)
Versions between v4.4p1 and v8.5p1 are not vulnerable, as are installations on OpenBSD due to their use of an async-signal-safe version of syslog.
How are hackers scanning for regreSSHion?
The source code for multiple bulk scanner tools, specifically created to identify potentially vulnerable hosts, is readily available on popular code-sharing websites.
These tools are written in various programming languages, including Bash, PHP, Python and Rust, with most providing multi-threaded bulk scanning of domains, IP addresses, and entire network ranges. For those that use the popular network mapping utility ‘Nmap’, NSE (Nmap scripting engine) scripts to scan for this vulnerability have also been observed.
The scanner identifies potentially vulnerable OpenSSH versions based on their service banner when connecting to each target host (usually via port 22, the default SSH port). The retrieved banner is then either compared against a list of static strings or parsed using a regular expression pattern to determine the major, minor, and patch version.
For example, a banner like SSH-2.0-OpenSSH_8.5p1 would indicate a vulnerable version 8.5p1.
Most observed vulnerability scanners focus on versions between 8.5p1 and 9.7p1, as indicated by the provided banners in Appendix A. Some tools go beyond this range, identifying earlier vulnerable versions along with determining the operating system version for a more comprehensive result set.
Given the ease with which these tools can be developed and deployed, identifying potentially vulnerable hosts is straightforward and can easily be leveraged by threat actors equipped with exploit payloads.
How is regreSSHion exploited?
Much like the scanner tools, proof-of-concept exploits written in C and Python have been observed on popular code-sharing websites. As news of this vulnerability spreads, these proof of concepts will likely be improved upon in the coming days and weeks.
When targeting a potentially vulnerable host, the observed exploits typically follow these steps:
- Establish an SSH connection to the target server
- Perform the initial handshake
- Use heap spraying to send a sequence of packets that manipulate the server’s memory allocation patterns
- Measure the server response time to fine-tune the exploit timing
- Send a carefully timed packet to exploit the signal handler race condition
- Once successfully exploited, deliver a shellcode payload for privileged execution
Qualys reported that in their experiments, it took approximately 10,000 attempts to successfully “win” the race condition due to the need for precise timing.
Depending on the target host’s operating system and the server’s ‘LoginGraceTime’, this process could take hours or even days to achieve remote code execution. Once achieved, the consequences could be severe.
What are hackers saying about regreSSHion?
As expected, users of underground hacking forums have taken note of CVE-2024-6387 and conversations about potential collaborations to enhance existing proof-of-concept exploits have already begun.
While it remains uncertain whether these forum users have the ability to create an effective exploit, it is highly likely that high-sophistication threat actors are already working to leverage this vulnerability and add to their arsenals.
In addition to the freely available proof-of-concept (PoC) code, attackers have the opportunity to purchase a ‘working variant’ for a fraction of a Bitcoin.
Given the relatively low price, around $146, it is likely that these sales, along with similar ones, aim to capitalize on increased interest and take advantage of buyers rather than offering anything notably improved over the publicly available proof of concepts.
How can I stay protected?
Given the potential severity of this vulnerability being exploited in the coming day, consider the following to reduce the attack surface and mitigate the potential threat from this vulnerability:
- Patching/updating all vulnerable OpenSSH installations to ensure they are up-to-date
- Favor the use of key-based, rather than password-based, authentication to negate the need for the ‘LoginGraceTime’ period
- If using password-based authentication, reduce the ‘LoginGraceTime' to reduce the time in which a threat actor can attempt their exploit
Following security best practices can also help to blunt the impact of this attack, which includes:
- Monitoring logs for anomalous activity, in this instance SSH login failures and unexpected connections
- Use network segmentation to limit SSH host access to trusted networks
Identifying a vulnerable system
You can discover if you’re using vulnerable OpenSSH versions by checking the service banner. The following OpenSSH server service banners are indicative of vulnerable deployments and are targeted by many of the readily available bulk scanner tools:
- SSH-2.0-OpenSSH_8.5p1
- SSH-2.0-OpenSSH_8.6p1
- SSH-2.0-OpenSSH_8.7p1
- SSH-2.0-OpenSSH_8.8p1
- SSH-2.0-OpenSSH_8.9p1
- SSH-2.0-OpenSSH_9.0p1
- SSH-2.0-OpenSSH_9.1p1
- SSH-2.0-OpenSSH_9.2p1
- SSH-2.0-OpenSSH_9.3p1
- SSH-2.0-OpenSSH_9.4p1
- SSH-2.0-OpenSSH_9.5p1
- SSH-2.0-OpenSSH_9.6p1
- SSH-2.0-OpenSSH_9.7p1
