We invite you to demonstrate an exploit against our kCTF demo cluster based on the challenges presented on this page. Successful demonstrations which don’t use Linux kernel vulnerabilities are eligible for rewards as described in our kCTF VRP announcement blog post.
Important note: If you’d like to demonstrate an exploit against a Linux kernel vulnerability, please submit it to our kernelCTF program. kCTF VRP does not accept Linux kernel vulnerabilities anymore since 2023-06-14. For more information read our blog post “Learnings from kCTF VRP’s 42 Linux kernel exploits submissions”.
kCTF is an open source infrastructure for CTF competitions. You can find details on how it works in the kCTF documentation, but in short, it’s running on a hardened Kubernetes cluster with the following security features:
At present, we’re interested in two attack scenarios against this infrastructure:
For this purpose, we set up two kCTF challenges with secret flags: “kctf” and “full-chain”. You can demonstrate a working exploit by leaking the flags of either of these. You can find the code for the challenges here.
The “kctf” challenge is the only entry point to the cluster. You can connect to it via:
Older cluster (GKE Regular release channel):
socat FILE:`tty`,raw,echo=0 TCP:kctf.vrp.ctfcompetition.com:1337
Newer cluster (GKE Rapid release channel):
socat FILE:`tty`,raw,echo=0 TCP:kctf.vrp2.ctfcompetition.com:1337
It will ask you to solve a proof-of-work and then gives you access to a bash running in a setup similar to the kCTF pwn template challenge. The only difference is that the flag is not accessible inside of the nsjail sandbox and you will need to break out of the chroot in order to read it. You can observe the full source code here.
The details of the environment of the VM can be read from
/etc/node-os-release, and you can get the image of the VM following this script based on the output of
The “full-chain” challenge is a challenge that runs a
while sleep loop and doesn’t have any exposed ports. In order to get access to the flag, you will need to break out of the “kctf” challenge and break the pod isolation of the cluster.
The flags are stored in Kubernetes secrets and mounted to the filesystem of the two challenges at “/flag/flag”. They are of the format:
As you can see, the flags include a timestamp and are rotated frequently.
We want to avoid learning about unfixed vulnerabilities, so the process to submit reports is:
We want to encourage the community to help research vulnerabilities, but which are still unfixed since they have not been shown to be exploitable. As such:
When we receive an exploit for a fixed vulnerability we’ll add details here.
In case of questions or suggestions, you can reach us in #kctf.