Attacking the Cluster Remotely
In our previous blog post “Kubernetes Pentest Methodology Part 1”, we wrote about the risks that might be created by misconfiguring the Kubernetes RBAC. Also, we demonstrated the attack vectors that could lead to privilege escalation.
In this part, we will focus on the attack vectors from the perspectives of a remote attacker and a black-box pentester. Usually, in black-box tests, we will not have any access to or early information about the Kubernetes cluster we will be testing and, because of that, we will need to combine different attack techniques.
Before we dive in, it’s important to keep in mind that we might face a variety of different situations when interacting with the Kubernetes API, depending on how the administrators chose to configure the cluster. There may be extreme situations where the API is exposed to unauthorized access. On the other hand, there may be situations where the Kubernetes administrators prefer to use a certificate authority to manage the Kubernetes cluster remotely and, consequently, we won’t be able to interact with the Kubernetes API at all.
In any case, we will need to focus on what was exposed to the outside world on purpose in order to find our way in. From my experience in the cybersecurity world, there are always surprises, so, we should always check ahead and be there at the right time.
Seeking for Exposed Services
Kubernetes is a container orchestration platform, which means that administrators can expose services to remote users, including web apps and any other services that require internet access.
If we cannot interact with the Kubernetes API, the exposed services are our only way in. So, we need to use different reconnaissance tools to investigate what is standing in our way.
1. Subdomain Enumeration
When a Kubernetes “pod” is exposed to the outside world, it might have a FQDN address to help users interact with its services. As remote attackers, we should first find out those names and explore them.
This technique is called “subdomain enumeration” and it is part of the “passive” reconnaissance phase. There are a lot of services and tools that automate this process and you can pick your favorite option.
For example, you might use “crt.sh,” which is a great service that uses a certificate search technique to search for exposed subdomains.
Figure 1 gives an example of different domains that might expose their pods to the outside world.
2. Searching for Sensitive Information or Configuration Files in Github
This technique is also part of the “passive“ reconnaissance phase.
Developers and administrators frequently save their projects in git repositories. Github is a well-known platform for uploading configuration files and other files that might contain sensitive information. As penetration testers, we should find out if Github has information that might help us with our test.
Figure 2 provides an example of YAML files in different Github projects.
3. Port scanning – External Port Visibility
Port scanning is one of the first steps in the active reconnaissance phase. We should always examine every open port we can access.
The following ports (taken from a Kubernetes workshop presentation) might be open in a Kubernetes cluster:
4. Exploring Network Plugins
Every environment has its own goals and, because of that, exploring network plugins can be a different experience for every system.
A classic example of a network plugin that you may come across is the “cAdvisor,” a containers monitoring tool. If this service can be accessed remotely, you will find it immediately in your scan results.
Figure 10 is an example of the cAdvisor web interface, which can be accessed remotely to expose information regarding the container’s users and CPU usage.
Seeking for Cluster Misconfiguration Remotely
This section is useful when the Kubernetes API is exposed to remote interaction.
1. Checking Anonymous Access to the API Server
By default, API endpoints are forbidden to anonymous access. But it’s always a good idea to check if there are any insecure endpoints that expose sensitive information (Figure 5.)
https://<master_ip>:<port>
2. Checking for ETCD Anonymous Access
You can think of the “ETCD” component as the Database of the Kubernetes cluster. The ETCD stores the cluster secrets, configuration files and more sensitive data. We will definitely want to attack this critical component.
By default, the ETCD cannot be accessed anonymously, but it always good to check.
If the ETCD can be accessed anonymously, you may need to use the etcdctl tool. The following command will get all the keys stored:
etcdctl –endpoints=http://<MASTER-IP>:2379 get / –prefix –keys-only
3. Checking Kubelet (Read Only Port) Information Exposure
When the “kubelet” read-only port is exposed, the attacker can retrieve information from the API. This exposes cluster configuration elements, such as pods names, location of internal files and other configurations. This is not critical information, but it still should not be exposed to the internet.
For example, a remote attacker can abuse this by accessing the following URL:
http://<external-IP>:10255/pods
As you can see in Figure 6, internal files and pods name are exposed.
Summary
When you follow best security practices and deploy it properly, Kubernetes can be highly secure and capable of defending the Kubernetes API server from remote attacks. But, not everyone remembers to follow the best practices or deploy the server correctly. These are the weaknesses that attackers exploit and that we – as black- and gray-box pentesters – need to find before the attackers do. In the second part of of the Kubernetes penetration test methodology blog series, we demonstrated some of the attack vectors that you need to address as a black\grey-box pentester. We hope this blog will help to increase security awareness when exposing the Kubernetes cluster to the world.
In the next part of this series, we will discuss attack vectors for the insider attacker.
