15. Research typical and known vulnerabilities in cloud

Introduction

HackTheBox is a platform used by red-team pentesters to hone their skills and generally have fun practicing their craft. They offer a virtual platform, in which there are various boxes or machines varying from difficulty. During the last few weeks of November, they hosted the Uni 2021 CTF. I joined this CTF with my team and worked on two challenges. One being a Jenkins application, the second – which we will be focusing on in this page is the SteamCloud Kubernetes challenge. In case you didn’t know, Kubernetes is considered a cloud platform thus it perfectly fit within the assignment.

Execution

While working on another machine within the CTF I accidentally wiped my own Kali setup due to running a script that I shouldn’t have ran which ended up wiping my /etc/shadow & /etc/passwd I though rebooting could solve it… but it didn’t, and that’s why I don’t have a lot of screenshots this time around.

Enumeration

I began this challenge by doing basic enumeration, nmapping a wide range and found a specific port very high indicating that it was a Kubernetes swarm; that port being in the range of 8443 and google showed me that kubernetes was usually found on this port.

Diving in

After a lot of enumeration I installed a tool called kubectl that allowed me to connect to the kubernetes swarm. My other team member was working on the network map while I continued to seek the exploits through trial and error. I have a few snippets of my snapshotted machine indicating my attempts:
https://i.imgur.com/Dps285F.png
As you can see, at one point it became obvious that this exploit permitted command injection. I tried setting up a reverse shell for it to connect to, but it wouldn’t accept any of the commands outside of the commands found in the help end point.
https://i.imgur.com/DtBsbs0.png
At this point, I found a certificate on the server I could use to bypass the limitation of commands permitted in the above examples. This was veeery trial and error, as you can see.
https://i.imgur.com/fIl608l.png
Since I tried sideloading my own certificate in via filepaths before, I decided to hardcode it into the payload. After a while I discovered the kubectl tool and began seeing good results.
https://i.imgur.com/eNygRSQ.png

Failure

The lead ran cold, I’ve tried a lot of further enumeration but I won’t show you as it was very trial and error. I decided that this machine was going to be too complex for me, but I did learn a lot already about cloud vulnerabilities and exploitation/enumeration of these environments. I looked up a write-up way after the event and discovered that one of my commands:
kubectl --token=`cat /var/run/secrets/kubernetes.io/serviceaccount/token` --certificate-authority=`cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt` --server=https://10.192.96.98:8443 get pods
Would actually list you one of the vulnerable pods found within the kubernetes swarm – this one was prone to command injection. I was so close to finding it, it was a bit silly finding out afterwards how f— close we actually were. The Uni CTF by HtB is very challenging, my team and I spent three days together from early in the morning until very early in the morning the next days for most days and we managed to crack about five challenges out of the thirty or so present – one of the challenges I managed to solve was the Jenkins challenge; which I got the flag of in about an hour or so of trying. This really humbled me, and taught me that even though I might excel in certain red team parts, competitively joining one of these CtF against world renown universities shows areas in which I still lack.