GKE Container Escape Hack: How Does It Work?

The container escape hack in GKE involves three main steps:

1. Exploit a command injection vulnerability in the vulnerable web application, DVWA. This allows the attacker to execute commands in the context of the web application, which runs on a Kubernetes Pod in the GKE cluster.
2. Utilize information gathering techniques to discover that the service account has permissions to deploy privileged pods on the cluster.
3. Deploy a privileged pod on the node, enabling you to perform a container escape and escalate your privileges to obtain a root shell on the node.

By following code examples and step-by-step instructions, you'll learn to exploit an insecurely configured and thus vulnerable Google Kubernetes cluster, scan your GCP project, and assess the security of your GKE cluster. This hands-on experience will enhance your understanding of insecure Kubernetes configurations and provide you with the knowledge and tools needed to protect your own infrastructure.

Let's dive into GKE hacking and discover how to defend your clusters against potential attacks.

Prerequisites

Before you begin, ensure you have the following:

1. A Google Cloud Platform Account
2. The gcloud CLI installed on your machine
3. Terraform installed on your machine
4. kubectl installed on the host from which you run terraform

Set Up and Hack a GKE Cluster

To set up your cluster and application on GKE, follow the step-by-step instructions in the GKE lab README. This guide will also walk you through the process of hacking the vulnerable web application and escalating your privileges to gain root access to the cluster node.

Protect Your GKE Cluster with cnspec

Utilize Mondoo's free and open source CLI, cnspec, to identify security gaps that could lead to potential breaches. Follow the steps to install cnspec and scan your GKE cluster for vulnerabilities, ensuring a more secure environment.

Checking Cluster Settings from the Google Cloud Platform (GCP) Perspective

1. Connect to the GCP project using the cnspec shell:

cnspec shell gcp project <project-name>

2. Retrieve the settings of the GKE cluster (or all your clusters in the project):

gcp.project.gke.clusters {*}

3. Get basic information about the node pools in the GKE cluster:

gcp.project.gke.clusters.map(nodePools{*})

4. View the settings of the node pools in the GKE cluster:

gcp.project.gke.clusters.map(nodePools{config{*}})

5. Get the name of the service account in which context the node pools in the GKE cluster run:

gcp.project.gke.clusters { name nodePools{name config{serviceAccount{name}}}}

6. Retrieve the GCP permissions of the service account that’s running the cluster.

Note: Make sure to use this format for the service account name in the query below:

serviceAccount:name@project.iam.gserviceaccount.com

The name should resemble the string lunalectric-xxxx-node. For project-name, substitute the name of your Google project.

Query:

gcp.project.iamPolicy.where(_.members.any(_ == "serviceAccount:lunalectric-xxxx-node@project-name.iam.gserviceaccount.com")) {*}

This output shows the permissions associated with the service account that runs the node pool in your test cluster. As you can see, in addition to the three necessary roles for running a cluster, the service account also has access to the role roles/iam.serviceAccountUser. This is one of the reasons why it's possible to deploy a new Pod that escalates privileges to the root account of the node.

The presence of the roles/iam.serviceAccountUser role is a key factor in enabling the privilege escalation required to obtain a root shell on the node.

Check your cluster settings from the Kubernetes perspective

If you are connected to your Kubernetes cluster via kubectl (as described in the README instructions), you can connect to the Kubernetes cluster API with a cnspec shell:

cnspec shell k8s

Check for Pod Security Policies and Pod Security Standards in the cluster

Check if there's a Pod Security Policy (the cluster in our example uses version 1.23.16-gke.1400) bound to the default namespace that limits the possible capabilities a Pod deployment can have:

k8s.clusterrolebindings.where( _.subjects.any(_['namespace'] == "default"))

Since there isn't any cluster role binding attached to the default namespace, there isn't a Pod Security Policy in place that could limit the deployment of privileged Pods in that namespace.

Pod Security Standards are the new way to secure your namespace from the deployment of privileged pods. Pod Security Standards will replace Pod Security Policies in Kubernetes version 1.25.

You can look for labels in the default namespace that would deny the deployments in question. This query checks if the default namespace is secured using the restricted policy:

