Part 6 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Credential Access

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

(This is Part 6 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 sixth tactic described in the MITRE ATT&CK framework for Kubernetes - Credential Access)

In the last post, we saw the techniques in the Defense Evasion tactic of the MITRE ATT&CK framework for Kubernetes. Let's look at the next tactic, Credential Access 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

Credential Access

Once the attacker has planted their feet firmly within the cluster, escalated privileges, planted backdoors and evaded defenses, it's time for them to move after data and credentials. We will cover data discovery and access in the next blog post while looking at the Credential Access tactic in this one.

Kubernetes, like any other software system with multiple moving parts, has data that needs protecting. This could be secrets stored as part of the cluster, database or app credentials which are part of the application or even cloud credentials for managed clusters. The Credential Access tactic of the MITRE ATT&CK framework talks about some of the techniques that an attacker could employ to steal secrets and credentials from the cluster and reuse them to move to protected systems within the cluster or outside it.

List Kubernetes secrets

A K8S secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. An attacker with the ability to list secrets within the cluster would be able to retrieve the secret(s) and compromise additional resources accessible from their vantage point.

List secrets in Kubernetes

Secrets created using literal values, files or directories in Kubernetes get stored as base64 encoded strings within the datastore and can be readily reversed to plain text.

Mount service principal

When Kubernetes is run in a managed environment like GKE or AKS, there is a service principal that is shared between the cloud platform and the Kubernetes cluster to allow the cluster to be managed using permissions of the cloud user.

This technique is the an overlap of the Access cloud resources and essentially covers ways by which an attacker within a cluster can gain access to credentials that would give cloud platform access.

For example, when setting up Kubernetes in Azure via AKS, if the service principal means of Authentication is chosen so that Azure Kubernetes Service can manage cloud resources attached to the cluster, then the service principal becomes accessible via the /etc/kubernetes/azure.json file on each of the nodes in the cluster. An attacker gaining access to the node would be able to elevate access to the Cloud platform by stealing these credentials.

Azure service principal access

Access container service account

By default, a service account is mounted to every pod in a Kubernetes cluster at /var/run/secrets/kubernetes.io/serviceaccount/ as a tmpfs file system (destroyed when pod is deleted).

Cluster access to Kubernetes API

This service account token is available via /var/run/secrets/kubernetes.io/serviceaccount/token.

An attacker who gains access to a pod can obtain the service account token. If Kubernetes RBAC is not enabled, the service account token will grant the attacker full access to the cluster or with RBAC enabled, privileges would be determined by role bindings. An attacker can use this token to gain access to the cluster resources.

Cluster access to Kubernetes API with token

Application credentials in configuration files

Developers may store tokens or credentials within environment variables or as configuration data with a pod spec. Attacker would be able to access these secrets by accessing the configuration files or by accessing the API to reveal these secrets.

Credentials in environment variables of container

Conclusion

Credential access is an attacker's attempt to find secrets and tokens that can be used for movement between resources within the cluster. More often than not, credential reuse or weakly protected secrets lead to additional compromise within the cluster and the cloud platform.

In the next post we will see how attackers attempt to discover what's present once access is obtained, privileges are escalated and credentials are stolen so that a map can be built of what else can be attacked within the cluster, using the framework as our guide.

References

More Articles

IAM Bad: Privilege Escalation using Misconfigured Policies in AWS IAM (Webinar)
Posted by
Riyaz Walikar
on
May 6, 2021

A walkthrough of the slides covered as part of our Star Wars Day special webinar on IAM policy misconfigurations that can lead to privilege escalations and a takeover of the target AWS account.

Read More
DeveloperWeek Europe 2021 - Walkthrough of the Talk slides and Audience Questions
Posted by
Riyaz Walikar
on
April 29, 2021

A walkthrough of the slides covered as part of the DeveloperWeek Europe 2021 virtual conference, attack details and answers to questions that were asked during the talk.

Read More
Who else is in your pod? - Walkthrough of the KubeSec Enterprise Online Talk
Posted by
Riyaz Walikar
on
April 8, 2021

A walkthrough of the slides covered during the KubeSec Enterprise Online 2021 talk with details of the attacks covered and tips and tricks to harden your Kubernetes cluster.

Read More

Ready to give Kloudle a try?

We help you monitor and prevent any data breaches.

Let's Talk