Aqua Security Uncovers Major Kubernetes Attacks

Aqua Security, a leading cloud native security figure, has unveiled alarming findings after a three-month investigation by its research team, Aqua Nautilus. The study revealed that Kubernetes clusters of over 350 entities, including Fortune 500 companies, open source projects, and individuals, were left exposed and vulnerable.

An insanely high 60% of examined clusters had been compromised, with malware and backdoors actively deployed. The vulnerabilities stemmed from two primary misconfigurations, highlighting the dangers of both known and overlooked misconfigurations.

Wrong Hands

Assaf Morag, Aqua Nautilus’s lead threat intelligence analyst, stressed the gravity of the situation, stating, “Access to a company’s Kubernetes cluster in the wrong hands could spell the end. Everything from proprietary code, customer data, financial records, to encryption keys is at risk.”

For example, Aqua found that the Kubernetes cluster was often part of the organization’s Software Development Life Cycle (SDLC). Therefore, the Kubernetes cluster also had access to Source Code Management (SCM), Continuous Integration/Continuous Deployment (CI/CD), registries, and the Cloud Service Provider. In short, everything and the kitchen sink.

Since Kubernetes has become the default platform for managing containers, numerous businesses use it to manage containerized applications efficiently. Now, if only they knew how to secure it! Morag added, “Despite the availability of Kubernetes security tools such as Aqua’s Software Supply Chain Security suite, misconfigurations remain rampant across all organization sizes. The potential damage from these vulnerabilities is immense.”

You think?

Indifference?

So, what did the violated groups have to say about all these problems? The initial response from the affected cluster owners was indifference. Many dismissed their hacked clusters as mere ‘testing environments.” Denial is not just a river in Egypt.

They should be concerned. Three different cryptocurrency mining operators are primarily using the breached Kubernetes clusters. These are TeamTNT’s Silentbob campaign; the role-based access control (RBAC) Buster campaign; and yet another Dero Campaign. Maybe your business can afford to waste compute on mining cryptocurrency. Mine can’t.

So, how are these crypto miners breaking in?

Number one with a bullet is that unauthenticated requests to the cluster are often enabled by default. That means that anyone can send requests and get responses with a Kubernetes cluster. Most cloud providers’ default configuration for the API server is to make it Internet accessible to anyone.

OK, that’s bad, but it’s not a showstopper. Still, since anyone can get answers from the API server, that means they can list all the secrets stored in the distributed key storage etcd. If you include secrets within the environment variables, such as links to other environments and secrets or credentials such as Docker Hub, your cloud service provider, GitHub, GitLab, Bitbucket, etc., etc. If you store secrets like this, you should block anonymous users from any access to your cluster.

Generally speaking, the anonymous user has no other permissions. But far too many administrators give privileges to the anonymous user. Don’t ask me why. This is just asking for trouble.

Aqua reports they’ve seen “cases in which practitioners bind the anonymous user role with other roles, often with admin roles. From there, it’s a very short step indeed to attackers gaining unauthorized access to the Kubernetes cluster. So, it is that “you’re only one YAML away from disaster.”

The other common misconfiguration is how the “kubectl proxy” command is set up. When you run “kubectl proxy”, you are forwarding authorized and authenticated requests to the API server.

So, for example, When you run the same command with the following flags “–address=`0.0.0.0` –accept-hosts `.*`”, your workstation’s proxy will now listen and forward authorized and authenticated requests to the API server from any host that has HTTP access to the workstation. Mind you that the privileges are the same privileges that the user who ran the “kubectl proxy” command has. Whoops.

So what can you do? Lock Your Systems Down. Specifically, Aqua Nautilus recommends using native Kubernetes features like RBAC and admission control policies to enhance security. Regular audits and open source tools like Aqua Trivy, Aqua Tracee, and Kube-Hunter can help in real-time threat detection and prevention.

Really, this is all pretty simple, straightforward security stuff. Unfortunately, all too many of us are still ignoring security 101. Aqua reminds us that we can’t afford to ignore it.