Headline
Google Kubernetes Engine Vulnerabilities Could Allow Cluster Takeover
By Deeba Ahmed An attacker with access to a Kubernetes cluster could chain two vulnerabilities in Google Kubernetes Engine (GKE) to escalate privileges and take over the cluster. This is a post from HackRead.com Read the original post: Google Kubernetes Engine Vulnerabilities Could Allow Cluster Takeover
Google addressed the issue with GCP-2023-047 on December 14, 2023; however, customers are urged to ensure they have installed the patch.
Palo Alto Networks’ Unit 42 researchers have discovered a vulnerability chain in Google Kubernetes Engine (GKE) that could allow attackers to escalate privileges and gain unauthorized access to entire clusters.
Unite 42 report highlights potential security weaknesses in two key GKE components: FluentBit, the default logging agent for GKE that collects/forwards container logs, and Anthos Service Mesh (ASM), an optional add-on for service-to-service communication within GKE clusters.
Unit 42 researchers first combined FluentBit vulnerability with ASM’s CNI DaemonSet privileges, leading to an attack chain escalating to cluster-admin privileges.
For your information, FluenBit, a lightweight log processor and forwarder, has been the default logging agent in GKE since March 2023, deployed as a DaemonSet (controller), whereas ASM is Google’s Istio Service Mesh open-source project implementation.
Kubernetes is a widely used open-source container platform for application deployment and management, but it is susceptible to security breaches due to misconfiguration and excessive privileges, potentially without customer awareness.
As stated in a technical blog post, researchers discovered that an attacker with access to Google Kubernetes Engine (GKE) could chain two vulnerabilities to escalate privileges and take over a Kubernetes cluster. This can help attackers gain a potential second-stage exploit path, provided they have achieved remote code execution in the FluentBit container or can break out of another container.
Second-stage cloud attacks involve an attacker (who already has some level of access to a Kubernetes cluster) managing to spread/escalate privileges by exploiting misconfigurations or vulnerabilities.
An attacker can access a GKE cluster through compromised containers or vulnerabilities, exploiting FluentBit’s default configuration to gain escalated privileges. If ASM is enabled, the attacker can exploit its default service mesh privileges to access the Kubernetes API server, granting them complete control over the cluster.
The FluentBit container can be exploited to gain unauthorized access to a Kubernetes cluster by exploiting a misconfiguration. The container mounts the /var/lib/kubelet/pods volume, which contains a projected service account token for each pod running on a node. This allows the attacker to impersonate a pod with privileged access to the Kubernetes API server and map the entire cluster. The attacker can also update the cluster role bound to CRAC to possess all privileges.
The ASM’s Container Network Interface (CNI) DaemonSet’s excessive permissions post-installation can also be exploited, allowing an attacker to create a new pod with these permissions. This allows the attacker to gain complete control over the Kubernetes cluster by escalating privileges to the cluster admin.
Google addressed both configuration issues with GCP-2023-047 on 14 December 2023. Google Security Team fixed FluentBit’s access to logs by reducing its volume mount configuration to only necessary ones. Google knew of high privileges in Anthos Service Mesh and fixed/reduced permissions to address the issue.
To stay protected, you must immediately update FluentBit, review ASM privileges, minimize privileges to GKE cluster components, and continuously monitor for suspicious activity in your GKE environment to address identified vulnerabilities.
Anthony Tam, Manager of Security Engineering at Tigera, a San Francisco-based cybersecurity firm specializing in providing protection services for containers and Kubernetes wanred that insufficient network visibility in Kubernetes may result in misconfigurations, exposing vulnerabilities that could lead to ransomware, data exposure, DoS attacks, and unauthorized lateral movement, emphasizing the need for workload-level visibility to address these threats effectively.
“Lack of network visibility in Kubernetes clusters and workloads can cause misconfigurations, which can lead to devastating consequences, such as ransomware attacks, exposure of sensitive data, denial of service (DoS) attacks and unauthorized lateral movement. It’s critical to have visibility at the workload level to identify and mitigate misconfigurations and threats that traditional perimeter-based security solutions cannot identify.”
****RELATED ARTICLES****
- ARMO integrates ChatGPT to secure Kubernetes
- Kubernetes Clusters Targeted by Siloscape Malware
- Kubernetes Clusters Targeted by Siloscape Malware
- Cryptomining Flourish on Misconfigured Kubernetes Clusters
- Google Workspace Vulnerable to Domain-Wide Delegation Flaw
- Malware Leveraging Google Cookie Exploit via OAuth2 Functionality