Punk Security Birthday CTF 2024
As we celebrate another year of Punk Security, we went back to the drawing board to develop some awesome new DevSecOps-themed CTF challenges.
Last year we hosted the first ever Punk Security DevSecOps CTF event. We’re passionate about what we do, so the prospect of hosting a CTF with our own unique challenges was really exciting! Due to the overwhelmingly-positive feedback from last year’s event, hosting another was a no-brainer.
The Challenges
As with last year, we developed a collection of challenges ranging from easy to obscure. We try to design our challenges around realistic scenarios to highlight how seemingly small misconfigurations or oversights can have catastrophic consequences. Let’s break down a couple of them…
Peer Reviews to Fight Abuse
Many source control management frontends, such as Github, allow administrators to place restrictions on how code changes enter and move through their repositories. One way that these restrictions are used is in the form of pull requests, which gives colleagues the opportunity to peer-review new work. Combined with other controls, such as requiring a minimum number of reviews before merging, it can be a really effective tool. Until it all goes wrong…
The premise of the challenge is as follows:
- A Gitea source control server with a repository owned by another user
- The repository requires pull requests for the main branch, with at least 1 approval needed to merge
- A Jenkins build server with two jobs:
- A job that automatically discovers and builds pull requests. This has limited access to build secrets and uses a build script from the repository
- A privileged job that builds only the main branch. This has access to additional secrets (the flag), but the build script is fixed and cannot be changed by regular users.
- A Gitea account that’s used in the first job to automatically leave comments on pull requests
(Un)fortunately, the administrator made some key errors:
- They didn’t restrict who could approve pull requests, allowing anyone with write access to approve
- They used an account with write access to automatically leave comments on pull requests
- They didn’t protect the pipeline script in any way, giving attackers complete control of the build process
- They used some bad practises when creating the job for the main branch, opening up a command injection vulnerability
By modifying the pipeline script, players abused the auto-comment feature to approve their own malicious pull requests. After merging their pull request, the command execution vulnerability was triggered, causing the flag to be included in the build output!
Terraform - Hard
It’s widely known that terraform state files can contain sensitive values, but it’s not obvious that manipulating the state files can lead to side effects - in some cases code execution!
In this challenge, players found themselves logged into a Jenkins instance as a low privilege user. Players first needed to identify the location of the Terraform state file and gain access to it. The state file then needed to be modified to trick Terraform into believing that it was managing a cleanup script.
When the Jenkins pipeline was next triggered, Terraform would see that it knew about a file that was no longer in the configuration and would delete the file. This meant that the workspace wouldn’t be properly cleaned up, leaving the flag exposed in the build artifacts.
This was a really obscure challenge, and we’re really impressed that one team managed to solve it!
Wrapping up
We’d like to extend our thanks to all our CTF players! We’ve had a lot of amazing feedback and have thoroughly enjoyed hosting the event. Now I think it’s time for the team to take a rest before we start thinking about challenges for next year!
