(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.
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.
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.
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.
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.
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.
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.
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
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.
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.
