This year's (2024) Area41 security conference was amazing as always. One of the sponsors, Redguard AG announced a Kubernetes CTF challenge to be solved during the conference. My k8s knowledge being very limited, and the offered prizes looking awesome, I decided to take my chances. Unfortunately, I gave up before achieving the solution, because it had already stolen too much sleep. I still wanted to document the process to capture the gained knowledge for later reference.
After registering with my address on the challenge page, I received the following instructions by email:
Your Kubernetes Challenge instance is now available at the following IP address: xxx.xxx.xxx.xxx. Point your /etc/hosts for hello-world.tld to xxx.xxx.xxx.xxx. After you've done this "https://hello-world.tld/" will be your starting point. Try to get full access to the master node and if you've found the flag at the end of the challenge (look for /root/flag.txt), please submit it at https://k8s-challenge.redguard.ch/flag?email=cookie@monster.com Best of luck! The Redguard Team
Reconnaissance
I first performed a port scan using nmap to
identify any exposed services on the target system. Several ports exposed a TLS connection. Their X.509 certificate attributes
contained interesting information about the internal network setup. It's
obviously a minikube setup with two nodes: 192.168.49.2 and 192.168.49.3, which I assumed to be the master node (the final target) and a worker node respectively.
The Kubernetes API seems to be exposed on port 32769, but access is protected:
Exploitation
After setting up Burp Suite with a hostname resolution override for hello-world.tld pointing to the specified IP address, I visited the target on port 443, which already provided the first hint:
I guessed that the author published a Docker image on dockerhub, by the name of disenchant/vulnerable-app-demo.