Analysis of a Kubernetes Hack

https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c

by jc_sec • 8 years ago

8 4 8 years ago

medium.com

alpb• 8 years ago

I'm trying to understand what the issue here was. Did they publicly expose the kubelet port on the internet?

jc_sec2• 8 years ago

Yep. The kubelet ports were exposed. From the article:

As it turns out, our coworker’s server was also publicly exposing the kubelet ports (tcp 10250, tcp 10255). Although the problem here was obvious, it should raise some questions about your own Kubernetes deployment, as it did for us.

jc_sec2• 8 years ago

Try a quick nmap scan on an AWS or Google IP range for tcp port 10250 to see some scary results.

terom• 8 years ago

kubeadm seems to configure the kubelet with `--authorization-mode=Webhook`, which prevents the use of the exec API by unauthenticated users:

  $ curl -vk -X POST https://...:10250/exec/test
  ...
  < HTTP/1.1 403 Forbidden
  ...
  Forbidden (user=system:anonymous, verb=create, resource=nodes, subresource=proxy)

OTOH some endpoints on the `--read-only-port=10255` API are completely open for unauthenticated requests... that leaks all the pod metadata/spec/status information:

  $ curl http://...:10255/pods
  {"kind":"PodList","apiVersion":"v1","metadata":{},"items":[{"metadata":{"name":"kube-proxy-knfqg","generateName":"kube-proxy-","namespace":"kube-system", ...}

Not what I expected, and the `--authorization-mode=AlwaysAllow` default seems like a very bad idea :/

Analysis of a Kubernetes Hack

Related Stories