January 28, 2021

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

This is the sixth part of a nine part series on the MITRE ATT&CK framework for Kubernetes, covering the Credential Access tactic with examples.

Table of Contents

Introduction

Credential Access

     List Kubernetes Secrets

     Mount Service Principal

     Access Container Service Account

     Application Credentials in configuration files

Conclusion

References

Introduction

(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

***

This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.

Written by:
Riyaz Walikar

Riyaz Walikar

Chief Hacker

Riyaz is a security evangelist, offensive security expert and researcher with over a decade of experience in the cyber security industry. His passion to break into some of the most well defended networks and systems in his career spanning 15 years has earned him a lot respect within the security industry. He has led Security Assessment and Penetration Testing teams at Pricewaterhouse Coopers (PwC) and Appsecco, and the Product Security Team at Citrix before co-founding Kloudle. Riyaz now specializes in cloud native, container and cloud security in general, helping build an easy to use security management platform to help companies enhance their visibility in the cloud, identify security misconfigurations and automate remediation for security gaps enabling compliance and operational security in multi-cloud environments. He is also an avid speaker and trainer and presents his research and findings at security conferences and community meetups around the world including BlackHat USA, BH Europe, BH Asia, nullcon and OWASP AppsecUSA.Specialties: Cloud (AWS, GCP, Azure, IBM, Others) Security, Cloud-Native Security, Kubernetes, Container Security, Web Application Security, Network and System Penetration Testing, Wireless Network Security, Malware Analysis and Reverse Engineering, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering. Certifications: CKA, CKAD, OSCP

Read more