On July 1st, 2024, a vulnerability was discovered internally in OpenSSH, Secure Shell, a tool for secure file transfers, system management, and other communication via the Internet or other untrusted networks. The flaw, assigned with the ID CVE-2024-6387, allows an unauthenticated attacker to perform a remote code execution on the affected system and gain root privileges. The issue has a PoC but is yet to be actively exploited; despite this, some industry experts argue that this may reach the scale of WannaCry and Log4Shell. This is due to the affected component being sshd – and particularly the server of OpenSSH – which is incorporated with a large number of IoT devices, firewalls, and most OS systems.
The vulnerability: CVE-2024-6387
Codenamed regreSSHion, this CVE is a remote code execution (RCE) vulnerability present in the OpenSSH server component, known as sshd. In its default configuration, it was developed to watch for connections from other client applications.
This vulnerability is not considered to be of critical severity, having received a CVSS score of 8.1; however, due to the depth and breadth of OpenSSH’s reach and integration in most operating systems, it is likely to affect numerous organizations. The number of possibly vulnerable OpenSSH server instances exceeds 14 million (as per Censys and Shodan searches) with Qualys already having reported approximately 700,000 such instances to be already exposed. Moreover, flaws in many other products might be exposed from this primary vulnerability.
Successful exploitation can grant the unauthenticated attacker root privileges, potentially leading to a full system compromise. Although a successful exploitation would have devastating consequences, given its complexity and the highly specific information the attacker would need to obtain before the exploitation attempt, it is rather unlikely.
It is interesting to note that the OpenSSH team resolved this issue back in 2006, and at the time it was allocated an ID CVE-2006-5051. As a result, the new bug is a regression—the recurrence of a previously known flaw because of some code modifications, that accidentally bring back the issue. This is where the new vulnerability’s term, regreSSHion, originates from. This case emphasizes how important it is to do extensive regression testing to stop known flaws from being introduced back into the system.
Possible exploitations
As mentioned above, a successful attempt to exploit this flaw could have disastrous consequences. The attacker could perform a complete system takeover, which, among other things, would enable malware installation and data manipulation, and establish a permanent backdoor. Given the number of instances that could potentially be at risk, it creates a global catastrophe.
Luckily, immediate exploitation is unlikely, even with a published proof of concept. Because the flaw has been found and disclosed to the vendor, instead of a malicious course of action, it has been immediately patched. Moreover, each exploit effort is a highly complex and time-consuming endeavor. Per each server, approximately 10,000 authentication attempts with standard OpenSSH settings are required for successful exploitation. And that would last six to eight hours for just one attack to be successfully carried out. What makes it even more complicated is the condition that the attacker must know which version of Linux the server is running. That makes it even less likely to be a mass exploitation target. Nonetheless, it is possible to utilize this flaw, most likely with some deep learning advancements or a very patient and persistent attacker.
Current solutions
CVE-2024-6387 affects OpenSSH versions 8.5p1 through 9.7p1. Additionally, versions prior to 4.4p1 are impacted unless they have been previously patched when CVE-2006-5051 and CVE-2008-4109 were published. Users are recommended to upgrade to the latest version, which is 9.8p1 as of now. Noteworthy, all OpenBSD systems are unaffected, given the security mechanism that blocks the flaw within.
If an immediate upgrade is not possible for some reason, it is recommended that administrators set the login timeout to zero (LoginGraceTime=0 in sshd_config) as a temporary mitigation. The drawback of this approach, however, is that it makes the SSH server more prone to a DDoS attack. Another method of mitigating this flaw is to implement stricter access control for SSH, which can be done by applying firewalls or other security tools.
How can Skybox Help?
The Skybox Research Lab added the vulnerability to our threat intelligence feed the day after it was made public. Its status in the feed was adjusted with the discovery that the proof of concept (PoC) has been published.
Skybox customers who have OpenSSH integrated in their network can use the vulnerability discovery features of the Skybox Vulnerability and Threat Management solution to find the vulnerability in their environment. If alerting is configured, they will also be notified of the number of vulnerability occurrences within their organization and the degree of exposure of each asset to the relevant attack vector. If patching is not imminent, Skybox suggests compensating security measures, including network segmentation or configuration modifications, to reduce exposure risk on the customer’s network.
To help the organization’s security team decide how best to protect itself, a customized risk score and a prioritization of the most critical threats will also be provided. These will be based on the significance of OpenSSH in the organizational network as well as other factors, such as the overall CVSS score for CVE-2024-6387.
Skybox’s threat intelligence team will keep a close eye on any updates about this flaw and update the threat intelligence feed – and affected customers – with any information that may be useful for making risk management decisions.
Learn how Skybox proactively protects you from vulnerabilities like the one affecting OpenSSH.
