kubernetes/minikube

CVE-2018-1002103: Dashboard vulnerable to DNS rebinding attack

tstromberg opened this issue · 2 comments

tstromberg commented

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

minikube exposes the Kubernetes Dashboard service with a configuration that makes it vulnerable to DNS rebinding attacks.

Thanks to Alex Kaskasoli (MWR Labs) for reporting this problem [1]

Vulnerable versions:

  • minikube 0.3.0 - 0.29.0

Vulnerable configurations:

  • VM environments which use a predictable IP address, such as VirtualBox or "None".

Vulnerability impact:

If an attacker gets a victim to visit a malicious web page, the attacker may be able to execute arbitrary code within the victim's minikube cluster.

minikube exposes the Kubernetes Dashboard listening on the VM IP at port 30000. In VM environments where the IP is easy to predict, the attacker can use DNS rebinding to indirectly make requests to the Kubernetes Dashboard without violating the Same-Origin Policy.

The attacker can generate a CSRF token from the /api/v1/csrftoken/appdeploymentfromfile endpoint, and pass this token to the /api/v1/appdeploymentfromfile endpoint to create a new Kubernetes Deployment running a payload of their choosing.

This vulnerability can be combined with a VM-specific vulnerability to escape to the host operating system. If minikube mount is in use, the attacker could also directly access the host filesystem.

Fixed versions:

  • Fixed in v0.30.0 by #3210

Fix impact:

Network access to the dashboard service is now provided on an as-needed basis, and is managed by kubectl proxy which enforces HTTP header checks to protect against DNS rebinding attacks.

Mitigations before upgrading:

Disable the dashboard entirely:

kubectl --namespace kube-system delete deployment kubernetes-dashboard

Additional information

bhishekarora commented

minikube is not running in production for any one and its only for learning and prototyping, who is going to do DNS attacks if its not on a public domain.

serain commented

@bhishekarora you would target developers using minikube, and from there pwn the things the developers have access to.

  1. phish employees who you know are likely to be using minikube locally. just get them to click a link.
  2. run a waterhole on a website you control (i.e. "Getting started with Kubernetes using Minikube" or "Explore the latest Kubernetes features with Minikube")

one thing to note is that this issue allowed trivial VM escape, so you would gain RCE and persistence on the host OS (and the engineer's passwords, private keys, emails etc.)

full disclosure: I'm the nerd who reported this issue

  • 👍1