The UCSB Capture The Flag is a distributed, wide-area security exercise, whose goal is to test the security skills of students from both the attack and defense viewpoints.

The CTF evolved from four previous security "live exercises" that were carried out locally at UCSB. The first edition of the UCSB CTF was carried out in December 2003. In that CTF, fourteen teams from around the United States competed in a contest to compromise other teams' network services while trying to protect their own services from attacks. The contest included teams from UCSB, North Carolina State University, the Naval Postgraduate School in Monterey, the West Point Academy, Georgia Tech, University of Texas at Austin, and University of Illinois, Urbana-Champaign.

This year we will perform an international CTF exercise, which includes teams from the United States and Europe. This has never be attempted before, and there are substantial technical issues that have to be addressed. We hope in the collaboration (and in the understanding) of everyone involved.

The exercise is loosely based on the DEFCON Capture the Flag contest. Acknowledgments go to the Ghetto Hackers that did such a wonderful (and inspiring) job in organizing the CTF contest at DEFCON. Many of the ideas of our CTF are derived from the DEFCON CTF and the lessons learned by participating to the DEFCON contest this August.

This exercise is different from the DEFCON contest because it involves several educational institutions spread across the nation. The DEFCON contest includes locally connected teams only.

In addition, the DEFCON contest has always involved a limited number of teams. We tried to develop a new network solution that allows a large number of teams to participate.

1. Description

The Capture The Flag contest is a multi-site, multi-team hacking contest in which a number of teams compete independently against each other.

Each team is given a VMware image containing a Linux server installation. The server provides a number of services. The services have a number of undisclosed vulnerabilities, which have been included by the contest organizers.

The goal of each team is to maintain the set of services available and uncompromised throughout the contest phase. Each team can (and should) attempt to compromise other teams' services.

During the contest a scoring system keeps track, for each team, of what services are available, and which services have been compromised.

2. Schedule

The CTF will be held on December 3, 2004. The contest will start at 10am, PST, by distributing a VMware image of a Linux system that provides a number of services. The participating teams have one hour to set up their systems and their connections. During this phase no traffic between teams will be allowed.

At 11am, PST the teams will start to compete and they will be able to attack each other. During this time the scoring system will provide real-time information about the performance of the participants.

At 4pm, PST the competition will end and the winner will be declared.

3. Network setup

3.1 Topology and IP addresses

The Capture The Flag (CTF) exercise involves a number of sites (e.g., UCSB, UC Davis, Georgia Tech). Each site can have one ore more independent teams.

Each site has a dedicated non-routeable set of addresses. Each team at each site has a dedicated class C subnetwork allocated within the address space of the site. For example, UCSB has the 10.10.x.x address space, and two UCSB teams have address spaces 10.10.10.x, 10.10.20.x, respectively.

Each site has a dedicated host, called the site box. The site box is connected to each of the site team subnetworks by means of a dedicated interface whose address is the "1" address of the corresponding subnetwork. For example, UCSB's site box is connected to the subnetworks through two interfaces with addresses 10.10.10.1, 10.10.20.1, respectively.

Each site box is connected to a central host called the main box. The connection between site boxes and the main box is implemented through a VPN tunnel. The figure below shows an example of the topology for four sites (UCSB, A, B, and C), with four, three, two, and one team, respectively.

ctf topology

The list of IP addresses assigned to each site and team is available on the participants page. To receive help in setting up your network, please send email to William Robertson at wkr@cs.ucsb.edu.

3.2 Routing configuration

The site boxes are configured so that all the traffic out of each team subnetwork is sent to the main box. This is an important difference with respect to a standard configuration. In a "normal" set up, traffic exchanged between two subnetworks connected to the same site box would not be sent to the main box. In this setup, instead, the traffic must always be forwarded to the main box because the box is configured to anonymize the traffic and collect statistics. For example, imagine the two hosts 10.10.20.2 and 10.10.40.2 in the figure above want to communicate. In a usual setup the traffic would have been routed through the site box only. In the CTF setup the traffic is routed through the following path: 10.10.20.2 -> site box -> main box -> site box -> 10.10.40.2.

