Google Cloud Resolves Privilege Escalation Flaw Impacting Kubernetes Service

Cloud Security / Data Protection

Google Cloud has addressed a medium-severity security flaw in its platform that could be abused by an attacker who already has access to a Kubernetes cluster to escalate their privileges.

“An attacker who has compromised the Fluent Bit logging container could combine that access with high privileges required by Anthos Service Mesh (on clusters that have enabled it) to escalate privileges in the cluster,” the company said as part of an advisory released on December 14, 2023.

Palo Alto Networks Unit 42, which discovered and reported the shortcoming, said adversaries could weaponize it to carry out “data theft, deploy malicious pods, and disrupt the cluster’s operations.”

UPCOMING WEBINAR

From USER to ADMIN: Learn How Hackers Gain Full Control

Discover the secret tactics hackers use to become admins, how to detect and block it before it’s too late. Register for our webinar today.

Join Now

There is no evidence that the issue has been exploited in the wild. It has been addressed in the following versions of Google Kubernetes Engine (GKE) and Anthos Service Mesh (ASM) -

• 1.25.16-gke.1020000

• 1.26.10-gke.1235000

• 1.27.7-gke.1293000

• 1.28.4-gke.1083000

• 1.17.8-asm.8

• 1.18.6-asm.2

• 1.19.5-asm.4

A key prerequisite to successfully exploiting the vulnerability hinges on an attacker having already compromised a FluentBit container by some other initial access methods, such as via a remote code execution flaw.

“GKE uses Fluent Bit to process logs for workloads running on clusters,” Google elaborated. “Fluent Bit on GKE was also configured to collect logs for Cloud Run workloads. The volume mount configured to collect those logs gave Fluent Bit access to Kubernetes service account tokens for other Pods running on the node.”

This meant that a threat actor could use this access to gain privileged access to a Kubernetes cluster that has ASM enabled and then subsequently use ASM’s service account token to escalate their privileges by creating a new pod with cluster-admin privileges.

“The clusterrole-aggregation-controller (CRAC) service account is probably the leading candidate, as it can add arbitrary permissions to existing cluster roles,” security researcher Shaul Ben Hai said. “The attacker can update the cluster role bound to CRAC to possess all privileges.”

By way of fixes, Google has removed Fluent Bit’s access to the service account tokens and re-architected the functionality of ASM to remove excessive role-based access control (RBAC) permissions.

“Cloud vendors automatically create system pods when your cluster is launched,” Ben Hai concluded. “They are built in your Kubernetes infrastructure, the same as add-on pods that have been created when you enable a feature.”

“This is because cloud or application vendors typically create and manage them, and the user has no control over their configuration or permissions. This can also be extremely risky since these pods run with elevated privileges.”

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.