Looking back on the GitHub Security Lab Capture The Flag: CodeQL and chill
One year ago, the security research team at Semmle launched its first Capture the Flag (CTF), as part of the Hack In The Box (HITB) Amsterdam conference. We wanted to…
![](https://github.blog/wp-content/uploads/2020/06/85479513-2b448a00-b573-11ea-819e-acf60e9be938.png?resize=1200%2C630)
One year ago, the security research team at Semmle launched its first Capture the Flag (CTF), as part of the Hack In The Box (HITB) Amsterdam conference. We wanted to propose something different from the usual CTFs, while supporting our mission of securing open source at scale. Instead of just searching for a flag, participants would write a CodeQL query that exposed the vulnerable pattern related to the flag, allowing them to find other occurrences of the same bug class.
Since then, the Semmle team has found a new home within GitHub, and we’ve continued with our contests as part of the GitHub Security Lab. In our latest CTF, CodeQL and chill – The Java edition, we asked participants to find a remote code execution (RCE) vulnerability in a container management platform, allowing an attacker to pass arbitrary executable Java code into the application. Participants used the CodeQL taint tracking libraries to track data flowing from a Java bean controlled by the user to a place where it would be executed.
This edition was a useful opportunity to show that there is more to participating in CTFs than just the thrill of winning or the prizes. See for yourself! Let’s hear from our winners what they got from the GitHub CTF!
Our winner is Kanav Gupta. Kanav wrote accurate and organized code, and provided both interesting ideas and clear explanations when tackling the more challenging bonus questions.
“The Java CTF was an awesome way to learn about static analysis and CodeQL. I was using it for the first time and the intuitive structure of CodeQL made writing queries that find vulnerabilities a piece of cake! Such an awesome tool. The challenges in the CTF were very clear and explained the motives clearly. Though found hints are a bit more helpful than they should have been. It was an awesome new type of CTF.”
In second position, ex-aequo, are Nguyen Jang and Manas Chaudhary. Jang demonstrated a good understanding of the CodeQL libraries and how to remove false positives. Manas provided creative approaches to the more challenging questions and backed them up with thorough explanations.
“While this was not a CTF in the traditional jeopardy/attack-defense sense, it’s the first where I got to see how vulns in huuuge codebases are like and how the methodology to find them is totally different from sandboxed CTF challenges. Loved this change of pace!” – Manas
The level of the challenge was quite high, especially since it demanded some familiarity with CodeQL, and the submissions were amazing. Honourable mentions: Oleksandr Synetskyi and Tony Torralba, who respectively ranked 4th and 5th. Tony gave us a fun and exciting PoC, very detailed, and it was a pleasure to follow along with the steps and tribulations described in his writeup, with bonus explanations of why some injections were not working. Oleksandr proposed a nice solution to the bonus question, by using another taint tracking configuration. You can see a similar approach in the reference solution linked at the end of this post.
“My main area is Digital Forensics/Incident Response. With that, the most eye-opening experience was the general idea behind CodeQL: being able to reason about code as data and run queries against it to find not just unsafe methods like strcpy, but entire unsafe coding patterns? It looks amazing!
Interestingly, for me this idea resonated with the Incident Response approach of “making an adversary’s job hard”. In IR, it’s accomplished by identifying and disconnecting compromised hosts, deleting hacking tools, blocking C&C IPs etc. so that every step of the intrusion takes more time and resources. CodeQL enables you to do something similar but with vulnerability discovery – its queries can be run not just against codebases they were originally developed for but against others as well, allowing to detect and remediate a whole class of vulnerabilities. Therefore, to be successful the attacker will need not just to find the same flaw in a different section of a program, but discover a new vulnerability type (which can then be turned into a query as well), needing to put more and more effort each time.” –
Oleksandr
“The CTF was super fun! A great guided learning experience and a nice challenge at the same time. I think the specific discovery it was based on was amazing, and being able to replicate the steps to find and exploit the vulnerability while learning CodeQL was a privilege.” – Tony
You can have a look at the reference solutions on the Security Lab website.
Don’t miss our next Capture The Flag challenge! Visit https://securitylab.github.com/get-involved to keep in touch with us! Part of an organization? Check out more security resources and upcoming events for teams.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2024/01/Security-DarkMode-3-1.png?resize=400%2C212)
From object transition to RCE in the Chrome renderer
In this post, I’ll exploit CVE-2024-5830, a type confusion in Chrome that allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site.
![](https://github.blog/wp-content/uploads/2023/11/Security-LightMode-4.png?resize=400%2C212)
Configure GitHub Artifact Attestations for secure cloud-native delivery
Introducing the generally available capability of GitHub Artifact Attestations to secure your cloud-native supply chain packages and images.
![](https://github.blog/wp-content/uploads/2023/12/Security-DarkMode-1-2.png?resize=400%2C212)
3 ways to get Remote Code Execution in Kafka UI
In this blog post, we’ll explain how we discovered three critical vulnerabilities in Kafka UI and how they can be exploited.