To achieve this, it is necessary to configure a site box properly. Note that if you only have one team at your site, you do not have to perform this step. If you have more than one team at your site, contact us with details about how to set up this routing. You basically have two options. Either run two site boxes with two completely separate VPN connection to us (this is what we recommend), alternatively you can perform routing-voodoo on your site box. The UCSB site box is utilizing the voodoo solution. If you choose to walk down that path you probably have to run OpenBSD on your site box.

3.3 VPN Setup

The VPN setup is a critical step and has to be completed as soon as possible. The detail on the setup are provided here.

3.4 Team Hosts

Each team can have any number of hosts in their subnetwork. The only requirement is that a PC, called, the team box is part of the subnetwork. The team box should have Fedora Core 2 (FC2) and VMware Workstation 4.5.2 installed. Fedora Core 2 is freely available. A copy of the ISO images for the installation disks is available on the UCSB FTP site and in other locations. A copy of the RPM for VMware Workstation 4.5.2 is available here. A 30-day evaluation key for VMware is available at the VMware web site.

To configure a team host, first install Linux FC2. Then install VMware and configure it. The VMware host MUST be assigned a the "2" address within the subnetwork address space. The team host MUST be assigned the "3" address (this is mainly to simplify debugging). For example, if the team's subnetwork is 10.10.30.x, then the team box must have address 10.10.30.3 and the VMware host running on it may be assigned the 10.10.30.2 address.

You can test your VMware installation by loading a test image that is available here.

Note that the VMware host is the only host in a team's network that has to be reachable from the outside. All the other hosts can be configured to block traffic coming from the outside. During setup, leaving the team host open to ping would help.

3.5 Connection Testing

If all goes well, you should be able to ping the UCSB CTF VPN. Pinging ONLY works from your team box, NOT your site box. You can ping the IP 10.0.0.1. This is the IP of the scoring system, so you want to have connectivity to this IP. 10.0.0.1 is running a web server. You can also check that you are able connect to that. Sniffing the packets between your VPN host and the UCSB VPN host should reveal traffic somewhat like this example:

17:51:41.981677 IP w.x.y.z > a.b.c.d: ESP(spi=0x08029b41,seq=0x2a)
17:51:41.981891 IP a.b.c.d > w.x.y.z: ESP(spi=0x0077f7cf,seq=0x26)
17:51:42.982533 IP w.x.y.z > a.b.c.d: ESP(spi=0x08029b41,seq=0x2b)

In the very likely case that problems arise, do not hesitate to contact the UCSB CTF VPN admin with details of the issue. Useful details include error messages from racoon found in your syslog, the output of ifconfig, netstat -rn, and iptables -v -L, and your kernel .config.

4. Participation

To participate to the CTF you have to be an educational institution (e.g., a University or a school). The teams must to be composed of graduate and/or undergraduate students only.

Each site has to provide the name of a faculty point-of-contact (POC), who is responsible for the ethical behavior of the teams. In addition, each site has to provide the name of a deployment POC, who is responsible for the setup of the necessary infrastructure.

Please send a message to the CTF organizer (Giovanni Vigna) with your affiliation, faculty POC, deployment POC, and number of teams. After that, you will be assigned an IP range and you will provided with additional instructions.

Participant slots are limited and are filling up fast, so it may be possible that soon no more participants will be included.

If you are already listed, please take the time to check that the names, affiliation, and email addresses associated with your site are correctly presented.

All the communication regarding the CTF will use the mailing list ctf-participants, accessible at http://lists.cs.ucsb.edu/mailman/listinfo/ctf-participants. If you are part of the competition and you are not listed as a member of the ctf-participants mailing list, please subscribe to the list. Mail messages to the organizers of the CTF should be sent to ctf-admin@lists.cs.ucsb.edu.

The list of current teams is available on the participants page.

5. Preparation

To prepare for the CTF we provide a test image and a VPN server before the competition. Therefore, the deployment POCs will be able to solve their connection/configuration problems early.

