THE GAME
——————

Your goal is to be the best country in the world, building up and unleashing a nuclear arsenal!

WOULD YOU LIKE TO PLAY A GAME?
./yes_but_how_does_it_work


Your Machine
——————

You will be given non-root access to a virtualized server. On this server, there will be a number of services running.

Your job is to keep the services up, detect attacks against the services, patch your services, and develop exploits to be used against other teams’ services.

When patching your service, you must keep the original functionality. If any of the scripts that simulate a user using the service is unable to fully exercise your service, then the service is considered non-functional.

You will gain Resources (to progress in the game) by keeping your services up and detecting attacks. You will gain Credits to spend on bonuses by developing exploits.

To detect attacks, you will be able to use tcpdump on your machine’s interface. There will be a publicly-accessible web interface where you can specify if a netflow in the last round was an attack and you will instantly see the results of your detection (i.e., if the attack was correctly detected or if the detection represents a false positive).

A netflow is identified by (source_ip, source_port, dest_ip, dest_port, timestamp). The timestamp that you see in the web interface will be when our side created the TCP connection. The timestamp you see from your vulnerable machine may differ slightly.


The Levels
—————

There are four levels in the game. Everyone starts out on the first level, with zero Resources.  At each level you generate a specific Resource, and once you generate enough Resources you will be promoted to the next level.

You will only attack and be attacked by teams at your level.

Your team’s ranking will be based on what level your team is in and how many Resources you’ve collected in your current level (that is, Resources collected in previous levels don't matter).
Teams in level 4 will be ranked above teams in level 3, and so on.



Collecting Resources
—————————

Here’s what a sample level looks like (specifics like color and so on could change):
http://i.imgur.com/82Cubvx.png

Red states are active, Blue states are inactive, and the smaller light blue nodes are services that are associated with each state.

In the example, “Mine Uranium” is the active state. Service dexware is active, because it is associated with “Mine Uranium.”

We will only generate traffic against active services. This traffic will consist of “benign” traffic and “attack” traffic. Part of your job is to decide which is which.

Each change of the level is called a “tick.” The tick will change (almost) every 3 minutes.

So, how do you create Resources?

Resources are allocated every “round.” A round is a complete traversal of the level, with the XMAS state being the last state.

The XMAS state is special, it will last for 1 minute, and there will be no traffic. This will give you time to identify attack traffic in the previous states.

So, there will be a round every 10 minutes, as every level has 3 states and 1 XMAS state. After the XMAS state, a round is complete and Resources are awarded to each team.


Calculating Resources
——————————

Every round you will be awarded Resources for how well you performed in that round.

The maximum Resources you can receive in a round is 500. The lowest is 0 (but you’re not going to be that team).

300 of the 500 Resources are rewarded for having the active services up.

So for N active services on the round, if you had Nup of those services up and functional, you will receive 300 * (Nup / N) Resources.

The remaining 200 of 500 resources are awarded based on how many attacks you detected. A successful undetected attack is an attack that:
1) correctly captures your flag
2) has not been marked as an attack (more precisely, NONE of the associated netflows have been marked).

You will also lose Resources for each incorrectly marked benign netflow.

So for Na number of successful attacks, Nd number of attacks you detected, and Nw number of incorrectly marked netflows, you will receive 200 * ((Nd - Nw) / Na) resources. Of course, if there are no attacks, you will receive 200 Resources.

So, for the math types, here’s the whole formula:
Total_Score_Of_The_Round = max(0, 300 * (Nup / N) + 200 * ((Nd - Nw) / Na))

Let’s look at an example.

For one round of the example level above there are two services involved (dexware and mathconsole),
which are active each in two states. In total, there are 4 instances of a service being up and "attackable" in a round.

Let’s say that, out of the 4 service instances, you had 2 services up. And, during the round there were 2 successful attacks, and you correctly marked one netflow as an attack, but you also incorrectly marked two benign netflows as an attack.

How many Resources would you receive in this round? Go ahead, I’ll wait.

50

N = 4, Nup = 2, Na = 2, Nd = 1, Nw = 2

