Introduction
In this blog, we will use a new standard, the Exploit Prediction Scoring System (EPSS), as an experimental method for deciding which Kubernetes vulnerabilities should be prioritized. The experiment sheds light on the variable importance of using pure CVSS scoring when deciding what to prioritize.
Too many Kubernetes vulnerabilities
There are 48 total Kubernetes vulnerabilities published since 2016, the last one being published on March 1, 2023. Recently we have posted about multiple vulnerabilities in Kubernetes tools ranging from BareMetal Operator (rated Medium), to Fluid, Clusternet, the Jenkins plugin (rated Medium), CubeFS, Crossplane (rated High) and more. It is easy to see how, combining the vulnerabilities in Kubernetes itself with the issues in third party Kubernetes tooling, one can become overwhelmed and want to figure out how to prioritize. This is especially true for projects or environments with large dependency trees, because the list of vulnerabilities you need to manage is constantly in flux.
Recently, we have been hearing about efforts to help triage those lists, including CISA’s “Known Exploited Vulnerability” database and new standards attempting to quantify the likelihood of a given vulnerability being exploited in the wild. For this blog post, we gave this concept a try to see what differences we would find with this approach, compared to one that is based purely on a CVSS score. To be clear, the sole focus of this analysis is vulnerabilities in Kubernetes itself, not vulnerabilities in third-party tools.
What is the Exploit Prediction Scoring System (EPSS)
For this post, we used one of the new standards, EPSS (Exploit Prediction Scoring System), which rates CVEs based on factors including the existence of PoCs, backlinks to the CVE, and observed exploit activity. The resulting score is an attempt to quantify the likelihood of a vulnerability being used in the wild. Additionally, a percentile lets you see how this score stacks up against other CVEs. This should, in theory, help you prioritize patching in a more effective way. The factors at play are (unlike with a CVSS score) dynamic: the absence of a PoC or in-the-wild activity today doesn’t mean there won’t be any tomorrow. So EPSS scores can and do change over time. This may cause your priorities to shift, especially with regard to older systems, but that seems intuitively to match with reality. The key difference between CVSS and EPSS in this regard is that what changes with CVSS-based prioritization is only the disclosure of new vulnerabilities. With EPSS, you are also responding to changes in adversary activity.
Applying EPSS to Kubernetes
Fundamentally, we like the idea of prioritizing vulnerabilities based on context, both inside and outside organizations. So as an experiment, we took all the CVEs in the official Kubernetes CVE feed disclosed since the start of 2020 and ran them through the EPSS API. What follows is a summary of the top 8 most likely to be exploited (as of May 12, 2023) CVEs:
CVE 2021-3121:
CVSS 3.1: 8.6
EPSS: 0.37
EPSS Percentile: 68.5%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/101435
Disclosure Date: April 23, 2021
Affected Kubernetes Versions: 1.21.0-1.21.1, 1.20.0-1.20.7, 1.19.0-1.19.11, <=1.18.19
Summary: This is an issue with the GoGo protobuf compiler (prior to version 1.3.2) used in Kubernetes. A malicious protobuf message could cause panic, potentially resulting in information disclosure, data manipulation, or denial of service. This can be mitigated via disabling protobuf messaging or through graceful panic handling. The Kubernetes security team believed at the time of release that Kubernetes built-in panic handling meant that Kubernetes itself was unaffected, but updated (and recommended updating) out of an abundance of caution. Controllers, operators, or workloads on a cluster might be impacted as well.
CVE 2020-8559:
CVSS 3.1: 6.8
EPSS: 0.27
EPSS Percentile 62.98%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/92914
Disclosure Date: July 8, 2020
Affected Kubernetes Versions: <=1.16.13, 1.17.0-1.17.9, 1.18.0-1.18.6
Summary: This bug could potentially be escalated to a High CVSS severity if multiple clusters shared the same certificate authority. Additionally, multiple proofs of concept (PoCs) exist, which likely explains the relatively high EPSS rating. In a nutshell: this bug allows an attacker who is able to intercept certain upgrade requests to the kubelet (examples: pods/exec, pods/attach, pods/portforward, any resource: proxy) to redirect those requests. This could in turn allow them to obtain credentials that could be used to take over other nodes, resulting in privilege escalation and/or lateral movement. When multiple clusters use the same certificate authority and authentication materials, this vulnerability could also be exploited to compromise nodes on other clusters. The chief factor that reduces the risk here is that the attacker needs a way to compromise the first node before they can use this vulnerability.
CVE 2020-8554:
CVSS 3.1 5.0
EPSS: 0.13
EPSS Percentile: 46.57%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/97076
Disclosure Date: December 4, 2020
Affected Kubernetes Versions: All versions
Summary: A potential man-in-the-middle attack vector, this issue remains intentionally unpatched and should be mitigated with a combination of RBAC and admissions control rules. A malicious actor with permissions to create or edit Pods and Services can potentially create a ClusterIP service with an externalIP attribute. This would allow them to intercept traffic to that service, including traffic from other Pods or Nodes in the cluster. This issue particularly impacts multi-tenant clusters, potentially allowing an attacker to intercept traffic from other tenants. A similar issue exists when an actor has permissions to patch the status of LoadBalancer services to change the ingress.ip attribute, but this is considered a privileged action and should be restricted via RBAC. Mitigations, in addition to restricting user permissions, include using admissions control to restrict the creation of external IPs and auditing/monitoring for the use of external IPs.
CVE 2021-25741:
CVSS 3.1 8.1
EPSS: 0.12
EPSS Percentile: 44.76%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/104980
Disclosure Date: September 13, 2021
Affected Kubernetes Versions: v1.22.0 - v1.22.1, v1.21.0 - v1.21.4, v1.20.0 - v1.20.10, <= v1.19.14
Summary: A path traversal bug allowing a pod to access files and directories directly on the host/node. This bug bypasses controls implemented to prevent hostPath mounts, allowing similar functionality through the use of symlinks. In addition to updating, it can be mitigated by disabling the VolumeSubpath feature and ejecting pods that use it.
CVE 2020-8551:
CVSS 3.1 6.5
EPSS: 0.11
EPSS Percentile: 43.23%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/89377
Disclosure Date: March 23, 2020
Affected Kubernetes Versions: kubelet v1.17.0 - v1.17.2, kubelet v1.16.0 - v1.16.6, kubelet v1.15.0 - v1.15.9
Summary: A denial-of-service attack against the Kubelet. Very few details were provided.
CVE 2020-10749:
CVSS 3.1 6.0
EPSS: 0.11
EPSS Percentile: 42.42%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/91507
Disclosure Date: May 27, 2020
Affected Kubernetes Versions: kubelet v1.18.0-v1.18.3, kubelet v1.17.0-v1.17.6, kubelet < v1.16.11
Summary: A Man-in-the-Middle (MitM) attack. This vulnerability was actually tied to the kubernetes-cni package used by many CNI implementations (including Calico, Docker, Flannel, and Weave Net). It made it to the official Kubernetes CVE feed because the kubernetes-cni package was delivered with official copies of kubelet for the affected versions. The vulnerability allows an attacker controlled container to send malicious router advertisements that prompt the host to redirect IPv6 traffic to the container. This may also include traffic not originally using IPv6 if DNS responses include an AAAA record (many implementations will try IPv6 first). Mitigations include blocking IPv6 router advertisements (this may break things if the cluster uses IPv6), TLS certificate validation, and not allowing CAP_NET_RAW for untrusted workloads or users (this requires a change to the Kubernetes default configuration).
CVE 2019-11254
CVSS 3.1 6.5
EPSS: 0.1
EPSS Percentile: 40.1%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/89535
Disclosure Date: March 26, 2020
Affected Kubernetes Versions: <= v1.15.9, v1.16.0-v1.16.7, v1.17.0-v1.17.2
Summary: A denial-of-service vulnerability. An attacker with permissions to create resources on the cluster could use maliciously crafted YAML to exhaust the CPU resources of the API server. Apart from upgrading, the best mitigation is restricting user authorizations using RBAC.
CVE 2020-8555
CVSS 3.1 6.3
EPSS: 0.1
EPSS Percentile: 39.81%
GitHub Issue: https://github.com/kubernetes/kubernetes/issues/91542/
Disclosure Date: May 28, 2020
Affected Kubernetes Versions: kube-controller-manager v1.18.0, kube-controller-manager v1.17.0 - v1.17.4, kube-controller-manager v1.16.0 - v1.16.8, kube-controller-manager <= v1.15.11
Summary: A Server Side Request Forgery (SSRF) issue. An attacker with permissions to create pods on the cluster using certain built in storage types or with the permissions to create StorageClasses can manipulate the kube-controller-manager into making GET and/or POST requests on their behalf to a user-supplied, unvalidated URL. This can result in leaking up to 500 bytes of information from unprotected endpoints in the master’s host network. It can be mitigated by protecting endpoints on the master’s host network, restricting the volume types available in the cluster, and using RBAC to restrict what users can create Pods or StorageClasses.
What Surprised Us?
First, since 2020 there have been two CVEs given an 8.8 CVSS rating. Neither of them made it to the top 8. The first, CVE 2020-8558, was close, coming in 9th with an EPSS of 0.1 (39.67%). In contrast, the more recent, CVE 2022-3294, has an EPSS of 0.048 (14.61%). We aren’t saying you shouldn’t patch either of these (we think you should), but it is interesting to note that they are both considered relatively unlikely to be exploited despite their high CVSS ratings.
Second, no CVE’s impacting currently supported versions of Kubernetes made the list either. These are:
- CVE-2022-3294 CVSS: 8.8, EPSS: 0.048 (14.61%)
- CVE-2022-3162 CVSS: 6.5, EPSS: 0.05 (16.4%)
- CVE-2022-3172, Not published to MITRE/NVD, no EPSS data
- CVE-2021-25749, Not published to MITRE/NVD, no EPSS data
Note the two that were not published to MITRE/NVD: EPSS only provides scoring for CVEs published to these aggregation databases. While that should cover most vulnerability disclosures, its an important caveat to keep in mind if you are considering EPSS for triaging your vulnerability management.
That being said, in a recent survey, most teams are found to be running Kubernetes v1.21, which is, as of writing this blog, 24 months old. Of the eight CVEs we have listed, two are potentially an issue in v1.21 or higher: CVE 2021-25741 and CVE 2021-3121. While upgrading Kubernetes versions is a significant, potentially breaking change, this analysis demonstrates it is worth it, regardless of whether you use a CVSS or EPSS method to prioritize vulnerabilities.
Conclusion
EPSS is a relatively new standard for triaging vulnerabilities based on their likelihood of being exploited. The concept itself is interesting, and our analysis of Kubernetes vulnerabilities demonstrates how it shifts the focus to vulnerabilities that are often lower severity but more likely to be used. This re-affirms the concept that, if you only focus vulnerability management in Kubernetes on critical and high CVSS scores, you are still vulnerable.
Misconfigurations, RBAC, runtime indicators, image CVEs and more must all be taken into account, in real-time, to get a true sense of prioritized risk for your Kubernetes clusters. Schedule a demo today to learn how to get the most refined security signal through the noise of various security findings in your clusters today.
