The CTFZone qualifying stage took place from November 30th to December 1st with 1043 teams from around the world registering for the event. Judging from our data, the competition reached even as far as Zimbabwe (26 unique IPs). Digging a little deeper, we would find out it was a team of college students from Bulawayo.
This year CTFZone became the qualifying event for DEF CON CTF, and the winners of the final stage, which will take place at OFFZONE on April 16–17, 2020, are going to the tournament in Las Vegas. DEF CON CTF is the world’s oldest and most prestigious competition for security specialists. At the moment, there are only 6 tournaments that can qualify a team for it, and CTFZone is among them. OFFZONE has even been moved to an earlier date to give the lucky winners the time to get their visas and flights sorted.
About the concept
Right now teams from different regions in the CTF community specialise in certain areas. For example, historically, Russians are better at solving web tasks, while Asian and American teams are stronger at PWN. Perhaps one of the reasons they have also performed better at DEF CON recently is precisely because almost all tasks there are binaries. We at CTFZone are trying to show that CTF is not only about PWN, but also about many other interesting categories: web, cryptography, reverse engineering, OSINT, forensics, PPC.
Web
While creating web tasks, their authors — penetration testing experts by day — tried to apply vulnerabilities from real projects. For example, in the Web-Shop task we used the popular python-markdown2 library, where our expert, just a few weeks before the competition, found a zero-day vulnerability that allowed to bypass the XSS filter. During the CTF, however, each of the four teams that solved the task found its own version of this vulnerability, which calls into question the quality of filtering in the library.
For the Web-Card, we used the zero-day vulnerability in the standard Java XML validation class. It was discovered when testing a real Web Application Firewall, so we invited participants to bypass the WAF we had developed specifically for this task. A detailed version of the write-up will be published later in the future.
And the EmeraldRush task highlighted the aspects in which GitLab and Github became similar over the last year — that being the vulnerabilities related to Ruby, in which both are written. One of them is based on CVE-2018–18649 (there is, however, no open access exploit for it), the second was recently discovered and published on the HackerOne platform (the description can be found in this article. Of course, the developers were notified of these and all other web vulnerabilities before the competition, in accordance with the principles of Responsible Disclosure
Cryptography
Here our development team spiced things up by basing crypto tasks not only on the bugs related to RSA implementation which constantly pop up in CTF, but also on some of the most notorious attacks of recent years. For example, the OCB2 task dealt with the attack on the symmetric encryption system with the same name, the discovery of which was awarded with the “Best Paper Award” at the Crypto 2019 conference.
And to solve the NTRU task, the teams needed to research the attack on an asymmetric cryptosystem based on lattices that was published back in September. Just finding and reading the corresponding article was not enough though. In fact, the author of the task himself encountered problems when it turned out that the source relied on the simplest case for description, which did not work with the parameters selected for the final task, so the algorithm had to be redone. Interestingly enough, one of the participants (Alexei Udovenko from the LC/BC team) solved the problem without referencing the article, and instead came up with a slightly different solution, built on the same principle.
Forensics
The trickiest category at our CTF was forensics. Everyone is used to thinking that forensic tasks are solved using three tools: foremost, volatility and strings. We, however, had something different in store — for example, an unusual In-The-Shadows task, which involved the technique described here. Details will also be released in the write-up later.
About the preparation stage
Three months before the start, a general meeting was held where the dates were selected — December 7 and 8. The team had to come to terms with the fact that there wasn’t nearly enough time, but still got down to business. And just as if those deadlines were not unrealistic enough, a week into preparation, they had to be moved 7 days earlier, as the selected dates and all the following ones have already had other CTFs scheduled for them. All we could do was grin and bear it, tripling down on our efforts. There was no turning back; the development was on track full steam ahead.
The tasks turnout was more than usual in the end — a full 30. As unique as each task is, its life span is brief: 3 months of preparation and only 36 hours in flight. But what a flight it is! The overwhelming excitement that hits you when you realise that world’s leading CTFers will click the buttons that you have spent nights carefully sketching; how they will immerse themselves in the idea that you yourself have created. The excitement and glee that rushes through your chest when you are awarded the opportunity to talk with a large community about your work and receive feedback on it. After all, the vulnerabilities that are seeded in the tasks oftentimes have some interesting stories behind them. Some tasks were so tough, though, that no one could figure them out. By the end of the qualifying round, two remained unsolved: Popular Forensic and Web-Card.
About the infrastructure
The setup of the tournament infrastructure could be approached in a myriad of ways. For example, the old-fashioned way — just divide up the virtual machines between task developers and give them access. In this situation, each developer is happy as a clam — a sole administrator of the localhost, everything works the way he wants it to. All that remains is to provide network connectivity. It is clear, however, that, in this case, there is no thought spared for replication and fault tolerance. This is exactly how a person tasked with creating our infrastructure failed the CTF at ZeroNights in 2016, and this time around, feeling the sting of that bitter experience, we decided to do things differently.
It took us a while to decide where to set up camp, and we eventually decided to deploy in the cloud. The reasons were obvious: since it was going to be a hacking competition, why not just let them hack Google, what with some ready-made developments up our sleeve already. The main tool for creating the platform was Terraform, which allows you to describe the infrastructure in the form of code in a declarative format and then takes care of all other steps. For instance, you need not worry about going to the Google API and telling it which virtual machines you want to deploy and how many.
It was also necessary to decide how to launch tasks. We were very lucky that all the developers were already able to write tasks in Docker. This is essentially a hyped up containerizer that allows you to pack a service with all the dependencies in an isolated environment that does not change between restarts. There aren’t that many ways to work with Docker: these are mainly orchestrators like Compose and k8s. To do everything tip-top, that is, to implement our whole wishlist including balancing, replication, fault tolerance and other goodies, the choice of the orchestration tool was, indeed, obvious — Kubernetes.
This is the part where we encountered some misunderstandings between the creator of the infrastructure and the developers. Pentesters are a special caste in the IT world: being the Jacks of all trades, they know their way around network administrating, working with databases, programming, and a lot of other things. Simply put, they are like Swiss knives. They are also rather extraordinary and ambitious, but, unfortunately, when it was decided to write a Helm chart for each task, it somehow slipped our mind that pentesters are still not professional admins. This led to a small tug of war, during which it became necessary to explain to developers why many decisions and restrictions were mandated.
The guys had no experience writing Helm, but they all knew how to write Compose. And the gap between a local Compose and a Helm chart translates into weeks or even months of studying the material. This was the first hint at some looming problems (but what is a CTF without them, especially when the teams and admins are new almost every time).
Due to a lack of time, it was not possible to automate everything — some things had to be picked up by the developers themselves. Pentesters had to attend meetings, where they were taught the joys of Helm writing, while probably cursing it from the bottom of their hearts. Yet, in spite of all the conflicts and challenges, we emerged successful — all the tasks were scripted and packaged in Helm charts, and the monitoring was configured in the form of Grafana and Prometheus. Then came the moment of truth.
To everyone’s relief, it turned out that the resulting infrastructure was, in fact, very easy to manage. When everything was described and deployed in Google, we conducted a briefing for the ten guys on duty. They all did a great job: if something crashed, they were there to swiftly pick up the pieces, reassemble everything and roll the patched-up version back out.
About the finalists
In the end, 10 awesome teams made it into the finals. And we don’t use the term “awesome” lightly! 6 out of 10 of these teams are in the CTFtime top ten, and the other four are just a little behind, but also ranking high.
Opposite to what some may have expected, the fiercest fight was not for a place in the top three, but rather for the tenth position. After all, the most important thing for the participants was to make it into the finals. Once they qualified, the scores would be reset, meaning that the final battle could go any which way.
What’s next?
Next we’ll take a breather, gather our strength and kick off with the preparations for the finals. The event will take on the Attack / Defense format, which is a completely different story. Some of you may be asking: what is this all for? And we grant you that this is indeed a worthwhile question, but there is probably no logical answer to it. But maybe, just maybe, if we succeed in stoking up that primal rush of competition, that exhilarating high from being part of a team, that brief moment which makes us feel alive, then all this will not have been in vain!
