With growing concern over the recently disclosed regreSSHion vulnerability, we’re explaining here what it is, why it’s so significant, what it could mean for your cloud environment and how Tenable Cloud Security can help.

The newly discovered CVE-2024-6387 vulnerability in OpenSSH, named “regreSSHion,” is a critical remote code execution (RCE) flaw resulting from a race condition. Exploiting this vulnerability allows attackers to remotely execute arbitrary code on affected systems, potentially gaining complete control over them. This flaw was introduced into the OpenSSH server code via bad input validation, which can be exploited by sending specially crafted requests. Successful exploitation could lead to unauthorized access, data breaches and potential disruption of services.

Read on to learn how this vulnerability could impact your cloud environments and how Tenable Cloud Security can help.

OpenSSH enables secure remote management of cloud-based servers and services, as well as traditional infrastructure. It enables encrypted communication channels, which are essential for data transmitted between administrators and cloud infrastructure. 

Given its role in managing cloud resources across platforms like AWS, Azure and GCP, and given its popularity, it’s mandatory to ensure the security of OpenSSH. Thus, a vulnerability in this common tool could have widespread implications, such as affecting multiple cloud deployments and potentially exposing sensitive information stored in those servers.

In cloud environments, it’s unfortunately too easy to deploy such vulnerable machines at a huge scale. All it takes is provisioning your virtual machines by selecting a machine image with a vulnerable version of the software package, and even if you patch it in time. As a result, you could potentially have many of machines vulnerable from the time of their inception until the point they were patched. 

In addition, virtual machines in cloud environments can and usually have service identities attached to them allowing them access to other cloud resources. Executing code on these machines by a malicious actor typically allows abusing and leveraging the permissions of these service identities to access additional resources in the environment or move laterally. 

The vulnerability affects OpenSSH versions earlier than 4.4p1 unless patched for CVE-2006-5051 and CVE-2008-4109. Versions from 4.4p1 up to, but not including, 8.5p1 are secure. However, the vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1. This issue is relevant across multiple operating systems, including various Unix and Linux distributions, and even Windows.

The vulnerability was discovered by Qualys researchers and responsibly disclosed, which reduces the chances of immediate exploitation. Additionally, exploiting the vulnerability typically requires around 10,000 authentication attempts, which would take six to eight hours per server with standard OpenSSH settings. Moreover, the complexity of the attack and the need for knowledge of the server’s Linux version, combined with protections against brute force and DDoS attacks, make mass exploitation less likely. 

Despite this, our recommendation is to update your OpenSSH versions as soon as possible to remove this exposure. 

But it doesn’t stop there. 

There are a few additional security lessons – which are generally considered best practices – that can be emphasized by learning about this vulnerability.

First of all, you should apply proper segmentation of your networks, specifically limiting access to port 22 (ingress SSH) in machines. This may sound trivial, but you’d be surprised how many machines we run into “in the wild” which are accessible from pretty much anywhere at port 22, significantly increasing the risk of being compromised. 

In addition – and this applies to cloud environments specifically – this is yet another reminder of the importance of applying the principle of least privilege for identities in general and service identities in particular. If a vulnerability like regreSSHion is exploited by an attacker, allowing them to execute remote code on it, the attacker effectively gets access to all the permissions granted to the service identity that machine uses to access cloud resources, such as data stores or even other computing resources. Limiting permissions to the bare minimum required is essential to restricting the fallout from such a breach. 

Finally, it’s interesting to note that well over three years passed between the release of version 8.5p1 of OpenSSH (which introduced the exposure to regreSSHion) at the beginning of March 2021 and the release of version 9.8p1, just now in July of 2024.

It’s interesting not just because it indicates the sheer extent of exposure to this vulnerability. Rather, the lengthy period between the exposure introduction and the release of the patch means that even if patched now, some machines may have been exposed for a long time to remote code execution. 

Therefore, you should apply proper scrutiny to fully analyze the risk posed to your environment during this time. This means you need to be able to easily investigate not just the network exposure and access management of the vulnerable machines, but also what was their activity in your cloud environment. Being prepared to quickly analyze so many configurations and logs at scale could be a challenge for any organization using tools that offer only basic functionality, either provided by cloud service providers or developed in-house.

Tenable Cloud Security brings one of the most trusted, pioneering and mature brands in vulnerability management to your cloud environment. 

Tenable Cloud Security analyzes your security posture, network configurations, identities and access management and many other aspects of your cloud environment. It also scans your workloads for exposure to vulnerabilities in order to find security gaps and even toxic combinations made up of several of these domains put together. 

Combining vulnerability exposure insight with deep, cutting edge analysis of your cloud infrastructure is crucial to accomplish the kind of analysis we described in the previous section. 

Let’s see how it works. 

When looking for exposure to the vulnerability, you can easily find where it’s at: 

Now, since Tenable Cloud Security doesn’t just scan your workloads for vulnerabilities but also inspects their configurations, you can easily filter the results and look for ones that have a network configuration exposing them to either a wide range of IPs or even the entire internet: 

Looking further, you can use Tenable Cloud Security’s identity and access management analysis to focus on machines with critical risk caused by their service identities:

This can help you focus your attention on the machines with the highest risk of being targeted by attackers to cause serious damage. 

You should, of course, attend to any machine that may be at risk, but as we all know, prioritization is crucial to making the most of the often limited resources you have at your disposal to secure your cloud environment. 

Next, as you look into each machine, you can easily see whether its network exposure includes port 22 from its network graph: 

You can also see a detailed graph of the permissions granted to the service identity used by the machine, so you can easily explore what kind of resources were at risk of a potential compromise of the machine. This information is also available in list view.

Finally, in AWS, Tenable Cloud Security will process activity logs from your cloud environment so you can easily inspect what actions were carried out by each identity, including the potentially compromised service identity of the machine: 

This log is easily accessible and more importantly, it’s easily understandable even for those who aren’t necessarily cloud experts. Such a tool is invaluable, especially when your team needs to do such auditing at a large scale in case you’ve had many exposed machines for a significant period of time. 

The discovery of vulnerabilities such as regreSSHion is a good reminder of the kind of power and control we as security professionals have to wield over the cloud environments we’re trusted with securing. 

Thinking about the kind of fallout such lengthy exposure at scale to remote code execution may have on your cloud environment can be overwhelming – and this is why we make it our mission at Tenable Cloud Security to assist you with this task.