Skip to content

Intro

Attack / Defense (A/D) is the definition of chaos in the fantastic land of CTFs. You will be challenged with attacks from other teams, availability problems, patches going wrong, sniffing network traffic, attacking other teams, and and and...

If you have never played A/D, expect stressful situations.

via GIPHY

As the A/D CTF of ECSC 2022 will reuse components from the FaustCTF-Framework, we recommend their documentation as a first read. Notice, however, that the ECSC competition will slightly diverge from a traditional A/D CTF. The overall concept is detailed below on this page.

Services

Jeopardy CTFs are made of challenges, A/D CTFs of services. A service is a pseudo-realistic application affected by security vulnerabilities that can be exploited to extract some secrets, i.e., the flags, which serve as proof of successful hacking attempts. Services could consist of multiple components, each storing a different set of flags: we call such components flag stores. Flags can be bound to a specific flag ID that simplifies the identification of the target to exploit.

For example, consider a service representing a Web forum where users can mark their threads as private. Users can also provide personal information in their profile. This information is only used for analytics and is not publicly shown to other users on the platform. Assume that flags are stored in 2 specific locations, representing the 2 flag stores of the service:

  1. as part of a private thread,
  2. as a field of their profile data.

The flag ID for the 1st flag store could be the identifier of the private thread, while the user identifier could be used as a flag ID for the 2nd flag store.

Expect 4 to 7 services, where each service will have one or more flag stores. A flag store can be exploited by one or more vulnerabilities. The number of flag stores of each service will be announced on the scoreboard, but we will not provide insights on the number, type, and expected difficulty of (intended) vulnerabilities.

Game Design

The game design is detailed in the A/D CTF Platform Overview page. A few important things that you may want to take into account:

  • Like traditional A/D CTFs, the game keeps track of attack, defense, and SLA (i.e., the percentage of time the service is up and working as intended). The scoring formula is based on FAUST CTF and explained in the Scoring page.
  • The game server checks the correct functionalities of each service once per round and places a new flag (different flag stores have different flags). The duration of a single round is 3 minutes, while flags are valid for 5 rounds.
  • Teams are required to attack services of other contestants as in a traditional A/D CTF. Organizers do not run exploits against other teams for you.
  • Teams have a limited access to their vulnerable machine. Additionally, there is a staging environment for testing/debugging and a production environment exposed to competing teams.
  • Patch deployment takes place via git. Patches are not tested by organizers before deployment. A patch that breaks the service (e.g., by removal of intended functionality) will lower the SLA of the service.
  • Anonymized traffic dumps (pcaps) of the services running in the production environment are provided.

Human and Technical Behavior

The goal of this competition is to allow participants to practice their skills and have fun. We want everyone to enjoy a fair game. For this reason, we ask you to follow these simple rules:

  • No attacks against the infrastructure. Attempts to circumvent the limitations imposed by the CTF infrastructure are forbidden. We reserve the right to award extra points (and eternal fame) for responsibly disclosed vulnerabilities in our infrastructure. Please open a ticket and inform us whenever you suspect that you are allowed to do specific actions that the infrastructure should have prevented.
  • The production services of other teams are the only allowed targets for exploitation. Players are not allowed to attack competition infrastructure or any other portion of a team's network (inside or outside of the VPN). Attacking other participants' devices is severely prohibited and could lead to disqualification. Weaponizing 0/N-days against tools that other teams might use is also not allowed.
  • No DoS. Causing unnecessarily high loads for CPU, traffic, memory, I/O, etc. on our infrastructure, other teams (including production, staging, and dashboard VMs), or any other party is strictly prohibited. Breaking another team's service through a sheer amount of requests is forbidden. Breaking it through logic vulnerabilities, flag deletion, etc., is not permitted. Generating fake flags is also disallowed.
  • Sharing flags, exploits, or hints between teams is severely prohibited.

During the competition, organizers will actively monitor the network traffic and record violations reported by participants. Violation of the rules or any other hostile behavior may lead to deduction of points or temporary exclusion from the competition by, e.g., sending RST packets or disconnecting a team for N rounds. Severe misconduct will be discussed with the Jury that could decide to permanently exclude a team from the CTF. Please, let's be nice.

Despite these policies, all participants are responsible for the security of their own hardware and software. We will do our best to prevent malicious behavior, but we cannot guarantee other participants' behavior. ECSC organizers are not liable for any potential damage to your equipment.

The rules listed on this page may change as more issues are raised by the participants. Also, the organizers keep the right to change them at any time. Please remember that it is impossible to list all rules and exceptions that apply to the CTF competition. When in doubt, use common sense or ask.

Please also have an look at the rules and the code of conduct created by the Steering Committee.