Google Kubernetes Engine Double Flaws: Exploiting FluentBit & ASM for Cluster Takeover

In the ever-evolving landscape of container orchestration, Google Kubernetes Engine (GKE) stands as a colossus, offering scalable and efficient solutions. However, recent revelations from Palo Alto Networks have cast a spotlight on two specific vulnerabilities within Google Kubernetes Engine, exposing potential threats even in this advanced digital fortress.

These issues, although seemingly innocuous individually, when combined, open privilege escalation opportunities. The first issue dwells in the default configuration of GKE’s logging agent, FluentBit, which runs on all clusters. The second lies in the default privileges for Anthos Service Mesh (ASM), Google’s iteration of the Istio Service Mesh.

The FluentBit container, an inherent part of every GKE cluster, could become a gateway for attackers. If an attacker manages to exploit a vulnerability in this component, they gain a foothold in the system. The real danger emerges when the cluster has ASM installed, allowing the attacker to weave a chain of control over the entire Kubernetes cluster.

Anthos Service Mesh misconfiguration: Istio installer keeps its powerful permissions after installation. | Image: Unit 42

Anthos Service Mesh, despite its utility in managing service-to-service communication within GKE, brings along a latent risk. Its default privileges, in the wrong hands, can lead to catastrophic outcomes, including data theft and severe disruption of cluster operations.

When these two issues converge, they form a formidable exploit chain. The attacker could start by compromising the FluentBit container and then leverage the excessive permissions of ASM’s Container Network Interface (CNI) DaemonSet. This two-step attack could grant complete control over the Kubernetes cluster.

“The fact that FluentBit is a DaemonSet allows the attacker to search for any mounted tokens of any other pods in the cluster by repeating the initial compromise on each node. The attacker can map the entire cluster and find the Istio-Installer-container token,” Unit 42 researchers wrote.

“The attacker will then take advantage of the ASM CNI DaemonSet’s powerful permissions after the installation process is complete. The attacker will then create a new pod in the Kube-System namespace.”

Recognizing the gravity of these vulnerabilities, Google acted promptly. On December 14, 2023, they released a fix under GCP-2023-047, addressing both configuration issues. These fixes are a testament to Google’s commitment to security and its agile response to emerging threats.

This incident serves as a crucial reminder for Kubernetes users and administrators. The complexity of Kubernetes environments often leads to security breaches due to misconfiguration and excessive privileges. It emphasizes the importance of vigilance and the need to constantly monitor and update security configurations.

The dual privilege escalation vulnerabilities in Google Kubernetes Engine underscore the need for continuous scrutiny and improvement of security measures in the Kubernetes ecosystem.