A test image (with no vulnerable services) is available here (~280MB). Note that you must request a VMware Workstation 4.5.2 30-day license from the VMware web site. From the same site you can also download the VMware RPM. A copy of the VMware RPM is available here.

The test image and the VPN setup will allow you to test your setup well in advance. We are also making available the VMware image from last year's CTF.

The VPN instruction are listed above. An actual VPN server will be available soon.

During the preparation phase a Frequently Asked Questions page will be updated with answers to the most common questions.

6. Rules

It is not possible/feasible to list all the rules and the exceptions to rules that apply to the CTF competition. When deciding if an attack/protection technique is fair or not, try to think about the fact that the goal of this exercise in not to determine who is 1337 and who is l4m3r, but, instead, to learn about protecting/attacking a system in a live situation. Try not to focus on "breaking" the scoring system and instead concentrate on developing/deploying effective (and realistic) defense and attack techniques.

Below, you'll find the current list of rules. These may change as more issues are raised by the participants.

7. Scoring

Each team must maintain a number of services active and uncompromised.

At the beginning of a scoring period (say time t0), the scoring system connects to a service using a username and password (possibly creating an account on-the-fly) and stores a flag that is unique with respect to the team, the service, and this particular iteration of the scoring process. The flag is stored in a location that, in theory, is accessible only by using the username and password used by the scoring system.

After a certain period of time (say at time t1 = t0 + q) the scoring systems tries to log in again with the same username and password. At this point, if the login is not successful, the service is considered as malfunctioning and no defense point are assigned to the team that is running the service. If the scoring system can successfully log in and nobody proved that at time t, with t0 < t < t1, the flag has been stolen, then the team hosting the service gets a number of defense points.

A team (say A) might compromise the service of another team (say B). In practice this means that team A is able to read the flags stored by the scoring system on team B's server for a specific service (without having to know the username/password combination used by the scoring system). Team A can then submit the flag to a central flag certification system to prove that it was able to compromise B's server security.

If the flag is correct and "fresh" then, at the end of the scoring period, team A gets a number of attack points. More precisely, the team gets a percentage of the attack points that is proportional to the number of services that the attack team has currently up and running. This is done to penalize "selfish" behavior, where a team keeps its services down and concentrate on attacking only.

Note that if another team (say C) steals the same flag, then the points are divided between the teams. This means that services that are easy to compromise may give less points, while services that are more difficult to hack may guarantee higher returns.

The attack points for compromising a specific service will max out after a certain amount. This means that, after a while, submitting flags for a specific service is not going to give any points to the team. The flag submission page will return an appropriate message when this happens. This measure is to guarantee that the teams work on compromising multiple services.

Note that the scoring period q is different for each service. Services that are more difficult to compromise may be scored more often, which means that if a team compromises that service it may get points at a higher rate.

Now a little example to clarify. Suppose that the server implements a web-based discussion service where authenticated users can post messages. Users can post messages publicly or to a private discussion forum that requires a username and a password to access the forum contents.

The scorebot connects to the service of team B and creates a new forum, called "recipes" protected by a password, say "spaghetti". Then it generates the flag and creates a message in the forum that contains the flag (e.g., in the body of a posting to that forum). The flag looks like this: MTNzEwECA+hWjCb8t8/FgbEg/mSm1hbU231kjg==

After some time, the scoring system attempts to log into the forum (using forum name "recipes" and password "spaghetti") and checks if the flag is still there. If it is, then a new flag is created as the body of another posting. (note that the scoring system might also decide to create a complete different forum to store the new flag.)

In order to steal the flag team A has to connect to team B's server and in some way access the contents of the "recipes" forum. Of course team A does not know the password used to create the forum and therefore it has to find some way to bypass security. If successful team A will be able to read the flag. Then, team A will immediately submit the flag using a form on the scoring web site. The fact that team A stole the flag will be recorded and, at the end of the scoring period, some points will be granted to team A.

8. Point of contact

The Capture The Flag (CTF) is organized by Giovanni Vigna, at UCSB.

This is the contact information:

Additional Contact Info

A number of students at UCSB are involved in helping setting up this exercise. You may want to contact them on particular issues or in case the main point of contact is not available.