Prioritizing CVEs in the Cloud

Introduction

Common Vulnerabilities and Exposures (CVEs) are a top cause of cloud breaches. Organizations often fail to patch or mitigate these known vulnerabilities. Sometimes, it is due to gaps in visibility over which CVEs are present in their cloud environments. Often, organizations simply struggle to keep up with the drumbeat of vulnerabilities and prioritize their remediation. Gaps in patching both offer a foothold for targeted attacks and also empower untargeted, large-scale exploitation attempts.

The Data on Cloud CVEs

Google Cloud is the only major cloud service provider consistently publishing data on the root causes of cloud compromises. Their H1 2024 Threat Horizons Report found that 11.5% of 2023 cloud compromises involved “vulnerable software” as the initial access vector.

Unit 42 published their own data on 2024 Incident Response engagements. In line with Google’s report, Unit 42 found that CVE exploitation is the single most common root cause in 2023. Large-scale exploitation of internet-facing vulnerabilities was the initial access vector in 39% of cases, compared to 28% of cases in 2022.

In the prior two years, CVE exploitation had closely trailed social engineering as the second most prominent initial access vector. While this data is not limited to cloud incidents, it is still indicative of the large role played by CVEs in cloud breaches.

Cloud CVEs & CNAs

There are two types of CVEs that impact cloud environments, which can be distinguished based on how they relate to the Shared Responsibility Model (AWS, Azure, GCP). In this post, we’ll be focused on CVEs in applications and services deployed by customers, and falling on customers to remediate. However, let’s have a quick aside on vulnerabilities directly in the Cloud Service Providers (CSPs).

Cloud CVEs are an evolving topic. Recently, we’ve seen momentum on tracking CSP security vulnerabilities, which had previously been handled with little tracking or fanfare. The Open Cloud Vulnerability & Security Issue Database is a community effort that has made significant strides in the past couple of years by aggregating public information on CSP security issues.

On the CSP side, Microsoft recently promised increased transparency. They commit to “issue CVEs for critical cloud service vulnerabilities, regardless of whether customers need to install a patch or to take other actions to protect themselves.” Amazon took a similar step, establishing themselves as a CVE Numbering Authority (CNA), hopefully a sign of increased transparency from them as well.

I applaud the potential for increased transparency, and hope the trend will continue. However, it is worth noting that there have been no known breaches attributed specifically to CVEs against cloud service providers.

Case Studies

Real world examples can help hammer home the risks CVEs pose to your cloud environment.

Going back to 2014, Browserstack were the victims of a breach facilitated by CVE-2014-6271, better known as Shellshock. In this case, the exploited machine was long-running and not in active use, and so patches were not kept up to date.

In a more recent example, ONUS, a large cryptocurrency platform, saw an attacker exploit Log4Shell (CVE-2021-44228) in a third party payment software. Here, attackers were able to rapidly exploit the vulnerability before notification had been made by the third party of their exposure. There was only a few-day window before Log4Shell’s publication and the attack.

Other examples can be found in anonymous case studies published by incident response and security vendors:

• SentinelOne’s Vigilance MDR team has coverage of a cloud ransomware incident that exploited CVE-2022-47986 in IBM Aspera Faspex.
• Permiso has reported exploitation of a GitLab vulnerability (CVE-2021-22205) leading to Cryptomining.
• Unit 42 saw CVE-2023-22952 in SugarCRM as an initial vector in multiple cases over the course of 2023.
• Trend Micro dissected XMRig cryptomining activity using CVE-2023-22527 in Atlassian.

Across these examples, we can see that both “name brand” vulnerabilities and more obscure ones are fodder for attackers. These vulnerabilities were all public before exploitation, although it could be as soon as days afterwards. Some examples indicate the opportunistic “large-scale exploitation” Google Cloud’s Threat Horizon explained, while others indicate attackers finding exposed vulnerabilities in a specific target (or set of targets).

Remote Code Execution (RCE) by Design

Beyond CVEs, there is an adjacent class of risk worth highlighting, that I’ll call “RCE by design”. This involves software or services with code execution as a feature. These services are more common than expected and the security model generally relies on isolating the service to trusted users. JupyterLab, which is such a tool, was inadvertently exposed publicly and SCARLETEEL exploited it. Another example is Weave Scope, a Kubernetes monitoring tool that attackers used to compromise JW Player.

Analyzing & Prioritizing CVEs

Cloud CVEs clearly pose substantial risk, so how can you best manage these issues?

The first challenge is discovery. In order to fix these issues, you must continuously identify and track your exposure to vulnerabilities. This requires a classic program of asset inventory and vulnerability management.

