Attack Chain

1. Initial Access: An attacker gains initial access to the GKE cluster, potentially through compromised credentials, exploitation of a vulnerable application running within a pod, or misconfigured access controls.
2. Privilege Discovery: The attacker assesses their current permissions within the cluster, identifying roles or service accounts that allow for pod creation, update, or patching.
3. Malicious Pod Specification: The attacker crafts a Kubernetes pod specification that includes hostIPC: true in its configuration.
4. Pod Creation/Modification: The attacker either creates a new pod with the malicious specification or patches an existing pod to enable hostIPC sharing. This action requires specific API permissions within the GKE cluster.
5. Host IPC Access: The newly created or modified pod is now able to interact with the host system's IPC facilities, such as System V IPC or POSIX message queues.
6. Privilege Escalation: The attacker leverages the host IPC access to exploit vulnerabilities or misconfigurations on the host node, allowing them to gain elevated privileges or achieve a container escape.
7. Impact: With host-level privileges, the attacker can then perform further actions, including lateral movement to other nodes, data exfiltration from the host, or disruption of critical cluster services.

Impact

Successful exploitation of this privilege escalation technique allows an attacker to break out of the container's isolation and gain elevated privileges on the underlying GKE host node. This can lead to a complete compromise of the node, enabling the adversary to access sensitive data, install malicious software, disrupt services running on the node, or potentially move laterally to other nodes or even the entire Kubernetes cluster control plane. While no specific victim count is provided, any organization utilizing GKE clusters is susceptible if proper security controls are not in place to prevent or detect such configurations.

Recommendation

• Deploy the Sigma rule "GKE Pod Created With HostIPC" to your SIEM to detect attempts to create or modify pods with host IPC enabled.
• Ensure GKE audit logging is enabled and configured to capture io.k8s.core.v1.pods.create, io.k8s.core.v1.pods.update, and io.k8s.core.v1.pods.patch events for the gcp.audit log source.
• Implement and enforce Pod Security Standards (PSS) or Pod Security Policies (PSP, deprecated) in your GKE clusters to prevent the deployment of pods with hostIPC: true in untrusted namespaces.
• Baseline legitimate usage of hostIPC in your environment and configure exclusions in the "GKE Pod Created With HostIPC" rule for trusted users or namespaces if necessary, after thorough review.