Part 4 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Escalation

Posted by
Riyaz Walikar
on
January 18, 2021
· 4 min read

(This is Part 4 of a 9 part blog series that explains the Kubernetes MITRE ATT&CK like Threat Matrix created by Microsoft from an attacker perspective and attempts to provide how real world attackers use the techniques covered in the framework to gain access, execute, persist and explore Kubernetes cluster environments.)

Use this index to navigate to and read the rest of the posts in this series

(This blog post discusses the fourth tactic described in the MITRE ATT&CK framework for Kubernetes - Privilege Escalation)

In the last post, we saw the techniques in the Persistence tactic of the MITRE ATT&CK framework for Kubernetes. Let's look at the next tactic, Privilege Escalation and the techniques that attackers use within this tactic. For reference, here's the framework that Microsoft created as a visual cue to the overall tactics and techniques that attackers use when attacking a Kubernetes cluster.

Kubernetes ATT&CK matrix

Privilege Escalation

Attackers seldom gain privileged access to targets upon exploitation. Services and applications are supposed to run as a lower privilege user to avoid any unnecessary violations of security boundaries. Privilege escalation is a very common tactic that attackers employ to gain additional access either to a system that is connected to the exploited endpoint or vertically to a different user level to gain access to restricted data or features.

Privileged container

A privileged container allows a process to access the underlying host with all of the root capabilities of the host machine. This gives the container the ability to view, interact and modify processes, network operations, IPC calls, file system access, mount points, SELinux configurations etc. as the root user on the host.

The following yaml will start a privileged container and allow the attacker to jump to the host.

apiVersion: v1
kind
: Pod
metadata
:
name: privileged-ubuntu
 labels
:
app: privileged-ubuntu
spec
:
containers:
 - image: ubuntu
   command
:
     - "sleep"
     - "3600"
imagePullPolicy: IfNotPresent
   name
: ubuntu
   securityContext
:
capabilities:
add: ["NET_RAW", "NET_ADMIN", "SYS_ADMIN"]
runAsUser: 0
restartPolicy: Never
 hostNetwork
: true
hostPID: true

Privileged Ubuntu

In the container created using the above yaml, install capsh using apt-get install libcap2-bin and run the capsh --print command to see the container's capabilities.

Enabled privileges on container

An attacker may have the ability to launch a privileged container or may have found themselves inside an already running privileged container, in either case a privilege escalation would mean a container to host escape.

Cluster-admin binding

The cluster-admin role is an RBAC, default role created alongside Kubernetes and is a super-user user facing ClusterRole. It essentially allows for access to all Kubernetes APIs resources and verbs.

You can describe the role using the command kubectl get clusterrole cluster-admin -o yaml

cluster-admin role yaml

An attacker who has the RBAC permissions to create role bindings can create a binding to the cluster-admin role thus elevating their privilege from a Kubernetes user to a Cluster administrator.

hostPath mount

Apart from providing persistence within the cluster, the hostPath volume can be used to read/write to configuration files or access the container daemon (Docker for example on the host) on the host allowing the user to escape the container and perform additional host based attacks.

For example, consider the following yaml and the ability of a user to start a new pod in a specific namespace. An attacker could launch a container using the mount point as mentioned below and then chroot their way to the host.

apiVersion: v1
kind
: Pod
metadata
:
labels:
run: attacker-pod
 name
: attacker-pod
spec
:
hostPID: true
hostIPC: true
hostNetwork: true
volumes:
 - name: host-fs
   hostPath
:
path: /
 containers
:
 - image: ubuntu
   name
: attacker-pod
   command
: ["/bin/sh", "-c", "sleep infinity"]
securityContext:
privileged: true
allowPrivilegeEscalation: true
volumeMounts:
   - name: host-fs
     mountPath
: /host
 restartPolicy
: Never

You can read about this in more detail at https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216

Access cloud resources

Managed clusters running on cloud providers are setup in a way so that the user can manage the cluster using the cloud IAM access. For example, Azure uses a "service principal" token that is stored in AKS which is used to perform CRUD operations on the cluster. However, the way this token is created, it also has Azure contributor rights, allowing an attacker who manages to get hold of the token to interact with other Azure cloud resources.

You can also see similar behavior with Google GKE where the default cluster setup provides access to extra OAuth scopes that can be used to gain read access to GCP storage. This role, devstorage.read_only provides read access to buckets and files within them using a token that can be generated using the metadata endpoint.

List of available scopes for default cluster in GKE
Generating the SA token for the attacker
List buckets in GCP using token obtained from within the Kubernetes cluster

Conclusion

Ideally in most cases of offensive tactics, persistence and privilege escalation are often attempted side by side as the chances of having a far more robust persistence technique would potentially be through a privileged account. Multiple features within Kubernetes allow for users to escalate privileges and escape the container environment to access the hosts resources.

In the next post we will see how attackers evade defenses and hide their tracks within the compromised environment using the framework as our guide.

References

More Articles

An Attacker's Approach to Pentesting IBM Cloud - fwd:cloudsec 2021
Posted by
Riyaz Walikar
on
September 14, 2021

Slides of the talk presented at fwd:cloudsec 2021, titled - "An Attacker's Approach to Pentesting IBM Cloud". The talk contains examples of attack vectors, interesting things in IBM Cloud and future work to improve documentation.

Read More
Kloudle is a BlackHat USA 2021 Sponsor
Posted by
Akash Mahajan
on
August 4, 2021

From being trainers at BlackHat to sponsoring at the conference. A bit about our journey in brief.

Read More
You do not want to miss these talks at Black Hat USA!
Posted by
Riyaz Walikar
on
August 3, 2021

A list of talks in the Cloud Security and Platform domain that we have added to our must watch list of talks as the sheer number of sessions at the Black Hat briefings can be overwhelming!

Read More

Ready to give Kloudle a try?

We help you monitor and prevent any data breaches.

Let's Talk