Multiple Flaws in Google Kubernetes Engine Let Attackers Escalate Privileges

Google Kubernetes Engine (GEK) has been detected with two flaws that a threat actor can utilize to create significant damage in case the threat actor already has access inside the Kubernetes cluster.

The first issue was associated with FluentBit with default configuration. FluentBit is GKE’s logging agent that runs by default on all the clusters.

The second issue was linked to Anthos Service Mesh (ASM), which has default privileges. ASM controls the service-to-service communication within the GKE environment.

Multiple Flaws in Google Kubernetes Engine

If an attacker gains enough privilege inside a FluentBit container, which also has ASM installed, the threat actor can create an attack chain that could result in complete control over the Kubernetes cluster.

Free Webinar

Fastrack Compliance: The Path to ZERO-Vulnerability

Compounding the problem are zero-day vulnerabilities like the MOVEit SQLi, Zimbra XSS, and 300+ such vulnerabilities that get discovered each month. Delays in fixing these vulnerabilities lead to compliance issues, these delay can be minimized with a unique feature on AppTrana that helps you to get “Zero vulnerability report” within 72 hours.

Register for Free

Post this, the threat actor can perform various actions such as data theft, deployment of malicious pods, or even disruption of the Kubernetes cluster’s operations. However, Google fixed this configuration issue in mid-December 2023.

Exploitation of FluentBit Permissions

In this step, each pod inside the FluentBit mounted volume contains a kube-api-access volume that has the projected service account token. This token is used to communicate with the Kubernetes API, which is sensitive information. 

If the FluentBit pod is compromised, the threat actor can use any token of any pod on the node. After this, the threat actor can also impersonate a pod and gain privileged access inside the Kubernetes API server, followed by several malicious actions such as mapping the entire cluster, listing all the running pods, etc.

Second Step: Exploitation of Istio Post-Installation Permissions

This step involves the exploitation of ASM’s Container Network Interface (CNI) DaemonSet, which keeps excessive privileges after installation. While ASM is enabled, Istio-cni-node DaemonSet is also installed in the cluster.

This Daemonset is used for installing and configuring the Istio CNI plugin on each node in the cluster, and it also has higher permissions to perform tasks. However, once it starts to run, it does not require higher permissions.

There are two roles for this Daemonset; one of them is to install the CNI plugin, which does not require RBAC (Role-based access control), and the other is “repair” mode, which detects if pods have started without configuration, which requires some level of RBAC privileges.

Chaining these Exploits

To chain these exploits, the pod must have an ASM feature installed, and the threat actor must gain privileged access inside the Kubernetes cluster. Once these two prerequisites are fulfilled, the threat actor can chain these exploits.

The threat actor can perform a task after taking control of the FluentBit container by exploiting the default configuration. Once after this, the threat actor can have access to the kube-api-access-<random-suffix> directory that has all the tokens from all the pods in the node.

From there, the threat actor can perform any malicious actions and gain complete control over the Kubernetes cluster.

A complete report about these two issues has been published by Palo Alto, providing detailed information about the privileges, concepts, exploitation, and other information.