(300 * (2 / 4)) + (200 * ((1 - 2) / 2) = 150 + -100 = 50

Now let’s say that you do better. Out of the 4 active services, you had 4 services up. And, during the round there were 4 successful attacks, and you correctly marked four netflows as an attack, but you also incorrectly marked one benign netflow as an attack.

N = 4, Nup = 4, Na = 4, Nd = 4, Nw = 1

(300 * (4 / 4)) + (200 * ((4 - 1) / 4) = 300 + 150 = 450


Promotion
—————

To be promoted to the next level, you must generate enough Resources at the current level.

Here is our current idea of the limits for each level (subject to change before and possibly during the competition):

L1: 6,000 resources
L2: 4,500 resources
L3: 3,000 resources

Therefore, you must generate 6,000 resources to be promoted from level 1 to level 2, and once there you must generate 4,500 of level 2’s resources to be promoted to level 3. And so on.

If you are the first team to be promoted to a level, you will not start generating Resources, which means that there will be no traffic to any of your services. Use this time to develop elite exploits. Once another team is promoted, you will both start generating Resources.


Services, Exploits, and flag_id. Oh My.
——————————————————

In the CTFs of old, each service had a single flag.

Our services have multiple flags, and these flags are part of the service. A flag could be user passwords, the status of the user, or nuclear launch codes, depending on the service.

Don’t steal all the flags; you’re supposed to be stealthy.

Your exploit should only steal a specific flag. But how will your exploit know which flag to capture?

In comes the concept of a flag_id. A flag_id identifies the specific flag to capture and is service dependent. For instance, if the flag are user passwords, the flag_id could be the specific username. If the flag is the status of the user, the flag_id could be the specific user_id. If the flag is the nuclear launch codes, the flag_id could be the specific nuclear site.

Imagine the following database table for a fake service:

| user_name | user_password | status |
| adam | 9cb4afde731e9eadcda4506ef7c65fa2 | ICTFFTW |
| test | 098f6bcd4621d373cade4e832627b4f6 | FLG47M9glVIWW3AG |
| l33t | 11119102f1634c7967cc1b58947295d8 | FLGmBSlIkZoWSy2p |
| vigna | 9cb4afde731e9eadcda4506ef7c65fa2 | FLG4V2tHkaodSy2p |

The flag_id for this service is the user_name. The flags are clearly the status.

If your exploit is given “l33t” it will be expected to return “FLGmBSlIkZoWSy2p” (of course by exploiting the service).
If your exploit is given “vigna” it will be expected to return “FLG4V2tHkaodSy2p”

Unlike those poor souls who competed in the 2012 iCTF, you will not have to guess what the flag_id is for a service. The web interface will clearly state, for each service, a description of the flag_id.

So, your exploit will accept, as a parameter, the ip and port to exploit, and the flag_id to capture the specific flag. Your exploit will return only that flag.

Your exploit will either be a single Python script or a .tgz bundle.

So that you can test your exploits, your vulnerable machine will have a script that will run exploits exactly as we will run them. You’ll only be able to run the exploits against yourself.

Specific exploit interface details and examples will be released Thursday.


Submitting Exploits
—————————

You will submit your exploit for a specific service through the web interface. Only your latest exploit for each service will be run. This information will also be shown on the web interface.

We will test your exploit to make sure that it can successfully capture the flag from an unpatched service. You will get automatic feedback from this process that will be shown in the web interface.

Any team caught messing with or trying to evade the testing service and automated feedback will be banned from the competition. Exploit each other, not us.

Your exploit should steal the flag. DOSing the teams’ service is also grounds for banning. Play fair, win fair, write dirty exploits.


Running Exploits
———————

Each tick ZDI (aka us) will run at most one exploit against each active service for each team. Eligible exploits are ones that have passed the exploit submission process (see previous section), and are from teams in your level.

The specific exploit to run against a particular team’s service will be randomly chosen between all eligible exploits from teams in that level.

Every time one of your team’s exploit script successfully captures the correct flag for the service, AND DOES SO UNDETECTED by that team, you receive one Credit.

For example, if you are the first team to submit an exploit for service mathconsole, when mathconsole is active, your exploit will be run against all the teams in your level (except for you). This means that if none of the teams detect your exploit and everyone has their service up, you will get at most N Credits, where N is the number of teams.

However, once another team submits an exploit for the service, the most credits you can get is N/2, and so on.

You will know from the scoreboard who has submitted an exploit for what service.


Spending Credits
———————

You worked hard to write those stealthy exploits, and we want to reward you for it.

Welcome to the auction house.

Here, you can spend your hard earned Credits on bonuses to help your team. Or hurt your competitors.

Each auction starts at the beginning of a tick, and ends 30 seconds before the end of the tick.

During the action, you can place a bid on one of the bonuses. Each bonus will have a different minimum bid. You cannot revoke a bid, and you cannot place more bids than you have credits.

Each bonus item can only be won by a limited number of teams, specifically the teams that bid the most.

You will not know what the bids are for the current auction, but you will know the winning bids for the previous auctions.

If you successfully win the bid, you will receive the bonus and your credits are deducted. If you loose a bid, you get back your credits.

What are these bonuses, you ask?

1. Protection for the next tick. If you win this bonus, you will not be attacked during the next tick.

2. Mute a team’s exploits. If you win this bonus, we will NOT run exploits from a given team for the next tick. You tell us which team when you make the bid.

3. Show attack netflow. If you win this bonus, we will tell you one netflow id of an attack in the current tick (the current tick that you’re placing a bidding). It’s your job to identify this netflow as an attack.

4. Purchase our exploits. If you win this bonus, we will give you a ZDI verified exploit for a service of your choice. It’s your job to submit it as your own, make tweaks as necessary, and so on. You will only be able to buy this bonus once.

Oh yeah, one more thing: you’ll be able to set a message that will be shown to everyone if you win a bonus. We’re a university, so keep it clean.


Important Note
—————————

We reserve the right to change the parameters of the game. But at least we’ll update you when we do.

Please ask if you have any questions, but understand that we are working on getting the game up and running and stable and scalable. If you think you can answer another team’s question, please do so.



_______________________________________________
ctf-participants mailing list
ctf-participants@lists.cs.ucsb.edu
https://lists.cs.ucsb.edu/mailman/listinfo/ctf-participants