Over the past 6 years, I've been collecting pieces of the DEFCON CTF's past and attempting to preserve them in a way that will allow future generations to enjoy the game. With the conclusion of DARPA's Cyber Grand Challenge and the start of DEFCON 24's CTF Finals, I'm releasing what I have. It's not 100% finished (I've been way too busy lately), but it is usable!
TL;DR: The most recent copy of the VM is v0.1.0 and can be downloaded here. The files are stored in a GitHub repository here. Credentials are below.
UPDATE 2016-08-08: Minor text fixes.
What is the DEFCON CTF?
The DEFCON CTF is the longest-running "capture the flag" hacking event of all-time. Finals are extremely difficult and have the reputation of being the "Hacker Olympics". Although the CTF has been around since DEFCON 4 (1996), its current format started in DEFCON 10 (2002) with the Ghetto Hackers. It was further refined in DEFCON 13 (2005) when Kenshoto re-focused the game and emphasized binary exploitation and patching.
The rules and details of the game have changed a lot over time, but can be generalized as:
- 8-20 teams each have a network drop to a computer, provided by the organizers, that they control some portion of.
- Custom services (like web or mail servers), created by the organizers, must be kept running on this computer.
- Each team must find flaws in these services and exploit them to steal "flags" from the other teams.
- Flags are little text-based tokens (like
0e63d4223b01d9aba596259dc155a174) that represent the idea of sensitive data (like proprietary information or customer details).
- Flags are little text-based tokens (like
- Each team must defend their computer by patching the flaws in these executables to prevent other teams from scoring.
- Because the services are usually compiled binaries, this typically means hex-editing the executable directly.
The score, at the end of the game, is generally of the form: uptime * value of flags. In some years, flags all had
the same value. In other years, flags for services that had not been as heavily exploited were worth more. Uptime is
always the percentage of time a given team's services were available (judged by having automated users, called
"pollers", try to connect and use each service at random intervals).
In CTF circles, we call this kind of CTF "full spectrum" or "attack-defend" because every team is responsible for both attacking and defending. This is unlike the far more popular "Jeopardy"-style CTFs (like the DEFCON CTF Qualifiers). As a result, the DEFCON CTF Finals are very unique and far more difficult than the average CTF event.
Where are the files?
Today, I am releasing a number of things:
- A FreeBSD 9 virtual machine with all of the challenges configured to run (user is "root" and password is "defcon" if you need it)
- A GitHub repository containing all the challenges, configuration files, and some documentation
These are not (yet) perfect. Some challenges don't run due to missing dependencies (packages I couldn't get installed, files I haven't been able to find, incorrect versions/configurations of things). Some things aren't documented as well as they should be (how to set up your own VM). But, they should be enough to get up and running.
I have focused entirely on the games run between 2005 (DEFCON 13) and 2012 (DEFCON 20). These were the games run by Kenshoto and DDTEK. The game's current organizers, Legitimate Business Syndicate, have an amazing habit of posting everything on GitHub some time after each year's game. As a result, I haven't felt a need to expend additional effort. Thanks, LegitBS!
Notably absent from the VM are all of the challenges from Kenshoto's 2006 (DEFCON 14) game. This is because they ran on Solaris, rather than FreeBSD like the other 7 years. I have provided all these binaries in the repository if some other intrepid hacker would like to put time into re-hosting them. If anyone does, please contact me and I'd be more than happy to provide a link on this page.
How do I use this stuff?
Booting the virtual machine should be all that's required to get services up and running. To interact with a service,
simply open a socket connection to the VM on that service's port. On a *nix system, this can be done in a terminal
with netcat: nc xxx.xxx.xxx.xxx yyyyy (X's represent the IP address, Y's
represent the port number). In python or ruby, this can be done with a script like these:
#!/usr/bin/env python3
import socket
# connection options
HOST = "defcon.local"
PORT = 9999
# connect to service
s = socket.socket.(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
# example of receiving a message
#message = s.recv(512)
# example of sending a message
#s.send(message)
# disconnect from service
s.close()
#!/usr/bin/env ruby
require socket
# connection options
HOST = "defcon.local"
PORT = 9999
# connect to service
s = TCPSocket.open(HOST, PORT)
# example of receiving a message
#message = s.read()
# example of sending a message
#s.print(message)
# disconnect from service
s.close()
Of course, this just gets you a connection. The game requires you to find and patch/exploit flaws in each service. To do this (for most services), you will need to disassemble and step through the compiled executable by hand.
The industry-standard tool for reverse engineering is IDA Pro. Alternatives include Hopper and the recently-released Binary Ninja. If you don't want to spring for a license (or use the free demo version), the Binary Ninja prototype is open-source. Radare is another open-source alternative. And, of course, no discussion of disassemblers would be complete without mentioning objdump, which should be readily available on *nix systems in your distribution's repositories.
To assist newcomers in understanding how to find, patch, and exploit vulnerable code in these services, I have also published a fully detailed walkthrough of one of the services from DEFCON as a tutorial:
- DEFCON 15's kimjong (2007)
Once you've gone through it (or decided it's beneath you), I recommend "antipasto" (from DEFCON 16), "deltad" (from DEFCON 17), and "sammichd" (from DEFCON 15) as other, easier services to start with.
How do I report bugs or request fixes?
Please report bugs for the VM by opening tickets against the GitHub repository. I can't promise I'll get to them in a timely fashion, but I can promise I'll give them my attention. If enough fixes are made, I'll cut another release of the virtual machine and update the links above and in the repository.
What has changed since you released the VM originally?
Currently? Nothing! I'll attempt to keep some sort of changelog below, though:
- Version 0.1.0: Original release.