Gaining Initial Access in a Kubernetes Environment (part 2)

In the last article ‘Exploring Kubernetes Architecture from an Offensive Viewpoint’ we touched on some of the fundamentals necessary to understand, when attacking from an Offensive Viewpoint.

In this article we will explore Initial Access techniques and procedures and how attackers may use them to gain a foothold in the Kubernetes cluster.

We will base this on the Threat Matrix for Kubernetes from Microsoft.

Image source: https://www.microsoft.com/en-us/security/blog/2020/04/02/attack-matrix-kubernetes/

From personal experience I encountered most often the ‘Application vulnerability’ and ‘Compromised images in registry’ tactics. So let us start with these!

Application Vulnerability

Applications in Kubernetes run in containers. From an offensive angle this means compromising the container of a running application will give us initial access in the cluster (or pod).

source: https://kubernetes.io/docs/concepts/workloads/pods/#what-is-a-pod

Obtaining remote code execution (related to MS-TA9009) on an application will give you command line access to the container. As in Kubernetes a pod shares (some of) its resources with the containers that are part of the pod, you may find useful information from within the container that allows you to further enumerate the Kubernetes Cluster.

Exploitation of the Application is not limited to RCE, other vulnerabilities such as local file inclusion (LFI) also can give you initial access to the cluster, for example, if you are able to read the service accounts token and the Kubernetes API server is exposed over the internet.

The compromise of the application most likely won’t differ very much from exploiting any other application in the wild.

Compromised image in registry

Different from exploiting a running application in a pod, a malicious image is more tailored to exploiting Kubernetes or any other framework that works with containers. There are different ways how to approach this from an offensive angle, one could gain access to a valid image and patch it with malicious intent or create his own malicious container that will be hosted in a registry accessible by the target. Deployment of the containers could be through social engineering exercises or exposed functionality that allow you to make a deployment in the cluster (related to MS-TA9008).

Procedures

CovertSwarm developed a simple proof-of-concept container that was hosted on a registry accessible by the target and contains configuration to spawn a backdoor on deployment and execution. 

Read more on how to create a docker container.

On deployment this container would execute the file that is located at /root/bd.py periodically.

This file contained the malicious code that would spawn a simple reverse shell to gain access to the pod after being deployed in the Kubernetes environment and connect back to CovertSwarm’s systems.

Finally, this image needed to be pushed to the (private) registry and later deployed in the Kubernetes environment.

“`

docker tag [OPTIONS] IMAGE[:TAG] [REGISTRYHOST/][USERNAME/]NAME[:TAG]

docker push NAME[:TAG]

“`

Example of pushing an image to a registry:

“`

docker tag 518a41981a6a myRegistry.com/myImage

docker push myRegistry.com/myImage

“`

Source: https://stackoverflow.com/questions/28349392/how-to-push-a-docker-image-to-a-private-repository

Using cloud credentials

The next attack vector we will discuss here will be through the cloud environment in which Kubernetes was deployed. This could for example be through a phishing engagement where an employee entered his credentials that were valid for google cloud.

Source: https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/Using%20Cloud%20Credentials/

Procedures

In the following we will explore some of the procedures an attacker could use to enumerate the managed Kubernetes clusters in cloud environments.

We will focus on three big cloud solutions:

• Google Kubernetes Engine (GKE)
• Azure Kubernetes Service (AKS)
• Elastic Kubernetes Service (EKS)

Reconnaissance (GKE)

List the managed Kubernetes clusters in GKE

“`

gcloud container clusters list

“`

Setup details for the gcloud CLI can be found here

Setup the kubeconfig for kubectl (related to MS-TA9003):

“`

gcloud container clusters get-credentials [CLUSTER NAME] –region [REGION]

“`

And then get baseline information about the cluster.

“`

kubectl cluster-info

“`

Source: https://cloud.hacktricks.xyz/pentesting-cloud/gcp-security/gcp-services/gcp-containers-gke-and-composer-enum#kubernetes

Further reference: https://cloud.google.com/sdk/gcloud/reference/container

Reconnaissance (AKS)

List the managed Kubernetes clusters in AKS

“`

Az aks list

“`

Setup the kubeconfig for kubectl (related to MS-TA9003):

“`

az aks get-credentials –name MyManagedCluster –resource-group MyResourceGroup

“`

Get baseline information about the cluster:

“`

kubectl cluster-info

“`

Further reference: https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest

Reconnaissance (EKS)

List the managed Kubernetes clusters in EKS

“`

aws eks list-clusters

“`

Setup the kubeconfig file for kubectl (related to MS-TA9003)

“`

aws eks update-kubeconfig –region region-code –name my-cluster

“`

Get baseline information about the cluster:

“`

kubectl cluster-info

“`

Further reference: https://docs.aws.amazon.com/cli/latest/reference/eks/#cli-aws-eks

Kubeconfig file

Attackers who manage to get a hold of a kubeconfig file may get an initial foothold on the organizations Kubernetes cluster. The kubeconfig file contains information (including credentials) to connect and authenticate to its associated  cluster. 

A compromise of this file may happen through social engineering exercises such as phishing or other attack vectors like leakage of this file in a public repository or an insider threat exposing this config willingly.

Below an example kubeconfig file (usually located at .kube/config in the home directory)

“`

apiVersion: v1

clusters:

– cluster:

    certificate-authority-data: <ca-data-here>

    server: https://your-k8s-cluster.com

  name: <cluster-name>

contexts:

– context:

    cluster:  <cluster-name>

    user:  <cluster-name-user>

  name:  <cluster-name>

current-context:  <cluster-name>

kind: Config

preferences: {}

users:

– name:  <cluster-name-user>

  user:

    token: <secret-token-here>

“`

Source: https://devopscube.com/kubernetes-kubeconfig-file/

Procedures

This file may be used by the kubectl binary or through direct communication with an exposed Kubernetes API Server via HTTP/S request. The Kubernetes API server also can be located by reviewing this config under the ‘server’ attribute (also see directly accessing the REST API).

• The ‘server’ attribute may be configured for a local IP address, which does not mean the API server is not accessible through an external IP address as well (related to MS-TA9005).

Read more on Access Clusters Using the Kubernetes API.

Exposed sensitive interfaces

A lot of Kubernetes services were built without the intention to make them publicly accessible, meaning no strong authentication mechanism is in place. Exposing these services to the outside anyways poses a risk to the whole environment as an attacker can access these sensitive services to gain a foothold in the cluster.

One example of this would be the kubelet API without authentication enabled. This immediately enables an attacker to execute a command within a pod in the environment and may lead to the compromise of multiple nodes.

Other examples include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard.

Conclusion

In this article we discussed different initial access techniques to gain a foothold in a Kubernetes cluster. We touched on the compromise through a vulnerable application, using cloud credentials to enumerate and gain access to configured clusters, impact of leaking a kubeconfig file and risk of exposing sensitive services of the Kubernetes cluster. In the next blog piece, we will do a deep dive into the different sensitive services and how to compromise a cluster exploiting these.

For those seeking expert assistance in identifying and addressing vulnerabilities within their Kubernetes environments, CovertSwarm offers specialized Kubernetes vulnerability scanning services. Don’t hesitate to reach out to our team for tailored support and guidance.

Author: Maximilian Kleinke