Kubernetes CVE-2018-1002105

James Condon
Director of Research, Lacework Labs

On December 3rd a critical Kubernetes vulnerability was announced under CVE-2018-1002105. This vulnerability scored a 9.8 out 10 on the Common Vulnerability Scoring System (CVSS). The vulnerability stems from an issue with Kubernetes API Server (kube-apiserver) handling proxy requests when upgrading to WebSockets. The vulnerability ultimately can allow authenticated and unauthenticated users to make API requests to backend servers with elevated privileges.

Background

The vulnerability was discovered by Darren Shepherd, co-founder and chief architect at Rancher Labs, Inc. in early November. However, the origins of the bug date back a few years. In his blog, Darren describes the history of the issue and the nature of the vulnerability. Darren also emphasises how quickly the Kubernetes community jumped on the issue and fixed it.

How the Vulnerability is Exploited

Exploiting this vulnerability begins with access to the kube-apiserver and authorization to make requests against aggregate APIs or authorization to issue exec, attach, or portforward actions on pods. If the conditions are met the user can issue a request, that includes an upgrade to WebSockets, to a backend server, via kube-apiserver. Regardless of the result of the WebSockets upgrade request, the proxy opens a connection that does not enforce authorization.

In the first scenario, and in a default configuration, authenticated or unauthenticated users can perform service discovery calls to aggregate APIs servers. This connection can be used to make requests with escalated privileges to do things such as leak information.

In the second scenario the user must be authorized to issue exec, attach, and portforward API calls. In this scenario the user can leverage the vulnerability to issue commands against the kubelet API with a higher privilege. The attacker can do things like run arbitrary commands or dump secrets such as this proof of concept.

Lastly, the implications of these scenarios depend heavily on the deployment and configuration of the cluster. However most issues stem from default configurations.

How to Fix and Mitigate

If possible upgrade to one of the following releases:

• 10.11
• 11.5
• 12.3
• 13.0-rc.1

If this is not possible consider mitigating by disabling anonymous requests, suspending aggregated API servers, and remove pod exec, attach, and portforward permissions for users that do not need them.

How Lacework Can Help

On December 10th, we announced support for Kubernetes. Lacework now gives visibility and threat detection for your Kubernetes clusters, namespaces, nodes, and pods. In Figure 1 you can see an example dashboard of metrics around a Kubernetes cluster in Lacework.

Figure 1. Dashboard for monitoring Kubernetes cluster.

For demo purposes we deployed a simple cluster and exposed the kube-apiserver to the world. As you can see from Figure 2, the API server receives connections from malicious IPs.

Figure 2. Polygraph of pod communications.

Lacework helps identify exposed Kubernetes components and also alerts on malicious activity.

Figure 3. Event detailing a blacklisted IP connecting to kube-apiserver.

Obviously you shouldn’t deploy a cluster with the API server open to the world, however it can happen through misconfiguration. Next in our demonstration we compromise the cluster and deploy a container for cryptocurrency mining. Below in Figure 4 is an event summary for a connection to an XMR mining pool.

Figure 4. Event Summary for connection to XMR mining pool.

Given the release of CVE-2018-1002105, visibility and threat detection for your Kubernetes cluster is paramount. Kubernetes clusters can become very complex very fast. It’s important to stay a step ahead and have the insights you need to protect your cluster.

 

 

 

Photo by Joseph Barrientos on Unsplash