k8s.namespaces.where(name == "default") {manifest["metadata"]["labels"] {_["pod-security.kubernetes.io/enforce"] == "restricted"}}

The result of this query is false, indicating that none of the mechanisms are in place that would prevent the privilege escalation hack, which uses the deployment of a privileged Pod to gain root access on the node.

‍

Leverage Mondoo for enhanced GKE security management

While custom checks and policies may appeal to security enthusiasts, Mondoo aims to simplify your job by providing a range of advantages:

• CIS-certified policies for all major cloud providers
• CIS-certified policies for all major Linux distributions and Windows builds
• Mondoo's custom-made best practice policies
• A user-friendly, browser-based interface for tracking hardening efforts across your infrastructure
• Numerous features designed to strengthen your company's security posture

Scan your GKE cluster

After setting up your Mondoo account, enter this command in your shell to scan your GCP project:

cnspec scan gcp project <your-project-name>

At first, this does not trigger scanning based on a policy. You need to enable a policy on which to base the scan:

1. Follow the link to your space in the Mondoo Console that looks something like this:

See more scan results and asset relationships on the Mondoo Console: https://console.mondoo.com/space/fleet/1KnZA3cAE1GHRTzU3s64Dw4QWERAu?spaceId=spicy-fisher-123456

‍

2. Select the Policies tab.

3. Select ADD A POLICY and type Google Kubernetes into the search field. Enable the CIS Google Kubernetes Engine (GKE) Benchmark - Level 1 by selecting the Enable icon (a bar graph).

After enabling the policy, return to your shell and scan your project:

cnspec scan gcp project <your-project-name>

Tip: If you use the -o full option, you can see the details of all failed checks directly in the shell.

cnspec scan gcp project <your-project-name> -o full

The output below shows one of the failed checks and points to the service account that the GKE hack relies on to succeed.

 ✕ Fail:  F  5  Ensure GKE clusters are not running using the Compute Engine default service account
  Query:
    gcp.project.gke.clusters.map(
      nodePools {
        config.serviceAccount {
          serviceAccountsNodepools = 'serviceAccount:' + email
          gcp.project.iamPolicy.where(
            _.role != "roles/logging.logWriter" &&
            _.role != "roles/monitoring.metricWriter" &&
            _.role != "roles/monitoring.viewer"
          ).map(members).none(
            _ == serviceAccountsNodepools
          ) serviceAccountsNodepools
        } name
      }
    )

  Result:
    gcp.project.gke.clusters.map: [
      0: [
        0: {
          config.serviceAccount: {
            serviceAccountsNodepools: "serviceAccount:lunalectric-xxxx-node@project-name.iam.gserviceaccount.com"
            [].none(): false
          }
          name: "lunalectric-pool"
        }
      ]
    ]

Now, with the policy enabled, return to the Mondoo Console to see the results of all checks in that policy. You can explore further from there.

Further useful commands to check your GKE infrastructure

Scan Kubernetes manifests

You can scan Kubernetes manifests to find potential vulnerabilities before deploying them in your clusters:

cnspec scan k8s --path ../assets/escape-to-node.yaml

Here are the results of a scan of the Pod manifest that led to the takeover of the node:

Scan the GKE Cluster

cnspec scan k8s scan

More Exploits and Platforms to Explore

Expand your Kubernetes hacking adventure with Mondoo by trying out our provider labs:

• Google Kubernetes Engine (GKE)
• Microsoft Azure Kubernetes Services (AKS)
• Amazon Elastic Kubernetes Service (EKS)
• Minikube

Follow the tutorial in each lab's README file for a unique hacking experience with different cloud providers.

Strengthen Your Security Posture with Mondoo's Kubernetes Container Escape Labs

With Mondoo's Kubernetes Container Escape Labs, you can learn how to secure your GKE clusters from potential breaches. By understanding the attacker's perspective and using Mondoo's powerful tools, you can effectively protect your infrastructure from similar attacks. Don't forget to explore other exploits and platforms with Mondoo to expand your knowledge and experience. Happy hacking!

‍