(This is Part 1 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 overall MITRE ATT&CK framework and dives into the first tactic - Initial Access)
Application architecture, data flows and compute infrastructure have undergone a massive shift in recent years. As more and more developers move from monolithic architectures to microservices, robust mechanisms required to deliver a transparent underlying infrastructure are being accepted as the way forward for modern apps. Moving applications away from self hosted data centers to cloud services to now container rich production ready environments comes at a price of constantly changing attack surface dynamic.
With the acceptance of Kubernetes as an industry standard container orchestration system that is now on the way to becoming the standard way for automating the building, deployment and management of cloud-native applications, it becomes even more important for infrastructure administrators, developers and app owners to understand the changes in attack surface that come with adopting new and rapidly growing technologies.
A recognized enterprise way of mapping an environment’s attack surface and to understand the risks that the infrastructure in question is exposed to, is to use the Enterprise Matrix from the MITRE ATT&CK framework. In their own words, “MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community”.
How does one apply this adversary tactics and techniques based approach to Kubernetes environments? Well, Microsoft actually created a Kubernetes specific attack matrix based on the MITRE ATT&CK framework early last year. Let’s take a look at the matrix and understand how we can use it to understand our cluster security better.
The MITRE ATT&CK framework is a knowledge base of known tactics and techniques that are involved in cyberattacks. Any potential attack that can be launched on a target with an applicable technique to achieve the attack would broadly fall into one of the following tactic
If you look closely at the mentioned tactics, the language used to describe the attack tactics can actually be applied to different software or platforms with only the underlying techniques changing based on what is being attacked. Any attack narrative that you would pick up, would eventually fit into one of the attack tactics. For example, “password cracking” could be a technique under Initial Access or Privilege Escalation or Lateral Movement.
Microsoft applied the same thought process and created what we now know as the ATT&CK Matrix for Kubernetes. Here it is presented in its visual form
Let’s understand what each of the tactics and the applicable underlying technique mean and how you can visualise this for your Kubernetes cluster environments.
The first attacker tactic is to gain Initial Access to the cluster. For an attacker to successfully launch attacks against a specific service within your cluster, the surface area of the cluster should allow an attacker to reach and interact with it. This is why one of the more popular (although not the most productive/correct) way of mitigating attacks on the Internet has been to put stuff behind firewalls. This gives rise to the “if the attacker cannot see it, they cannot attack it” philosophy. With Kubernetes it is no different. As long as an attacker is able to reach and interact with the cluster, the underlying cloud infra (for managed clusters), any services or applications running in the cluster and accessible to an attacker or usage of components within the cluster that may already be back-doored can provide the initial foothold that an attacker needs to perform additional exploitation. The matrix lists the following techniques under this tactic
For managed clusters on a public cloud (for example, AKS in Azure, GKE in GCP, or EKS in AWS), access to access keys, secrets or plain old passwords to the cloud provider could mean the ability to manage and access clusters running on the cloud. For example, if a developer’s AWS IAM access key and secret are leaked via a code repository and if they provide account wide access to the cloud, these can be used to take over any running clusters within the cloud environment.
For most workloads, enterprises may implicitly trust the source of the images that are being pulled into the cluster. As an image runs within the cluster post deployment, any malicious code within the image will have access to the data, network and potentially secrets within the cluster. As an attacker, compromising a registry to plant a malicious image could allow an attacker immediate foothold within the cluster when the image is pulled and run as a container.
Additionally, apart from deliberately compromising a registry to plant malicious code, it is also possible that over a period of time, new software vulnerabilities or configuration weaknesses are discovered that become a cause for concern since the images uploaded to registries are not updated/patched as frequently as they should be.
This is far more common in the real world than it sounds to be, for example, a dynamic analysis of the publicly available images on Docker Hub found that 51% had critical vulnerabilities and about 6,500 of the 4 million latest images could be considered malicious.
The kubeconfig file contains the JWT user token and the server IP/hostname of the master node that allows tools like kubectl to interact with and manage the cluster. Depending on the provider or the Kubernetes variant, these credentials are found in different locations on the system with the most common locations being the $KUBECONFIG environment variable, the ${HOME}/.kube/config file or the /etc/rancher/k3s/k3s.yaml in case of K3S. Access to managed clusters is usually obtained using the configuration generated using cloud specific commands like gcloud container clusters get-credentials for GKE, for example.
Access to this file would allow access to the cluster unless access to the master node IP is whitelisted at the network layer.
This is perhaps the most common technique that attackers employ to gain access to a target cluster. A vulnerability in a network aware application (like FTP) or a web application could allow an attacker to run commands on the container hosting the application. Vulnerabilities of this type are called Remote Code Execution vulnerabilities. Some examples include default credentials to administrative portals, the ability to upload arbitrary server-side executable files (like .php, .aspx or ,jsp), a command injection weakness or the insecure usage of deserialisation.
Once the attacker is within the container, additional access to the cluster using mounted service accounts or IAM credentials could become possible.
The Kubernetes dashboard is a web-based user interface that can be used for monitoring and managing a Kubernetes cluster. The dashboard is usually not enabled by default and when enabled, is accessible only within the cluster as an internal endpoint via a Kubernetes ClusterIP service without any authentication. If the dashboard is exposed externally, it may allow unauthenticated remote management of the cluster. The dashboard based on the credentials with which it is running, may also provide a way to gain access to the underlying cloud infrastructure for managed clusters resulting in an additional cloud platform compromise.
An internet wide scan, conducted in early 2018 for Kubernetes dashboards exposed to the Internet identified an alarming number of them accessible without credentials.
A recurring theme in security regardless of infra, app or platform is attack surface visibility. The common notion that an attacker can only proceed if the target is visible holds true even with Kubernetes. However, like all systems with many moving parts, an attacker may exist outside the perimeter or within through a compromised config file or application. This post showed how the MITRE ATT&CK framework for Kubernetes discusses the Initial Access tactic and what techniques attackers could potentially utilise.
We shall see how attackers move from Initial Access all the way to Impact using the framework as our guide.
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.
