February 22, 2021

Part 8 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Lateral Movement

This is the eighth part of a nine part series on the MITRE ATT&CK framework for Kubernetes, covering the Lateral Movement tactic with examples.

Table of Contents

Introduction

Lateral Movement

     Access Cloud Resources

     Container Service Account

     Cluster Internal Networking

     Applications credentials in configuration files

     Access Kubernetes dashboard

     Access tiller endpoint

Conclusion

References

Introduction

(This is Part 8 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 eighth tactic described in the MITRE ATT&CK framework for Kubernetes - Lateral Movement)

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

Lateral Movement

Once an attacker has gained access to an environment, obtained privileges to reach regions that require authentication and discovered additional areas of the environment that can be reached from their current vantage point, they attempt to move to adjoining environments using multiple offensive techniques. This tactic is termed as Lateral Movement, although many of the techniques will usually move the attacker from the current plane of attack to a horizontal as well as vertical plane of attack.

Let's take a look at the techniques that attacker's use when applying the Lateral Movement tactic to Kubernetes environments.

Access cloud resources

This technique overlaps with the "Access cloud resources" technique covered under the Privilege Escalation tactic.

Essentially, an attacker is able to use service accounts or OAuth scopes that can be used to break out of the Kubernetes environment and move to the Cloud platform layer.

For an example of how a default cluster setup with GKE provides access to extra OAuth scope which an attacker uses to gain access to GCP Storage to read files, take a look at the "Access cloud resources" technique covered under the Privilege Escalation tactic.

Container service account

This technique also has an overlap with the "Access container service account" technique covered under the Credential Access tactic.

Attackers can use the mounted service account token found at /var/run/secrets/kubernetes.io/serviceaccount/token to gain access to the Kubernetes API. 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.

Container Token Access

Cluster internal networking

Kubernetes does not restrict traffic between pods in a cluster unless a NetworkPolicy has been applied. This default behavior can be exploited by attackers to reach pods running other applications once cluster access is obtained.

Kubernetes provides NetworkPolicy as a resource that can be used to implement granular access between namespaces, pods and even individual ports that are exposing services.

Applications credentials in configuration files

This technique overlaps with the the "Application credentials in configuration files" technique of the Credential Access tactic that we have written about before about.

Essentially, an attacker is able to access secrets that developers store in environment variables, app configuration files or the Kubernetes Secrets and ConfigMap store. Access to secrets allow access to additional resources that require authentication. In most cases, additional vulnerabilities or the ability to execute shell commands may be obtained via the new found access, allowing the attacker to jump networks or platform boundaries.

An example that we have covered in the Credential Access blogpost is of the following Pod yaml that contains MySQL DB credentials. An attacker can authenticate themselves to the MySQL DB store and gain access to restricted data using the new found access.

MySQL creds stored in yaml file

Writable volume mounts on the host

This technique overlaps with the "Writable hostPath mount" technique of the Persistence tactic that we have written before about.

Allowing unnecessary ability to write to volume mounts would allow an attacker to create or update files that could be used to obtain shell command execution capabilities.

Access Kubernetes dashboard

This technique overlaps with the "Access Kubernetes Dashboard" technique of the Discovery tactic that we have written before about.

An attacker who has access to the Kubernetes Dashboard may manage the cluster resources and would have the ability to run their code on the workloads running within the cluster using the "exec" functionality that the Dashboard provides.

Exec into Pod via Dashboard

Access tiller endpoint

Helm is a package manager for Kubernetes, maintained by CNCF. Much like how you can use pip or apt to install python and debian packages respectively, Helm is used to deploy resources within a Kubernetes cluster.

Tiller is the server side component of Helm, up until version 2. Helm is currently at 3.5.0 (helm version), so this technique no longer applies for versions beyond 2.

Tiller exposes an internal gRPC endpoint in the cluster which listens on port 44134. By default, this endpoint does not have RBAC. An attacker can connect to this endpoint using the helm client binary and "install" resources. For example, a Kubernetes resource can be created using a helm chart using the command

helm --host tiller-deploy.kube-system:44134 install <packagename>

Conclusion

With the Lateral Movement tactic, an attacker attempts to gain additional access moving to different resources within the cluster or finding ways to move out of the cluster into the Cloud platform plane. Multiple techniques used in the tactics covered thus far can be repurposed to move laterally within the cluster.

In the next and final post of this series, we will see the impact an attack can have on data, access and the cluster itself when we look at the Impact tactic of the MITRE ATT&CK framework.

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