HomeData BreachGoogle Cloud Resolves Privilege Escalation Flaw Impacting Kubernetes Service

Google Cloud Resolves Privilege Escalation Flaw Impacting Kubernetes Service

Google Cloud has addressed a medium-severity security flaw in its platform that could possibly 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 might mix that entry with excessive privileges required by Anthos Service Mesh (on clusters which have enabled it) to escalate privileges within the cluster,” the corporate mentioned as a part of an advisory launched on December 14, 2023.

Palo Alto Networks Unit 42, which found and reported the shortcoming, mentioned adversaries might weaponize it to hold out “knowledge theft, deploy malicious pods, and disrupt the cluster’s operations.”

There isn’t any proof that the difficulty has been exploited within the wild. It has been addressed within the following variations 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 efficiently exploiting the vulnerability hinges on an attacker having already compromised a FluentBit container by another preliminary entry strategies, comparable to by way of a distant code execution flaw.

Google Cloud

“GKE makes use of Fluent Bit to course of logs for workloads working on clusters,” Google elaborated. “Fluent Bit on GKE was additionally configured to gather logs for Cloud Run workloads. The quantity mount configured to gather these logs gave Fluent Bit entry to Kubernetes service account tokens for different Pods working on the node.”

See also  State hackers exploiting Confluence zero-day since September

This meant {that a} risk actor might use this entry to realize privileged entry to a Kubernetes cluster that has ASM enabled after which subsequently use ASM’s service account token to escalate their privileges by creating a brand new pod with cluster-admin privileges.

“The clusterrole-aggregation-controller (CRAC) service account might be the main candidate, as it may add arbitrary permissions to current cluster roles,” security researcher Shaul Ben Hai mentioned. “The attacker can replace the cluster position certain to CRAC to own all privileges.”

By the use of fixes, Google has eliminated Fluent Bit’s entry to the service account tokens and re-architected the performance of ASM to take away extreme role-based entry management (RBAC) permissions.

“Cloud distributors robotically create system pods when your cluster is launched,” Ben Hai concluded. “They’re in-built your Kubernetes infrastructure, the identical as add-on pods which have been created whenever you allow a function.”

“It’s because cloud or software distributors usually create and handle them, and the person has no management over their configuration or permissions. This can be extraordinarily dangerous since these pods run with elevated privileges.”

See also  Juniper Networks Releases Essential Safety Replace for Routers

- Advertisment -spot_img
RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -

Most Popular