Wall of Text in one sentence: I can't wait for the next edition :)
If you're a computer security enthousiast, have an interest in the latest iOS jailbreaks or just happen to have been in contact with ITQ the last few years, then chances are you already know what Hack in the Box is. If not, then here's a short introduction: Hack in the Box is a series of security conferences which has grown from a simple get-together of Malaysian security enthousiasts in 2002 to one of the must-attend global security events. In 2010, Hack in the Box partnered with ITQ to organize a European installment: Hack in the Box Amsterdam. This experiment turned into a great success and has since become an annual event, with its 3rd installment in May 2012.
The setup of Hack in the Box is somewhat different from / larger than B-Sides. Instead of a single-day conference, Hack in the Box is a near-week long event. The event is split in two sub-events: the Training Days and the Conference Days.
During the Training Days, security specialists from all over the world can touch up on their skills in their choice of subject. This year, there were three single-day trainings sessions and three two-day trainigs, culminating in a total of three training days.
After the Training Days, it's time for the Conference Days, which offer a more traditional conference experience, with several tracks of security-related presentations, several competitions and an exhibition area for seurity related organizations.
This year, it was my privilege to participate in the organization of two of the competitions that were held on the Conference Days: the Bank0verflow Capture The Flag competition and the HackWEEKDAY programming competition.
A CTF can be thought of as a sort of hacking competition and can come in one of two flavors: attack-only or attack & defense. In the former, participating teams are presented with a set of challenges which they have to complete in order to gain points. In the latter, participants are given control of identical (virtual) machines that host a set of (potentially) vulnerable services and are assigned to find and exploit those vulnerabilities in the machines of their competitors while preventing their own machine from being exploited in a similar fashion. After two years of attack-only games, this year it was time to create an attack & defense game.
From the start, it was clear that attack & defense was going to be more challenging than attack-only, both from a challenge-creation perspective as from an organizational / infrastructural perspective.
As a creator of challenges, you have to deal with the fact that you're going to be creating a service of some sort. This means that you're going to be dealing with networking, not buts about it. You had a nice idea for a reverse engineering / obfuscation challenge? If it's not network accessible and can't be used to abuse other competitors' machines, you're going to have a bad time.
Also, as the participants will (eventually) have full access to the machine running your service, every part of your service will be completely exposed. This means that competitors are, by definition, given white-box access to all your challenges. So, you have an idea for a challenge that relies on exposing hard-coded secrets (perhaps a web-challenge with LFI)? Better make sure it won't be reduced to `strings <chal> | grep -i 'passw'`.
And don't forget, your service has to be 'fixable' somehow within the rules of the CTF. That is, teams should be able to mitigate or remove the vulnerability in such a way that it doesn't affect the functionality and interoperability of the service. After all, it wouldn't be much of an attack & defense game if there was no way to defend (other than outright killing the challenge) ;)
From an organizational perspective, you've got a lot more to think about too. Where in an attack-only game you only have to deal with keeping the virtual machines that run your challenges and the scoreboard alive, you now also have to deploy, administer and monitor all of the competitor vm's. You're faced with questions about how you're going to distribute flags and challenges. If challenges rely on retrieving a hard-coded secret, how are you going to make sure that these secrets are unique to each competitor? Will you be deploying all challenges at once, or will you distribute them separately as the competition progresses? How will you deploy new challenges at run-time without disturbing the rest of the game? How do you respond when challenges break and need to be fixed? How do you determine whether teams are abiding by your rules? Not that easy, eh?
In the end, we decided to be pragmatic and create a sort of hybrid attack & defense game. All of the teams were given a vm which would be fully updated so that any and all succesful attacks would either have to be related to our challenges or 0-day (in which case you deserve the pwnage). Every vm would include the organization's ssh rsa pub key and teams were forbidden from removing it, so at any time we would be able to monitor activity, distribute new flags and add or fix challenges. Challenge creators were instructed to provide challenge-specific deployment scripts that would create a challenge-specific user and group (so challenges wouldn't interfere with one another) and customize the challenge for a specific machine based on ip (for instance to generate unique hard-coded secrets). We also set up a centralized challenge server which could host bonus challenges that were deemed inappropriate for a pure attack & defense game. The scoring system was a punishment / reward system, where points were awarded for keeping services alive and functioning (and of course for finding flags) and deducted for having them disabled or disrupted. Checks on service availability and functionality were inplemented as automated unit tests for core functionalities, that were run at semi-random intervals.
In the end, I ended up creating three challenges for the CTF, two of which were actually released. The first one that was released was a Digital Cash system called ByteNote, which contained several cryptography-related issues that allowed teams to create or falsify digital IOU's that could be turned into points at the central server.
The second challenge was a bonus steganography challenge called Invisible Ink, which consists of a disk image that contains two files that each encode half of a flag. The catch? Upon inspection of the files, you will notice both contain nothing but null bytes :)
My third challenge, which was planned to be released on the second day, sadly remained unreleased due to organizational preoccupation with other issues. The challenge was a centralized Security Scanner's host agent that contained a variety of issues that could be elevated to, among other things, Denial of Service and Remote Code Execution.
We are currently discussing how to publicly release the challenges we made for the CTF, so if you're interested in giving them a try, keep your eyes posted on this blog :)
HackWEEKDAY is a relative new comer to the Hack in the Box repetoire, with its first installment at Hack in the Box KL 2011. The idea of HackWEEKDAY is simple, but fun: it is a programming comptetition where, during the course of the Conference Days, teams of programmers design, implement and present a Proof of Concept solution to their choice of one of several coding challenges. These PoC's are then evaluated by a team of judges on aspects such as functionality, originality, applicability, etc. and the winner gets the Big Prize of $1337.
When I joined the organization of HackWEEKDAY, the theme had already been determined: Browsers and their Extensions, so all we had to do was translate this into a series of programming challenges; invite and select suitable participants; create a shared development environment so different team members could cooperate on their chosen assignment; and, last-but-not-least, provide a comfortable physical environment in which the participants could be stimulated and supported throughout their undertakings.
The first two aspects turned out to be the most challenging from an organizational point of view.
At the first edition of HackWEEKDAY, the competition ran non-stop for a full 24 hours. This time, due to practical limitations with the venue, we would not have the luxury of continuing throughout the night. This meant that the time available for the competition was reduced to a span of 12 hours. This is not a lot of time in the world of software development, so we would have to be careful with the scope of our challenges. Make the challenges to broad or too complex, and you risk ending up with non-functioning/non-presentable PoC's, which not only makes the results less interesting to present, but also harder to judge. Luckily for us, the theme of Broswer Extensions lends itself perfectly for relatively small projects, as a lot of basic functionality is provided through the browser's api.
Inviting and selecting the right candidates was challenging mostly due to the novelty of the HackWEEKDAY. With only one previous edition at the other side of the globe, it was difficult to gauge and predict the level of interest in the various potential target audiences and the best communication channels to reach them. Although we did manage to find a nice selection of participants, this is definitely an area in which we still have a lot to learn.
Once these things were deal with, the rest was a breeze. With a simple SVN setup to enable collaboration; a nice conference room at the Okura hotel with a good sound system for physical comfort; and the presence of a few representatives from Mozilla (who sponsored the event) that helped both in supporting / stimulating the participants and in judging the submissions, the competition ran perfectly smooth.
In the end, we had a total of 4 teams, that chose to work on 3 different challenges:
- Automatic hash verification of downloaded items (1 team)
- A password re-use detection / warning system (2 teams)
- A client-side encryption tool (to be used, for instance, with unencrypted webmail) (1 team)
Although not every team started at the same time (some taking longer to reach a decision on their choice of challenge than others) each of the teams managed to create and present a functioning PoC. To me, as part of the organization, that meant a job well done. As icing on the cake, some of the developers expressed their intention to continue working on their PoC's and turn them into full-fledged extensions. Among them was the winning team, whose github for the project can be found here: https://github.com/DevNerd/YAP
All in all, I had a blast during Hack in the Box, from the preparations to volunteering during training sessions, to the last minute CTF fixes, to the final presentations of the HackWEEKDAY. Although with one Conference Day fully dedicated to the CTF and one Conference Day fully dedicated to HackWEEKDAY I didn't get to attend any but the Keynote presentations and one of my challenges sadly got benched, I would do it again in a heart beat. I can't wait for the next edition :)