Rancher stored secrets in plaintext, exposed Kubernetes clusters to takeover

Ben Dickson 28 September 2022 at 14:08 UTC
Updated: 28 September 2022 at 14:15 UTC

Maintainers patch vulnerability and offer mitigation advice over bug that affects all Kubernetes objects

A now-patched version of Rancher, an open source Kubernetes management tool, stored secrets in plaintext, a security researcher has discovered.

The issue affected various Kubernetes objects and could enable attackers to take over entire clusters.

Rancher, which was acquired by German software provider SUSE in 2020, is popular among the DevOps and Kubernetes communities.

Catch up with the latest cloud security news

The platform allows developers to deploy and run Kubernetes container clusters from different providers. It also adds value by centralizing authentication and role-based access control to clusters, which allows admins to control cluster access from one location.

Linux system engineer Marco Stuurman, who made the recent discovery, stumbled on it while investigating Rancher’s service tokens. “I’m not a security researcher, but I keep my eyes open for things like this,” Stuurman told The Daily Swig.

“I fetched information from one of our Rancher set-ups and became suspicious of the token. I’ve looked into similar tokens before, so it caught my attention.”

‘Problem lies in low privileges’

According to Stuurman’s findings, Rancher stored sensitive fields like passwords, API keys, and account tokens in unencrypted plaintext directly on Kubernetes objects.

“Storing secrets in plaintext is indeed bad practice but sometimes needed. In this case, you can’t choose to hash the secret as this is the access key to the cluster,” Stuurman said. “The problem lies in the low privileges needed to access this key.”

According to the bug report, the plaintext data would be available to anyone with read access to the Kubernetes objects through the API.

“The attacker only needed the least possible privileges to a cluster Rancher manages. For example, our monitoring robot user’s only privilege was to proxy HTTP requests from rancher to the monitoring instance running in the target cluster,” Stuurman said.

Protecting your cluster

All Kubernetes objects are affected.

The service account token used to provision clusters is particularly critical since it has the highest privileges. In this case, the exploit could allow attackers to escalate their privileges and completely take over the cluster if there weren’t any other advanced prevention measures.

The issue has been addressed in the latest version of Rancher. The maintainers of the project have provided a script to rotate Rancher service account tokens. They also advised admins to limit access to Rancher instances, to check their downstream clusters for potential signs of a breach, and to change credentials that might have leaked.

“The best way to protect your cluster is to limit your cluster management tool access to people you trust,” Stuurman said. “However, that doesn’t mean it shouldn’t be as secure as possible.”

The Daily Swig has invited the maintainers of Rancher to comment but we are yet to hear back. If we do, we will update this article accordingly.

DON’T MISS CI/CD servers readily breached by abusing SCM webhooks, researchers find