Rules

FAUST CTF is an IT security competition for teams of one or more members ("the teams", "the participants" or "you"). It is organized by FAU Security Team ("the organizing team" or "we") on behalf of Fachschaft der Technischen Fakultät Erlangen e.V.

As events happening during a CTF competition are hard to foresee, these rules may be enhanced or changed at any time before or during the competition. Changes will be announced via email, IRC (#faustctf on Freenode) and/or the organizing team's Twitter account. In cases not covered by the rules, we will decide according to our own judgement.

Schedule

The password for vulnbox decryption will be released at 2015-12-18 15:0015:30 UTC via email, IRC and Twitter. Network connections between teams are enabled one hour later, at which point gameserver traffic and scoring starts as well. The competition is then planned to run for eight hours, but might be expanded.

One tick lasts three minutes. The gameserver checks the functioning of each service once per tick and places a new flag. Therefore, one flag exists per tick, service and team. Flags can be submitted within five ticks from their generation.

Scoring

The total score is the sum of three components:

  • Offense: Points for flags captured from other teams and submitted to the gameserver within their validity period
  • Defense: Points for not letting other teams capture your flags
  • SLA: Points for the availability and correct behavior of your services

As all CTF organizers, we tried to find a formula that is fair to all teams and prohibits tactical tricks. The result is not as easy as we wanted it to be, but this is what we came up with:

\[ score(team) = \sum_{s \in services} \left( \sum_{ti \in ticks} \big( offense\_score(team, s, ti) + defense\_score(team, s, ti) \big) + sla\_score(team, s) * 0.3 \right) \]

Update: We decided to weight the SLA score at .3 the original value because it dominated the scoring too much.

Every flag has a value for attack, determined by the total number of different flags submitted in a tick. This value is split among all teams who submitted the flag in the tick:

\( offense\_score(team, service, tick) = \)\[ \sum_{flag \in captured\_flags(team, service, tick)} \left( \frac{|teams|}{\left| \bigcup\limits_{te \in teams} captured\_flags(te, service, tick)\right| } \cdot \frac{ multisubmission\_remaining(multisubmission\_count(team, flag))}{\left| \big\{ te \in teams \big| flag \in captured\_flags(te, service, tick) \big\} \right|} \right) \]

Every flag is only scored once for each team. Multiple submissions of the same flag are considered unnecessary load and result in penalties, reducing the points for the initial submission:

\[ multisubmission\_remaining(multisubmission\_count) = 5 / (multisubmission\_count+4) \]

Every submission of a flag will decrease the protecting team's defense score in every tick from submission until the flag has expired:

\[ defense\_score(team, service, tick) = defense\_rating ( capture\_count(team, service, tick) ) \]

The count of currently valid captures is calculated and normalized by the maximum possible count of currently valid captures for one team:

\( capture\_count(team, service, tick) = \)\[ \left\lceil \sum\limits_{te \in teams} \sum\limits_{ti \in ticks} \left| \big\{ flag \in \big( placed\_flags(team, service) \cap captured\_flags(te, service, ti) \big) \big| ti \leq tick \wedge \neg is\_expired(flag, tick) \big\} \right| \div valid\_ticks \right\rceil \]

The normalized count of captures is rated to get the protecting team's defense points:

\[ defense\_rating(capture\_count) = \left\{\begin{array}{lcl} capture\_count = 0 & : & 1\\ capture\_count = 1 & : & 0,5\\ \vdots & : & \frac{50 - capture\_count}{49 \div 0,5 }\\ capture\_count \geq 50 & : & 0\\ \end{array}\right. \]

The SLA is determined by the number of status checks with result "'up"'. (Update: To account for checker irregularities, we will handle status "recovering" the same as "up".) The teams with the best SLA will get the same points as the highest offense score for the respective service:

\[ sla\_score(team, service) = \frac{| checks\_up(team, service) |}{\max\limits_{te \in teams} | checks\_up(te, service) |} \cdot \max_{te \in teams} \left( \sum_{ti \in ticks} offense\_score(te, service, ti) \right) \]

These formulas use the following definitions:

\( placed\_flags(protecting\_team, service) \): Set of flags to be protected
\( captured\_flags(submitting\_team, service, submission\_tick) \): Set of flags submitted to the gameserver
\( multisubmission\_count(submitting\_team, flag) \):Number of attempted submissions of the same flag
\( is\_expired(flag, tick) \): Whether the flag has become invalid before the given tick
\( valid\_ticks = 5 \): Number of ticks a flag is valid for
\( checks\_up(team, service) \): Set of status checks with result "up" "up" or "recovering"

Bug bounty: Responsible disclosure of vulnerabilities and serious bugs in our infrastructure or rules will be rewarded with bonus points according to our judgement as well as eternal fame.

Results & prizes

During the contest, a preliminary live scoreboard is provided. The official final results will be published by the organizing team after the competition. The scores in the contest might not be a good representation of your actual skills, so we encourage you to focus on gaining experience and having fun.

Nevertheless, the following prizes will be payed out to the best-ranked teams:

  • First place: 512 Euros
  • Second place: 256 Euros
  • Third place: 128 Euros

An additional "first blood" award of 32 Euros per service will go to the team that is first to submit a correct flag for each service.

We will do our best to get the price money to the winners smoothly. Please understand that potential transaction fees will have to be covered by you. For regulatory reasons, we might also require you to specify payment information for each of your team members and transfer the prize money split to them.

Technical behavior

The vulnboxes of other teams are the sole target for exploitation, attacks against competition infrastructure or any other portion of a team's network (inside or outside of the VPN) are forbidden.

Causing unnecessarily high loads for CPU, traffic, memory, I/O, etc. ("denial of service") on our infrastructure, other teams (including vulnboxes) or any other party is also strictly prohibited. Breaking a vulnerable service of another team is OK as long as it does not lead to resource spikes, but remember that preventing yourself from stealing their flags won't do you any good.

Despite these policies, all participants are responsible for the security of their own hard- and software. We will do our best to enforce the rules, but cannot give any guarantees for other participant's behavior.

Teams are prohibited to filter connections to services on the vulnbox, as long as they don't cause unnecessarily high loads. Vulnerabilities should be patched by fixing the actual bug in the service.

Social conduct

The goal of FAUST CTF is to allow people to practice their skills and have fun. We ask you to avoid spoiling other's fun unnecessarily.

We want the competition to be a pleasant experience for all participants, regardless of their gender, sexual orientation, race, religion, skill level, personal background or any other criteria. Therefore, we do not tolerate harassment in any form.

This especially applies to our official communication channels, i.e. IRC and Twitter. Misbehavior may lead to a ban from these communication channels and ultimately, the same consequences as for any other rule violation (see below). We ask everyone to speak English in the IRC channel, so that everybody knows what's going on.

Enforcement

Violation of the rules or any other hostile behavior may lead to deduction of points, temporary or permanent exclusion from the competition or any other measure deemed appropriate by the organizing team.

We suggest every team to have at least one representative in our IRC channel with a nick starting with the team name. In case of problems this will be our first point of contact, because email delivery can be slow. If we want to stop you from doing something and are not able to reach you as fast as the issue requires, we might temporarily kill your VPN connection in order to get your attention.