What Are The Common Kubernetes Security Vulnerabilities

Kubernetes has become the de-facto standard for managing containerized applications. The high popularity and wide adoption across the industry have led to rapid growth in Kubernetes and its ecosystem. However, this widespread usage has also led to an increased attack surface for K8s, resulting in a higher number of security vulnerabilities. The Kubernetes community is actively patching any discovered vulnerabilities. As a Kubernetes user, you must be aware of common vulnerabilities to mitigate them until a fix is available. Each of these vulnerabilities is scored using the which determines their severity. Common Vulnerability Scoring System (CVSS Score : 6.0) CVE-2020-8559 The in versions 1.6-1.15 and version prior to 1.16.13, v1.17.9, and v1.18.6 are vulnerable to invalidate redirects on proxied update requests. It allows an attacker to escalate privileges from a compromised node. kube-apiserver The attacker can intercept requests on a compromised node and redirect those requests along with their credentials. They can use those requests to interact with other nodes that trust the intercepted credentials. (CVSS Score : 6.0) CVE-2020-8554 All versions of the Kubernetes API server are vulnerable to this attack. If an attacker manages to create a ClusterIP service and set the “spec.externalIPs” field, he can intercept any traffic to that IP. Additionally, if an attacker can change the status of a Loadbalancer service and set the “status.loadBalancer.ingress.ip”, he can intercept traffic to that IP. This is only applicable if the attacker already has access to the cluster and has the necessary permissions to create or edit services. The authorization process determines the actions a user can perform. If the access control is improperly applied or compromised, the attacker can gain access to service resources in K8s and intercept traffic in the cluster. (CVSS Score : 6.4) CVE-2019-11248 The debugging endpoint /debug/pprof is exposed over the unauthenticated Kublets healthz port. As the go pprof endpoint is exposed, it can leak sensitive information such as internal memory addresses and configurations. This vulnerability only affects the versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10. Here, an attacker can freely access any data exposed by the endpoint as the debugging endpoint does not have any authentication requirements (no access control configurations). (CVSS Score : 6.5) CVE-2019-11247 The kube-api server will mistakenly allow access to a cluster scoped resource if the access request is made as if the resource was namespaced. This vulnerability affects K8s versions prior to 1.13.9, 1.14.5, 1.152, and versions 1.7 to 1.12. Authorization for resources accessed in this manner is controlled using roles and role bindings of the namespace. However, this vulnerability allows users who have access to a resource in one namespace to view, create, update, and delete cluster scoped resources. Again, this vulnerability is due to incorrect authorization management with the cluster. (CVSS Score : 7.5) CVE-2018-1002105 Affecting all K8s versions prior to 1.10.11, 1.11.5, and 1.12.3, this vulnerability allows unauthenticated users to perform privilege escalations and gain complete admin-level privileges. It is caused due to incorrect handling of requests in the kube-api server. There are two attack scenarios enabled by this vulnerability. Normal authenticated users with Pod exec/attach/forward privileges can escalate their privileges and become admins, and remote unauthenticated users can gain access via the aggregated API server. The exec/attach/forward API calls can be used to perform any API request against the kubelet API. Additionally, an API call to an aggregated API server endpoint can be used to perform any API request against that aggregated API server. (CVSS Score : 7.5) CVE-2018-1002101 can be caused by insecurely handling user input while setting up volume mounts on Windows nodes. It allows attackers to execute arbitrary commands in the host system. This vulnerability only affects k8s versions 1.9.0-1.9.9, 1.10.0-1.10.5, and 1.11.0-1.11.1. Command line argument injection (CVSS Score : 6.3) CVE-2017-1002102 This vulnerability affects containers that use a secret, configMap, projected, or downwardAPI volume and allows the deletion of arbitrary files and directories on the node where the containers are running. An attacker can exploit this vulnerability and delete files and folders in a node, totally compromising the node integrity and completely shutting down the resources. It relates to Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x, and prior to versions 1.7.14, 1.8.9, and 1.9.4. (CVSS Score : 7.5) CVE-2017-1000056 This vulnerability affects Kubernetes version 1.5.0 to 1.5.4. There, privilege escalation in the PodSecurityPolicy admission plugin allows users to use any existing PodSecurityPolicy object, including objects the user is not authorized to access. This vulnerability is only applicable if the PodSecurityPolicy API and the are enabled by the users as they are disabled by default. It again relates to missing authorization controls in the plugin, which could have been mitigated by properly managing the access controls. PodSecurityPolicy admission plugin (CVSS Score : 6.8) CVE-2016-7075 This vulnerability pertains to certificate validation where Kubernetes did not correctly validate X.509 client intermediate certificate hostname fields. It will allow an attacker to bypass the authentication requirements by creating a custom X.509 certificate. This vulnerability was detected on Kubernetes used in Openshift Enterprise 3. This vulnerability is caused due to improper certificate validation. It allows an attacker to use a custom certificate to spoof a trusted entity and authorize communication between the client and the host. The system thinks the request is coming from a trusted entity and allows an attacker to access the system. Conclusion In this post, we have covered some common vulnerabilities that affect Kubernetes. Apart from them, there are other vulnerabilities with less severity, and new ones will be discovered in the future. Thus it is always advisable to keep an eye out for vulnerabilities and take action to mitigate them as soon as possible to improve the security posture of your cluster and the application as a whole. Asad Faizi Founder CEO CloudPlex.io, Inc asad@cloudplex.io