___

Products & Services Topics Industry Content Type

Resource Menu

All (https://www.cyberark.com/resources) » Threat Research Blog (https://www.cyberark.com/resources/threat-resear…

Kubernetes Pentest Methodology Part 2

Or Ida | 9/5/19 Share This!    

Attacking the Cluster Remotely

In our previous blog post “Kubernetes Pentest Methodology Part 1” (https://www.cyberark.com/?

p=71725), 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 (https://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.

What can I help you with today?

(https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-1.png)
Figure 1 Crt.sh search engine results

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
(https://github.com/) 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.

(https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-2.png)
Figure 2 Github search results

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 (https://github.com/calinah/learn-

by-hacking-kccn/blob/master/Learn%20by%20Hacking.pdf)) might be open in a Kubernetes cluster:
 (https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-3.png)
Figure 3 Popular open ports

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,”
(https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/#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.

(https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-4.png)
Figure 4 cAdvisor web interface

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>

(https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-
fig-5.png)
Figure 5 Kubernetes API endpoints

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 (https://github.com/etcd-
io/etcd/blob/master/etcdctl/READMEv2.md) 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.

(https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png)
Figure 6 Kublet information exposure

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.
Share This!    

(https://www.cyberark.com/resources/threat-research-
Previous Article (https://www.cyberark.com/resources/threat-research-
Next Article
blog/eight-ways-to-create-a-pod)
Eight Ways to Create a Pod
blog/krypton-stealer-kryptonite-for-credentials)
Krypton Stealer – Kryptonite for Credentials

RECOMMENDED FOR YOU

Your NVMe Had Been Syz’ed: Crumbled Security: Unmasking The Hacker’s Guide to The A Deep Dive
Fuzzing NVMe-oF/TCP Driver the Cookie-Stealing Malware Cosmos (SDK): Stealing Testing of m
for Linux with Syzkaller Threat Millions from the Blockchain (Part 3)

Read Article  Read Blog  Read Blog  Read Blog 

RETURN TO HOME

(HTTPS://WWW.CYBERARK.COM/RESOURCES)

Support Resources Partners Company