Kubernetes News: High Severity Vulnerability Discovered

DZone 's Guide to

Kubernetes News: High Severity Vulnerability Discovered

If you use Kubernetes, you're going to want to know about this vulnerability, and how to avoid it.

· Security Zone ·
Free Resource

In case you haven't heard already, a major security flaw in Kubernetes has recently been discovered — one that has a CVSS score of 9.8.

CVE- 2018-1002105, a Privilege Escalation flaw, can potentially enable attackers to gain remote access to parts of a Kubernetes cluster through an API Server and perform malicious operations. Further, this vulnerability is especially tricky to find as potentially malicious requests made by attackers are made over established connections, which don't usually appear in the Kubernetes API server logs or server logs, and even when they do, they are impossible to distinguish from the correctly-authorized requests via the Kubernetes API Server.

Now, does this mean that your entire cluster can be owned by an attacker outside of the cluster?

That depends on how you've configured your cluster. The first step in the exploit is an 'Authorized request' to the Kube-API server. So if you've configured your cluster to deny access to unauthenticated users by either disallowing anonymous requests with `--anonymous-auth=false` or removing the default discovery permissions granted to anonymous users, you're good.

This flaw mostly affects clusters that have multiple (untrusted-)users with Role-Based-Access-Control(RBAC) roles intended to constrain users to particular namespaces in place. A low-privileged user with permission to exec/attach/portforward Pods can escalate privileges to perform any API request against the kubelet API on the node specified in the pod spec, like running commands on any pod and copying the secrets.

To understand the flaw, we first need to understand how WebSockets are different from a typical HTTP request/response flow. Unlike a regular HTTP request/response, WebSockets are bi-directional. It is standard procedure to start a connection using HTTP and then, request an upgrade to WebSockets. The request to upgrade to WebSockets would look something like this:



Host: destination.server.ext

Authorization: TOKEN

Connection: Upgrade

Upgrade: websocket


The server would respond with an `HTTP 101 Switch Protocols response` and a TCP connection dedicated to the WebSocket, assuming the request was authorized.


HTTP/1.1 101 Switching ProtocolsConnection: UpgradeUpgrade: websocket


Kubernetes did not check for the 101 Switch Protocols response but set up a TCP connection dedicated to the WebSocket anyway.

Essentially, if an unauthorized attacker sent a request from a pod to the K8s API-server via. the kubelet, a dedicated WebSocket connection, would be set up with the K8s API-Server, with credentials of the API server! So, an authorized user with low privilege can basically get full access to the API, escalating privileges.

While this issue has been fixed in the latest releases and patched by major service providers (like GKE, EKS, AKS, and DigitalOcean), it does not hurt to check. If you're running any of the following versions of Kubernetes ie,. v1.0.x-1.9.x, v1.10.0-1.10.10, v1.11.0-1.11.4 or v1.12.0-1.12.2, you need to upgrade as soon as possible. This can be checked by running the `kubectl version --short=true | grep Server.`

Example of a Version that is Vulnerable to the exploit

An open-source security tool by Aquasec called 'kube-hunter' was recently updated to identify CVE- 2018-1002105. Running it against a Kubernetes cluster (that you own!) can help identify some of the vulnerabilities.

Me responsibly running a vulnerable version of Kubernetes that was identified by kube-hunter

Also, it's advisable to revoke exec/attach/portforward pod permissions from users who should not have full access to the kubelet API and upgrade the cluster on priority as a mitigation against authorized privilege escalation.

cluster, devops, kubernetes, security, vulnerability

Published at DZone with permission of Nithin Jois , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}