Downstream of your asset inventory, you should review and manage potential risks from RCE by Design. Audit any publicly exposed software in your environment for features that might intentionally allow code execution.

Once you have identified potential cloud CVEs in your environment, prioritization is the challenge. In many companies, there are simply too many minor vulnerabilities to feasibly resolve immediately. An example vulnerability management Service Level Agreement (SLA) might allow 3 days for critical risks, 7 days for high risks, 30 days for medium risks, and have low risks resolved as best effort. Ensuring that your cloud CVEs are appropriately categorized is therefore key to ensuring they are resolved before attackers can exploit them.

There are a few useful resources to inform risk rating cloud CVEs:

Common Vulnerability Scoring System (CVSS)

CVSS contains the baseline “severity” information for a CVE. The score is computed based on a mix of Exploitability metrics like Attack Complexity, and Impact metrics like Vulnerable System Confidentiality. However, it was not initially intended for use in remediation prioritization. Vulnerabilities are often rated High or Critical despite unlikely exploitation.

CISA’s Known Exploited Vulnerabilities (KEV)

CISA started developing the KEV catalog in 2021. It presents a clear risk signal, as it only includes vulnerabilities that are causing immediate harm based on real world attacker activity. However, while a vulnerability’s presence in the KEV catalog is meaningful, it can only capture a subset of exploitable and exploited high risk vulnerabilities. It is also a lagging indicator of exploitability.

Exploit Prediction Scoring System (EPSS)

EPSS offers a theoretical, data-driven prediction of the likelihood a specific CVE will be exploited in the wild. Usefully, EPSS evolves over time, and incorporates real-world exploit data on an ongoing basis. Definitionally, any of the CVEs in our example cases will carry an extremely high EPSS, as they now have been exploited in the wild.

Common Weakness Enumeration (CWE)

CWE categorizes vulnerabilities. For example, Server-Side Request Forgery is CWE-918.

CWE can be useful to specifically weigh and prioritize the classes of vulnerability that are most likely to impact your cloud environment. CWE-918 is a prime example, as there is a long history of SSRF vulnerabilities leading to cloud compromise.

Applying our Prioritization Approach

Let’s close out by working through some applied examples of our prioritization approach.

Example 1

We can start by retroactively checking our approach against CVE-2022-47986, found in a cloud ransomware incident reported by SentinelOne’s Vigilance MDR. This vulnerability has:

• CVSS: 9.8 base score
• Current EPSS: 95.99%
• Initial EPSS: 38.46%, which is ~97th percentile
• CWE: CWE-502 (Deserialization of Untrusted Data)
• In KEV? Yes

Overall, while the CWE is not specifically dangerous to cloud environments, the extremely high EPSS, combined with high CVSS would have been a clear signal to remediate well before the issue made its way into the KEV.

Example 2

To stress test our methodology, we can compare two recent CVEs. I’ve selected two “high risk” CVEs from those disclosed in the month of September.

As you can see, CVE-2024-6445 has a higher CVSS score on its face. But deeper inspection shows the higher risk posed by CVE-2024-45507 to cloud environments based on the cloud specific CWE and EPSS score.

This example offers a model for more effective prioritization of cloud CVEs. I hope it serves a useful tool in mitigating a top cause of cloud breaches.

Conclusion | The SentinelOne Perspective

It’s clear that new models for prioritizing cloud risk are required, and Rami’s process is an excellent approach.

This evidence-based approach to prioritization and alert validation surfaces remediation opportunities for security practitioners to immediately and concretely increase their cloud security posture. For example, which vulnerabilities (potentially in combination with cloud misconfigurations) are actually exploitable from the outside, with proof to match. Below is an example Exploit Path of a Metabase vulnerability which leads to Server Side Request Forgery and proves that an attacker could perform credential theft externally with this risk:

SentinelOne is on this journey with you, and our Singularity Cloud Security focuses on enabling organizations to protect their cloud resources and respond to cloud risk that matters.When it comes to ranking cloud risk, SentinelOne believes in an evidence-based approach to prioritization. Within our Cloud Native Security, we offer an Offensive Security Engine™, which delivers crucial value and an industry-first for customers: Verified Exploit Paths™.

Where cloud alerts and vulnerability notifications typically consist of overwhelming noise, are time-intensive to validate, and prone to false positives, the Offensive Security Engine differentiates between theoretical and exploitable risks by providing proof of exploitability with each alert.

Learn more about Singularity Cloud Security here, or hear what our customers have to say on PeerSpot, G2, and Gartner Peer Insights. A self-guided tour is also available here for those who want to see CNS in action.