1

Can an API endpoint or a Web Application hosted on K8S exposed been breached to compromise the entire K8S cluster? Were there ever such attacks?

i.e., attacker compromises the spring boot based API with some /PUT, /POST calls which then compromises the container, then the pod, then the cluster itself and subsequently lateral movement throughout the network.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Nathan Aw
  • 1
  • 7
  • 12
  • 5
    Can is the possibility whose answer is always yes in infosec. Probability of it is unlikely because it requires chain of exploits and an ideal condition to assume that all the exploits will work. – defalt Oct 08 '21 at 08:05

2 Answers2

3

So this model of attack is definitely possible in a Kubernetes environment, but has some steps to it :-

Let's assume that the attacker can compromise a container running an application, and get a shell. From there there's a couple of lateral movement options

  1. By default every pod in a cluster gets a service account token to communicate back to the Kubernetes API server. In any modern version they don't have many rights by default, but I've seen cases when they do. If this is the case the attacker can use the token to execute commands directly onto the Kubernetes API server, what they can do will depend on the rights given.

  2. By default on every Kubernetes cluster, there's a flat open network for all applications. Assuming that network policy hasn't been used, the attacker can try to compromise other applications running in the cluster. I've often seen cases where applications assume the container network is trusted and allow unauthenticated access.

  3. Cloud metadata services are another attack point. By default a compromised container will have access to 169.254.169.254 in the network they're in, and if there are IAM creds available they may be able to get them and escalate privileges out to the Cloud env.

  4. Downwards into the hosting node (by attacking the container runtime) may be possible, but it would depend on the container being run with a lot of rights (e.g. --privileged), having sensitive files mounted, or a CVE in the runtime, probably not as likely.

TBH there's more variable than that, depending on what's in environment and exactly how it's configured (e.g. if they're doing EKS fargate that changes things a lot) but those attack paths are possible in a standard configuration of many cloud clusters.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
1

It's possible? Yes. There's no law of Universe stopping that to happen.

It's trivial? Not at all.

An attacker can start on the API and end on the host, but he would have to breach a lot of layer to get there.

He would need to achieve code execution on the application, execute code outside of the application boundaries, get access to the container, exploit the container runtime to escape it, compromise the cluster, compromise the K8S runtime, escape it, and achieve code execution on the host.

And if you take into account that a container usually hosts only the bare minimum to run the application, you see how difficult is to start on it and end on the host.

It's doable, but very unlikely: it needs a long chain of exploits to succeed. The longer the chain, the more difficult.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142