SteamCloud
So I've been doing some good old HackTheBox machines to refresh a little on my hacking skills and this machine was a very interesting one!
Exploitation itself wasn't particularly difficult; what was, however, was finding information on what I needed to do! Allow me to explain the process. :)
Enumeration
As is standard, I began with an nmap scan on SteamCloud:
Other than OpenSSH being outdated, all that I could really see was the use of various web servers. This led me to believe that there was a larger app running on the server, each service interacting with a different component of the app.
I performed some initial checks on each of these ports and found an API running on port 8443:
I noted the attempt to authenticate a user referred to as 'system:anonymous', originally thinking these could be credentials to another component of the application.
Some directory scans on different ports also revealed the presence of /metrics at port 10249 and /version at port 8443. Other than that, I really couldn't find anything and admittedly I was at a loss for a short while.
This is where I realized I'm an actual moron and didn't think to research the in-use ports. xD A quick search for 'ports 8443, 10250' returns various pages referring to Kubernetes. I can't remember precisely what page I checked but Oracle provides a summary of the components of a Kubernetes deployment.
Now that I had an idea of what was being used on the server, I was in a good place to dig further into what was exploitable.
Seeing What's Accessible
Knowing absolutely nothing about Kubernetes, I spent quite a while researching it and common vulnerabilities found in Kubernetes deployments. Eduardo Baitello provides a very informative article on attacking Kubernetes through the Kubelet API at port 10250.
With help from this article, I discovered that I was able to view pods running on the server, in addition to being able to execute commands on the kube-proxy and nginx pods. The nginx pod is where you'll find the first flag. I also made note of the token I discovered here, in addition to the token from the kube-proxy pod (though this isn't needed):
After finding these tokens, I did discover that the default account had permissions to view pods running in the default namespace through the API running on port 8443 (/api/v1/namespaces/default/pods) but I had no awareness of how this could be exploited.
If I had known Kubernetes and the workings of their APIs, I would have instantly recognised that this is the endpoint used to also add new pods to Kubernetes, but I didn't! Due to this, I wasted more time than I care to admit trying other things such as mounting the host filesystem to one of the pods I can access and establishing a reverse shell to one of the pods.
I did initially look at how to create new pods too; honestly there's very little documentation on using the API on port 8443 directly. Every example I looked at used kubectl, a commandline tool for managing Kubernetes.
Exploitation (Finally!)
After a while of digging, I finally came across a Stack Overflow page on adding a pod through the API on port 8443.
Along with this, I found a usable YAML file from Raesene in an article on Kubernetes security. I then converted this from YAML to JSON and added the pod after some minor tweaks.
My first attempt at adding a pod was unsuccessful- the pod was added, but the containers section was showing as null
However, it didn't take me long to see that this was due to the image I had specified in the original YAML file. I simply copied the image specified in the nginx pod to my YAML file and ended up with the following:
I saved the json output to a file named new-pod2.json and added the second pod.
curl -k -v -X POST -H "Authorization: Bearer <nginx-token>" -H "Content-Type: application/json" https://steamcloud.htb:8443/api/v1/namespaces/default/pods [email protected]
This time, the pod was added successfully and I was able to access the host filesystem through 'le-host'
The Vulnerability
The main issue here that made exploitation possible was the ability to access the Kubelet API on port 10250 without authorization. This should not be possible. AquaSec provide a useful article on recommendations for Kubernetes security.
Conclusion
SteamCloud was a relatively easy machine to exploit; what was difficult was finding information on the Kubernetes APIs and how to perform certain actions. It is one of those that someone with experience in the in-use technologies would have rooted in a matter of minutes; for a noob like me, the process wasn't so straightforward, particularly with information on Kubernetes being a little difficult to find! I've only recently returned to hacking, however, which might have contributed to my potential lack of Google Fu here. ^-^
I very much enjoyed the experience, however, and feel I learned the fundamentals of testing a Kubernetes deployment which I can imagine will be useful at some point in my future!
