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 Common Vulnerability Scoring System which determines their severity.

CVE-2020-8559 (CVSS Score : 6.0)

The kube-apiserver 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.

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.

CVE-2020-8554 (CVSS Score : 6.0)

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.

CVE-2019-11248 (CVSS Score : 6.4)

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).

CVE-2019-11247 (CVSS Score : 6.5)

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.

CVE-2018-1002105 (CVSS Score : 7.5)

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.

CVE-2018-1002101 (CVSS Score : 7.5)

Command line argument injection 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.

CVE-2017-1002102 (CVSS Score : 6.3)

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.

CVE-2017-1000056 (CVSS Score : 7.5)

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 PodSecurityPolicy admission plugin 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.

CVE-2016-7075 (CVSS Score : 6.8)

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

[email protected]