A new Vulnerability affecting OpenSSH, regression, with CVE identifier CVE-2024-6387 (named RegreSSHion), has been discovered, and wide exploitation is possible; in the article, we’ll explore the impact, the likelihood of this to happen and how to tackle external system upgrades with ASPM technologies quickly. This vulnerability affects OpenSSH, a widely used suite of secure networking utilities based on the Secure Shell (SSH) protocol. In this article, we delve into the details of CVE-2024-6387, its impact, the complexities involved in its exploitation, and how organizations can mitigate the associated risks.
The challenge of this vulnerability is that it could potentially impact tens of thousands of software being very popular ssh components and embedded in glibc.
“The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems,” Bharat Jogi, senior director of the threat research unit at Qualys
Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with [address space layout randomization],” OpenSSH said in an advisory. “Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept.”
Key points about CVE-2024-6387:
- Vulnerability: Remote Unauthenticated Code Execution (CVE-2024-6387)
- Affected: OpenSSH 8.5p1 to 9.8p1
- Architecture: Primary PoC for 32-bit (x86), 64-bit (amd64) theoretically vulnerable
- Systems: glibc-based Linux distributions
- Impact: Root-level access if exploited
- Complexity: High (requires precise timing, multiple attempts)
- Status: Patch available (OpenSSH 9.8p1)
Note:
Qualys describes the vulnerability as highly complex to exploit, requiring an average of around 10,000 exploitation attempts to succeed.
under ideal conditions, you can perform about 5 attempts per minute, so 10,000 attempts would take around 1.4 days. This is also in a lab environment where network lag is negligible, as is SSH background noise. On a real internet-connected system experiencing network jitter and being blasted by SSH scanners, exploitation could take significantly longer. From a link in Mark Hutchins
What Does OpenSSH Stand For?
OpenSSH stands for Open Secure Shell. It is an open-source implementation of the SSH protocol, which provides encrypted communication sessions over unsecured networks. OpenSSH includes a set of secure networking utilities designed to offer robust encryption, secure file transfers, and secure remote logins, making it an essential tool for administrators and developers managing servers and networked systems.
What is OpenSSH Vulnerability?
An OpenSSH vulnerability refers to a security flaw found within the OpenSSH software that can be exploited by attackers to compromise system security. The regreSSHion vulnerability (CVE-2024-6387) is a prime example. It is a signal handler race condition in the OpenSSH server component (sshd), allowing unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems. This makes it a critical threat, as it could potentially allow attackers to gain full control over affected systems.
What is the Difference Between SSH and OpenSSH in RegreSSHion?
SSH, or Secure Shell, is a protocol used to secure remote logins and other network services over an unsecured network. OpenSSH is an open-source implementation of the SSH protocol, providing a suite of tools that include SSH clients and servers, as well as utilities for secure file transfers and other secure network operations. While SSH is the protocol itself, OpenSSH is a widely used implementation of that protocol.
Where is OpenSSH Used?
OpenSSH is used in a variety of environments to ensure secure communication and data transfer. It is commonly deployed for remote server management, secure file transfers, automated backups, and batch processing. OpenSSH’s robust security features and flexibility make it a cornerstone in DevOps practices, where secure handling of sensitive data across multiple systems and locations is crucial.
What is Regression? Why CVE-2024-6387 has been named RegreSSHion?
In software development, regression refers to the reappearance of a previously fixed bug or vulnerability in a subsequent software release. This can occur due to changes or updates that inadvertently reintroduce the issue. The regreSSHion vulnerability is a regression of the previously patched CVE-2006-5051, highlighting the importance of thorough regression testing to prevent known vulnerabilities from re-entering the environment. ASPM technologies helps identify new and older version by cataloguing the version of the library
What Systems Are Affected?
The regreSSHion vulnerability affects glibc-based Linux systems running vulnerable versions of OpenSSH. Specifically, it impacts versions from 8.5p1 to 9.7p1. Versions earlier than 4.4p1 are also vulnerable unless they have been patched for both CVE-2006-5051 and CVE-2008-4109. Notably, OpenBSD systems are unaffected due to a security mechanism implemented in 2001. ASPM technologies helps scaling remediation efforts
Are There Exploits for CVE-2024-6387?
When it comes to cybersecurity, understanding the exploitation potential of a vulnerability is crucial. The regreSSHion vulnerability, identified as CVE-2024-6387, is no exception. This section delves into the existence and complexity of exploits for this vulnerability, shedding light on the practical challenge potential attackers face.
Proof-of-Concept (PoC) for CVE-2024-6387
As of the latest update, a Proof-of-Concept (PoC) for CVE-2024-6387 exists. This PoC targets certain i386 (32-bit) versions of OpenSSH where the GNU C Library (glibc) is at a static base address. This scenario bypasses Address Space Layout Randomization (ASLR), a security feature that randomizes memory addresses to make exploitation more difficult. In systems where ASLR is not bypassed, the complexity and time required to exploit the vulnerability increase significantly. ASPM technologies and Phoenix cyber intelligence helps identify when a vulnerability is weaponized or is in a PoC state
How to remediate CVE-2024-6387?
With Phoenix security, you can search for active campaign
How to identify CVE-2024-6387?
We amended some of the script to identify the vulnerable version and to output the vulnerabilities that can be imported into Phoenix Security
https://github.com/Security-Phoenix-demo/CVE-2024-6387_Check_phoenix_Security
Scanning for CVE-20246387 can be simple, and there are at least a couple of scripts that enable the identification of the vulnerability
You can import the vulnerable file:
Other options are
- https://github.com/Security-Phoenix-demo/CVE-2024-6387_Check_phoenix_Security
- https://github.com/xaitax/CVE-2024-6387_Check
Exploitation Complexity CVE-2024-6387
Qualys’ whitepaper highlights the high complexity involved in exploiting CVE-2024-6387. Under lab conditions, it took an average of around 10,000 exploitation attempts to succeed. Several factors contribute to this complexity:
- Login Timeout: The exploitation process is restricted by the login timeout setting, which ranges between 120 to 600 seconds.
- Concurrent Connections: OpenSSH typically allows a maximum of 10 concurrent unauthenticated connections.
- Exploitation Rate: Under ideal conditions, this setup permits about five attempts per minute. Thus, achieving 10,000 attempts would take approximately 1.4 days.
These conditions are based on an ideal lab environment with negligible network lag and minimal SSH background noise. In real-world scenarios, factors such as network jitter and interference from SSH scanners could extend the exploitation timeframe significantly.
How many systems are exposed to CVE-2024-6387
Qualys’ whitepaper highlights the high complexity involved in exploiting CVE-2024-6387. Under lab conditions, it took an average of around 10,000 exploitation attempts to succeed. Several factors contribute to this complexity.
Currently, there are around 61,800 openssh exposed systems according to shodan
Shadowserver has observed a higher number of them, with the count reaching ~4.5M hosts possibly vulnerable 2024-07-02 (out of over 23.5M seen), while the number is high there is no active exploitation at the moment and the exploitability requirement are still high
Advanced Exploitation TechniquesCVE-2024-6387
While the PoC provides a starting point, successful exploitation of CVE-2024-6387 in a real-world environment is challenging. Attackers would need to:
- Overcome ASLR: On modern systems (x86_64 / AMD64), ASLR significantly complicates the exploitation process. Predicting memory addresses becomes a game of chance, reducing the probability of success with each attempt.
- Handle Network Latency: Real-world networks introduce latency and jitter, making precise timing of exploitation attempts more difficult.
- Mitigate Background Noise: The presence of legitimate and illegitimate SSH traffic can obscure exploitation attempts, requiring additional measures to isolate and execute the attack.
Realistic Threat Assessment
Given these complexities, it is unlikely that CVE-2024-6387 will see widespread in-the-wild exploitation similar to other high-severity vulnerabilities. However, the possibility remains that sophisticated attackers could develop more efficient methods over time. Organizations must remain vigilant and prioritize patching and other mitigations to protect against potential exploitation.
Update (2024-07-01 11:09 PST)
The recent update notes that while there is a PoC for i386 systems, the estimated exploitation time is based on these older systems. For newer systems running x86_64 / AMD64, exploitation would take significantly longer due to the necessity of overcoming ASLR. This further reduces the likelihood of mass exploitation but does not eliminate the risk entirely.
Mitigation Strategies
To mitigate the risks associated with CVE-2024-6387, organizations should:
- Apply Patches Promptly: Ensure that all systems running vulnerable versions of OpenSSH are updated to the latest secure versions.
- Limit SSH Access: Use network-based controls to restrict SSH access to trusted IP addresses and employ VPNs where possible.
- Implement Network Segmentation: Separate critical systems from less secure parts of the network to limit the potential impact of a successful exploit.
- Monitor and Alert: Deploy and configure intrusion detection and prevention systems to detect and alert on exploitation attempts.
How Could I Discover If I’m Affected by CVE-2024-6387?
To determine if you are affected by CVE-2024-6387, you should check the version of OpenSSH running on your systems. If your version falls within the vulnerable range (8.5p1 to 9.7p1, or earlier than 4.4p1 without patches), you are at risk. Vulnerability scanning solutions like Qualys or Phoenix security external scanners can help you stay updated.
What Version of OpenSSH is Vulnerable to CVE-2024-6387?
The versions of OpenSSH vulnerable to CVE-2024-6387 are from 8.5p1 up to, but not including, 9.8p1. Versions earlier than 4.4p1 are also vulnerable unless patched for CVE-2006-5051 and CVE-2008-4109. Ensuring your OpenSSH installation is updated beyond these versions is critical to mitigate the risk.
The Complexity of Exploiting CVE-2024-6387
According to Qualys’ whitepaper, exploiting CVE-2024-6387 is highly complex. It requires an average of around 10,000 exploitation attempts to succeed under lab conditions. The number of attempts is restricted by the login timeout setting (120-600 seconds) and the maximum concurrent unauthenticated connections (10). Under ideal conditions, you can perform about five attempts per minute, so 10,000 attempts would take around 1.4 days. This estimate assumes a lab environment with negligible network lag and minimal SSH background noise. In real-world scenarios, with network jitter and interference from SSH scanners, exploitation could take significantly longer.
Update (2024-07-01 11:09 PST)
There does appear to be a proof-of-concept (PoC) for certain i386 (32-bit) versions of OpenSSH where glibc is at a static base address, eliminating the need for an ASLR bypass. Since the estimated exploitation time is based on i386, it can be assumed that newer systems (those running x86_64 / AMD64) would take significantly longer to exploit due to the need for an ASLR bypass. While it’s entirely possible that attackers find ways to optimize the exploit further, given the complexity and time commitment, it’s unlikely we would see the same kind of massive in-the-wild exploitation observed with other vulnerabilities of similar severity.
The Impact of regreSSHion
The impact of the regreSSHion vulnerability is far-reaching, given the widespread use of OpenSSH. A successful exploit could lead to a full system compromise, allowing attackers to execute arbitrary code with root privileges. This could result in a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access. Moreover, an exploited system could be used as a foothold to traverse and exploit other vulnerable systems within an organization, facilitating network propagation.
Qualys’ findings indicate that there are no less than 14 million potentially vulnerable OpenSSH server instances exposed to the internet, with around 700,000 of these being external internet-facing instances. This highlights the significant risk posed by the regreSSHion vulnerability and underscores the importance of timely patching and robust security practices.
Mitigating the Risks of regreSSHion
To mitigate the risks associated with CVE-2024-6387, organizations should take several key steps:
- Patch Management: Apply the latest patches for OpenSSH immediately. Ensuring that your OpenSSH installation is updated beyond the vulnerable versions is crucial to mitigate the risk of regression vulnerability, even if it is marginal. ASPM technologies with campaigns of remediation can help with scaling
- Access Control: Limit SSH access through network-based controls. Restricting SSH access to trusted IP addresses and using VPNs can help reduce the attack surface.
- Network Segmentation: Implement network segmentation to restrict unauthorized access and lateral movement. Separating critical systems from less secure parts of the network can limit the impact of a successful exploit.
- Monitoring and Alerting: Deploy intrusion detection and prevention systems to monitor for unusual activities indicative of exploitation attempts. Timely alerts can help administrators respond swiftly to potential threats.
How Phoenix Security ASPM Can Help
Phoenix Security offers comprehensive solutions to help organizations focus on the vulnerabilities that matter most by adopting a risk-based prioritization approach. Here’s how Phoenix can assist:
- Likelihood of Exploitation: Assess the likelihood of exploitation based on various factors, prioritising high-risk vulnerabilities.
- Actual Chances of Exploitability Using EPSS Scores: Utilize Exploit Prediction Scoring System (EPSS) scores to determine the actual chances of exploitability, enabling better prioritization of remediation efforts.
- Threat Intelligence: Leverage threat intelligence to stay informed about emerging threats and vulnerabilities like PoC in github (current status of RegreSSHion), evidence of exploitation and weaponization to enhance ASPM technologies
- Internal/External Exploitation: Consider both internal and external exploitation vectors to provide a holistic view of the risk landscape.
- Verified Sources of Exploitation: Use verified sources of exploitation, such as CISA KEV and Metasploit, to confirm the presence and severity of vulnerabilities. ASPM Technologies help identify the vulnerabilities faster
- Business Impact and Consequences of Vulnerability: Evaluate the business impact and consequences of vulnerabilities to ensure that remediation efforts align with organizational priorities.
Phoenix Security ASPM helps organizations move towards a risk-based approach, focusing on the 1% of vulnerabilities that matter most instead of a reactive approach. Organizations can significantly enhance their security posture and mitigate potential threats by prioritising vulnerabilities based on actual risk and impact.
Conclusion
The regreSSHion vulnerability (CVE-2024-6387) in OpenSSH underscores the importance of rigorous security practices and timely patch management. The risks are significant with millions of potentially vulnerable instances exposed to the internet. However, organisations can mitigate these risks and protect their critical assets by understanding the complexity of exploitation, implementing security measures, and leveraging solutions like those offered by Phoenix Security ASPM.
For more detailed information on the regreSSHion vulnerability, you can read the articles on SC Magazine, The Hacker News, and explore the concepts of exploitability and top exploited vulnerabilities on Phoenix Security and Phoenix Security Tag: Top Exploited
How Phoenix Security Can Help
Phoenix Security helps organizations identify and trace which systems have vulnerabilities, understanding the relation between code and cloud. One of the significant challenges in securing applications is knowing where and how frameworks like OpenSSH are used. ASPM tools can scan the application portfolio to identify instances of OpenSSH, mapping out where it is deployed across the organization. This information is crucial for targeted security measures and efficient patch management. Phoenix Security’s robust Application Security Posture Management (ASPM) system is adept at not just managing, but preempting the exploitation of vulnerabilities through its automated identification system. This system prioritises critical vulnerabilities, ensuring that teams can address the most pressing threats first, optimising resource allocation and remediation efforts.
The Role of Application Security Posture Management (ASPM):
ASPM plays a vital role in managing and securing applications like those built with OpenSSH. It involves continuous assessment, monitoring, and improvement of the security posture of applications. ASPM tools can:
- Identify and Track OpenSSH Components: Locate where OpenSSH is implemented within the application infrastructure.
- Vulnerability Management: Detect known vulnerabilities in OpenSSH and prioritize them for remediation.
- Configuration Monitoring: Ensure OpenSSH configurations adhere to best security practices
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.
