February 8, 2021

Part 7 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Discovery

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

Table of Contents

Introduction

Discovery

     Access the K8S API server

     Access Kubelet API

     Network Mapping

     Access Kubernetes Dashboard

     Instance Metadata API

Conclusion

References

Introduction

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

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

Discovery

Although, this tactic comes a little later in the MITRE ATT&CK framework, Discovery is an important stage in the attacker's plan. Being able to identify what is running within the cluster, performing network identification, accessing the kubelet for additional cluster information or even pulling information from the instance metadata endpoints amongst managed clusters is key in identifying what areas of the cluster should be attacked and others that can be de-prioritized.

At this point in the attack chain, the attacker is assumed to have credentials to various parts of the cluster and/or apps from the previous tactic and are actively using them to gain additional visibility.

Access the K8S API server

The Kubernetes API is one of the most critical components of the control plane and allows users to perform cluster operations across all resources. You can interact with the Kubernetes API server using the kubectl binary or using a user-agent like cURL. An attacker that gains access to the kubernetes API server can perform various administrative actions on the cluster and get information about nodes, pods, apps, services, secrets and much more.

kubectl listing pods

Access Kubelet API

This attack technique is based on access to the kubelet, which is a go binary that runs on every node in the cluster, including the master node/control plane.

The kubelet is responsible for the execution of pods and manages container resources. In versions post v1.10 of the kubelet, multiple command line arguments were passed via a configuration file, one of which was the value for --read-only-port. This option is now deprecated and (unless explicitly set via the config file) defaults to 0..

Prior to v1.10, kubelet by default listened on TCP port 10255 and responded with an unauthenticated read-only API service that could be used to obtain pod and container information.

An attacker having compromised an app and now with access to the pod (on a cluster where kubelet version is older than 1.10) could query the API endpoint and leak information.

Network Mapping

By default, if NetworkPolicy is not applied,pods can communicate with each other across nodes. An attacker who gains access to a pod and has the ability to run commands could potentially port scan the pod network and discover additional internal apps that are not visible to the Internet.

An attacker may not require complete shell access to achieve port scanning. Depending on the application that was compromised, it may be possible to use the application itself to perform port scanning using the apps server side code.

Access Kubernetes Dashboard

Although the more popular way of managing a Kubernetes cluster is using the kubectl binary, there exists a Kubernetes Web UI dashboard that can be deployed and which can be used to manage and troubleshoot the cluster and deploy containerized applications.

kubernetes dashboard

If the dashboard is deployed within a cluster, it may be possible for an attacker to gain access to it by proxying requests from a compromised pod. In cases where the network policies have been configured to give access to the dashboard from outside the cluster, it may result in additional unwanted access. An Internet wide sweep for dashboards in June 2018 showed that over 20,000 dashboards were misconfigured and publicly exposed.

Instance Metadata API

In managed kubernetes environments, cloud providers expose a non-routable endpoint (169.254.169.254 across GCP, Azure and AWS) that can be used to fetch metadata about the instance on which the cluster nodes are running. Across GCP, Azure and AWS, there exist extensive documentation on the structure of the instance metadata endpoint and what requests need to be made for fetching specific kinds of information.

An attacker with access to a pod would be able to access the instance metadata information, potentially leaking cluster information including secrets and various resource configuration. For example, an attacker can traverse the instance metadata API endpoint in Azure with a cURL request as shown below

Azure instance metadata being accessed via a compromised pod

Conclusion

With the Discovery tactic, an attacker attempts to gain as much visibility within the cluster as possible. Due to RBAC and default secure configurations, the attacker may use credentials obtained using previous tactics to walk around the cluster mimicking an authenticated user. On managed clusters, additional cloud platform related information can also get leaked resulting in a cluster escape.

In the next post we will see how attackers attempt to move laterally within the cluster or even attempt to escape to the cloud platform layer when we look at the Lateral Movement 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