b01lersCTF 2023
- 4 minsOverview
Being in charge of the infrastructure for b01lersCTF 2023 was an incredibly rewarding experience. While it was not without its challenges, it was a fantastic opportunity to learn, grow, and support this amazing organization. The CTF spanned 48 hours, from Friday, March 17th @ 5:00pm EST to Sunday, March 19th @ 5:00pm EST. The event ran quite smoothly, with only a slight error preventing users from being able to submit flags within the first 5 minutes. That one was on me… The infrastructure held study for the duration of the CTF which was amazing to see. No issues with website loading times, challenges going down, or DOS attacks from players.
We had 860 teams that signed up with 425 teams submitting a flag. The top three teams were Maple Bacon, Tower of Hanoi, and PFS so a huge congratulations to those folks! This was Maple Bacon’s second year maxing out our CTF, so some extra laurels to them! Our CTF featured 25 challenges in total, with 3 Crypto, 7 Misc, 1 OSINT, 5 Pwn, 4 Rev, and 3 Web with 11 authors contributing challenges.
How We Pulled it Off
In the past, CTF challenges for b01lersCTF have been deployed by simply exposing containerized versions of challenges to the public using a variety of different methods, from different servers, to different cloud providers. However this year, we decided to switch to the KCTF platform for challenge hosting. KCTF is a CTF platform developed by Google based on Kubernetes and integrated into Google Cloud. It’s actually quite a nice piece of kit, especially for this use case. For every challenge a Docker container is created. Within this container, nsjail is running so that for every TCP connection to the container, a new challenge instance is spawned. As you might imagine this is quite a handy feature as it allows players to have their own instance of a challenge when they connect to it. This prevents bad actors from trying things like deleting flag files, running fork bombs, or any other DOS attacks against the challenge instance. These containers with nsjail running inside are then ran inside their own Kubernetes pod. This allows for quick and easy deployment as well as load balancing. If a challenge is being overrun with requests, the Google GKE cluster will simply spin up another VM and deploy more pods. Another pro to using KCTF is how easily it integrates into Google Cloud. KCTF has its own interactive shell that allows you spin up GKE cluster and create a domain name for your challenges in one command. The domain name is automatically mapped to Google’s DNS services so that challenges can be accessed publicly. This interactive shell also features other commands that allow for easy creation and debugging of challenges. This security, peace of mind, and ease of use (most of the time) is why we decided to make the switch to KCTF this year.
Problems Faced
As amazing as the KCTF platform is, we faced a few issues with our challenge deployment. The first issue was that for some reason KCTF wouldn’t install properly on the Google Cloud account we originally designated, so another one had to be used. No biggie though, all it took was a simple account switch. We were however plagued with a few issues getting challenges to run in nsjail. Things like directories not having R/W privileges when needed, different Libcs being used, different files being read from outside the chroot directory, dependency issues, issues with Qemu, and web challenges not working were some of the problems we faced throughout our challenge testing. With help from our amazing challenge authors most of these issues were resolved. However, deployment was a bit rushed towards the end and we were not able to get web challenges working with KCTF. This is a primary goal for next year as web challenges greatly benefit from the KCTF platform.
Too Many People to Thank
The first person I’d like to thank is our Vice President r3x. He assisted with troubleshooting deployment issues and was always one DM away to help with any issues.I’d also like to extend a HUGE thank you to all of our challenge devs. Not only did they crank out some amazing challenges, they were incredibly helpful troubleshooting deployment issues with challenges. They were also always on call to help with deploying new challenges, answering help tickets in the Discord, and general CTF administration tasks. It was also quite helpful seeing other CTF teams’ CTF deployments that have been pushed to Github. Shoutout specifically to the team over at UIUC, Sigpwny, as their KCTF deployments were integral in helping us understand our own deployments.
Final Words
This CTF never would have been successful if not for club members contributions. Working with this group was an incredibly rewarding experience and I’m thankful that this opportunity was presented to me. If anyone stumbles accross this and could use a hand, reach out via Discord: CaptainNapkins#1325.
Gabriel Samide
Sophomore, Webmaster