In case you haven’t heard already, a major security flaw in Kubernetes has been discovered recently. 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 Kubernetes API server logs or server logs and even when they do, they are impossible to distinguish from the correctly-authorised requests via the Kubernetes API Server.
Now does this mean your entire cluster can be pwned 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:
```
GET HTTP/1.1
Host: destination.server.extAuthorization: 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 setup 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 setup 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 `kubectl version --short=true | grep Server`.
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.
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.
