Return of the RCE: Addressing the regreSSHion Vulnerability – CVE-2024-6387

A Regrettable Resurgence

On July 1, 2024, the Qualys Threat Research Unit (TRU) published their discovery of an unauthenticated remote code execution (RCE) vulnerability in OpenSSH, a tool for secure remote connectivity using the Secure Shell (SSH) protocol. The bug, assigned CVE-2024-6387, is a regression of a previously patched vulnerability, impacting OpenSSH version 8.5p1 up to (but not including) 9.8p1, as well as unpatched versions older than 4.4p1.

The story of CVE-2024-6387 – dubbed “regreSSHion” – serves as an example of what can happen when a lapse in the essential process of software regression testing occurs. Regression testing is a common practice in software development. By comparing newly developed software to earlier versions prior to release, it prevents the resurgence of old mistakes that harm the software functionality or security – for example, software vulnerabilities that were previously discovered and fixed. In this case, a vulnerability first discovered over a decade ago (CVE-2006-5051) was reintroduced unnoticed in OpenSSH 8.5p1, which was released in October 2020.

The Impact of the regreSSHion Vulnerability

CVE-2024-6387 is concerning for two main reasons: its prevalence and its potential impact in case of exploitation.

First, OpenSSH is a broadly used implementation of the SSH protocol for secure networking, natively integrated in Windows, macOS, and most Linux operating systems. Many OpenSSH servers are connected to the Internet, typically for remote management and administration of systems, creating an external attack surface that exposes sensitive systems. According to Qualys, over 14 million OpenSSH server instances are exposed to the Internet, with approximately 700,000 of these being vulnerable to regreSSHion.

Second, while exploitation of the regreSSHion vulnerability is not trivial, it can be achieved remotely by an unauthenticated attacker. If exploited, the vulnerability allows the attacker to execute arbitrary code with root privileges on affected systems.

Exploitation can lead to severe consequences, including:

• Full System Compromise: An attacker can gain root access, allowing complete control over the system.
• Malware Injection: Malicious software can be inserted to run attacks such as ransomware on sensitive internal systems.
• Data Manipulation and Exfiltration: With root access, attackers can alter data, establish a command & control channel for data exfiltration, and create backdoors for persistent access.
• Lateral Movement: A compromised system can be used as a launchpad to attack other vulnerable systems within the network.

regreSSHion Vulnerability Exploitation: The Adversary Point of View

The SSH secure networking protocol is commonly used to provide protected access to sensitive corporate resources, making it a prime target for attackers. Although compromising vulnerable OpenSSH servers can yield significant rewards, the exploitation of regreSSHion is not trivial.

The regreSSHion vulnerability is exploited by taking advantage of a timing issue in the OpenSSH server software. When a client fails to log in within a defined time frame, the server tries to handle this by running certain functions. On vulnerable versions, these functions can be tricked into letting an attacker run their own code on the server with full control. Exploiting this vulnerability requires a high level of skill and persistence, as well as tools to repeatedly try the exploit on the vulnerable machine until it succeeds.

From an internal attack surface perspective, the threat of regreSSHion is diminished due to the time, effort and skill required to exploit it. Consistent exploit attempts of hours to days would create significant noise on the network, increasing the chance of detection by network traffic monitoring systems. Adversaries would most likely consider attempting this exploit for a sophisticated targeted attack. In such a scenario, they are likely to try other methods with a higher “value for effort” to achieve their goals.

From the external attack surface, it is significantly easier for attackers to run repeated exploit attempts, increasing the chance of success if a vulnerable OpenSSH server is accessible from the Internet. External-facing assets are constantly hit with incoming traffic from bots, making it easy for attackers to hide their actions. In addition, an adversary outside the organization’s network does not have the same time constraints that an internal attacker faces when trying to progress attacks while evading detection.

Mitigating the regreSSHion Vulnerability: Recommended Action

Validating the security of your SSH implementation is crucial due to the potential risk exposure if compromised by an adversary. We encourage security teams to use the emergence of regreSSHion as a driver for validating their overall SSH security posture.

The recommended actions are as follows:

1. Detect instances of OpenSSH in your environment, with a focus on instances that are accessible externally.
2. Eliminate unneeded external access to OpenSSH servers. As a best practice, connecting SSH servers to the public Internet should be avoided whenever possible, regardless of vulnerability to regreSSHion. It is recommended to place SSH servers behind firewalls and use VPNs or other secure methods to access them. In cases where direct Internet access is necessary, such as for cloud-based services or remote administration of dispersed systems, implementing strong access controls such as multi-factor authentication and regular monitoring can help mitigate the associated risks.
3. Identify instances of OpenSSH that are vulnerable to regreSSHion, and patch or mitigate them. If patching is not feasible, apply other types of mitigation described below as a first step.

Mitigation options include:

Software Patch

The most effective mitigation strategy is to apply the latest patches provided by OpenSSH. Specifically, OpenSSH should be updated to version 9.8p1 or later, which includes fixes for the regreSSHion vulnerability.

Configuration Changes

It is possible to reduce the likelihood of exploitation by modifying the LoginGraceTime  parameter in the sshd configuration file on vulnerable OpenSSH servers. Setting LoginGraceTime to 0 mitigates the risk of remote code execution but can result in denial-of-service (DoS).

Access Controls

Implementing access controls can help limit the exposure of SSH services. This includes:

• Firewall Rules: Restrict SSH access to only trusted IP addresses.
• Network Segmentation: Isolate critical systems and limit lateral movement within the network.
• Multi-Factor Authentication: Ensure access by authorized identities.

Monitoring and Detection

Deploying intrusion detection systems (IDS) and monitoring tools can help detect unusual activities indicative of exploitation attempts. High volumes of connection attempts or unusual process behavior can signal an ongoing attack.

Identify Exposure to regreSSHion with Pentera

Our customers can leverage Pentera’s attack surface monitoring capabilities today to locate vulnerable instances of OpenSSH in their environment.

We are currently working to automate detection and tracking of CVE-2024-6387 with Pentera.

Conclusion

In conclusion, while the regreSSHion vulnerability presents a real threat, it is not an easy target and requires significant expertise to exploit. This makes it unlikely to be exploited by amateur attackers or „script kiddies.“ Instead, it poses a higher risk for high-profile attacks, such as ransomware and data exfiltration, targeted at specific organizations. We strongly recommend that organizations use this situation as an opportunity to review and strengthen their SSH security practices, especially with regard to external-facing connections. Ensuring that all OpenSSH instances are promptly patched and following best security practices can significantly reduce the risk of exploitation.