Google Cloud Resolves Privilege Escalation Flaw Impacting Kubernetes Service

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

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

Palo Alto Networks Unit 42, which discovered and claimed the shortcoming, explained adversaries could weaponize it to carry out “knowledge theft, deploy malicious pods, and disrupt the cluster’s functions.”

Impending WEBINAR From Person to ADMIN: Learn How Hackers Achieve Complete Control

Explore the solution tactics hackers use to turn into admins, how to detect and block it in advance of it is really way too late. Register for our webinar these days.

Be a part of Now

There is no evidence that the issue has been exploited in the wild. It has been resolved in the following variations of Google Kubernetes Motor (GKE) and Anthos Assistance 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 critical prerequisite to effectively exploiting the vulnerability hinges on an attacker obtaining already compromised a FluentBit container by some other original accessibility strategies, these kinds of as through a remote code execution flaw.

“GKE works by using Fluent Bit to system logs for workloads managing on clusters,” Google elaborated. “Fluent Little bit on GKE was also configured to acquire logs for Cloud Operate workloads. The quantity mount configured to accumulate individuals logs gave Fluent Little bit access to Kubernetes company account tokens for other Pods functioning on the node.”

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

“The clusterrole-aggregation-controller (CRAC) assistance account is most likely the leading applicant, as it can increase arbitrary permissions to current cluster roles,” security researcher Shaul Ben Hai claimed. “The attacker can update the cluster function certain to CRAC to have all privileges.”

By way of fixes, Google has removed Fluent Bit’s access to the support account tokens and re-architected the functionality of ASM to get rid of abnormal function-dependent entry control (RBAC) permissions.

“Cloud sellers quickly build process pods when your cluster is released,” Ben Hai concluded. “They are constructed in your Kubernetes infrastructure, the identical as add-on pods that have been made when you empower a element.”

“This is since cloud or software sellers typically make and handle them, and the consumer has no management over their configuration or permissions. This can also be incredibly dangerous considering that these pods operate with elevated privileges.”

Discovered this posting fascinating? Observe us on Twitter  and LinkedIn to go through more special material we submit.

Some parts of this article are sourced from:
thehackernews.com