Skip to content

A/D CTF Platform Overview

Network

A/D Network
A/D Network

The competition takes place in the 10.10.0.0/16 subnet. Each team has a dedicated portion of the subnet in the 10.10.{TEAM_ID}.0/24 address space. The first half of the team's subnet is reserved for services (10.10.{TEAM_ID}.0/25); the second half (10.10.1.128/25) is used by the players.

Players have access to their and other team services (see below) but can not connect to other team players' subnets. Services do not have access to the Internet, players' laptops, or other services.

A connection rate limit is in place to prevent players from DoS-ing services. If you receive connection drops, ensure you are not opening too many connections.

All connections to services are tracked inside traffic dumps (PCAPs). Each team can download the pcaps for all their services.

Scoreboard and Rounds

The scoreboard is available at http://10.10.254.254/. Flag ids are published as JSON at http://10.10.254.254/competition/teams.json. The round length is 3 minutes.

Flags

The flag format is ECSC_[A-Za-z0-9\+/]{32}. Flags are valid for 5 rounds.

The flag submission endpoint is at 10.10.254.254:31337. It follows the same TCP-based protocol as FAUST CTF. A detailed description of the protocol specification can be found here.

Upon connecting, the server will greet you with a welcome message, terminated with two newlines (\n\n). You can submit one or more flags per connection, separated by a single newline (\n). The server will respond with a repetition of your submitted flag, a response code and an optional error message.

The response codes the server may send are:

  • OK: The flag was valid and will be counted towards your score.
  • DUP: You previously submitted the same flag already.
  • OWN: The flag belongs to your own team.
  • OLD: The flag has expired and cannot be submitted any more.
  • INV: The flag is invalid.
  • ERR: The competition has not started or has already ended.

An example conversation with the submission endpoint may look as follows. C and S indicate lines sent by the client and server, respectively. Each line includes the terminating newline (\n).

S: ECSC 2022 | Attack-Defense Flag Submission Server
S: One flag per line please!
S:
C: ECSC_uGUKTZtMUmOmoieKUorXzAqcDZznfokk
S: ECSC_uGUKTZtMUmOmoieKUorXzAqcDZznfokk OK
C: invalid_flag
S: invalid_flag INV Invalid flag
C: ECSC_uGUKTZtMUmOmoieKUorXzAqcDZznfokk
S: ECSC_uGUKTZtMUmOmoieKUorXzAqcDZznfokk DUP You already submitted this flag

To speed up submission, you may submit multiple flags without waiting for the server's response:

C: ECSC_zFFsVPqQLyBErVBVOKBMneqHtVsqTXnN
C: ECSC_GCQs/cdAok/enPzbAwvrz/ASqDtrcyHK
C: ECSC_CLBqjMqMhacCcNssK+SbhvCgmgOPzKtD
S: ECSC_zFFsVPqQLyBErVBVOKBMneqHtVsqTXnN OK
S: ECSC_GCQs/cdAok/enPzbAwvrz/ASqDtrcyHK OK
S: ECSC_CLBqjMqMhacCcNssK+SbhvCgmgOPzKtD OLD Flag has expired

NOP Team

The CTF will feature a NOP team for testing exploits. This team is not displayed on the scoreboard, and attacks against it will not award points. The TEAM_ID of the NOP team is 1.

CTF-as-a-Service

We are providing the computational resources to run the CTF-as-a-Service. Services are developed as docker containers and hosted on our platform. You can focus all your resources on exploiting and patching the vulnerabilities.

Each team has 3 VMs available:

  • 10.10.{TEAM_ID}.1: Production environment
  • 10.10.{TEAM_ID}.2: Staging environment
  • 10.10.{TEAM_ID}.3: Dashboard

Production environment

Services running in production are the only ones counting towards exploitation, defense, and SLA. The production environment runs a copy of all services, and other teams and game bots can reach it. You do not have direct access to your production services, i.e., players of team X will not be able to connect to their services in the production environment. Therefore, you must rely on your superior patching skills to deploy the safest version of your services.

Staging Environment

It exposes a testing copy of each service that can be accessed only by members of the team, i.e., players of team X can connect to their services in the staging environment, while players of team Y are prevented from reaching staging services of team X. You can use staging to test all your patches, attempt to exploit a vulnerability, or admire the beautiful look of your services.

Dashboard

The dashboard is available at http://10.10.{TEAM_ID}.3/ and provides an overview of currently running containers. Selecting the corresponding environment, you can list information on either staging or production. In this view, you can access the logs or restart containers by clicking the related icons shown under Actions in the service table. PCAPs of all production services are also listed in the dashboard for download.

Volume Explorer

A SSH service is available with read-only access to the volumes of all services running in production and staging. You can connect as user user without password at 10.10.{TEAM_ID}.1:2222 (production) and 10.10.{TEAM_ID}.2:2222 (staging). All service volumes are available in the storage directory on the user's home.

Example command:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@10.10.1.1 -p 2222

Service Patching

The service view in the team dashboard provides information on the different services, including the ssh://git@... address to clone these services into players' laptops. Furthermore, it offers the functionality to factory reset data volumes and deploy service images to either production or staging.

To create a new image with a patched service:

  • Upload your SSH Key through the dashboard (key icon on the lower left)
  • Clone the service
  • Add your patches
  • Push the service
  • Check the dashboard and wait for the build to finish

Once the build has finished and succeeded, you can deploy the service to either Staging (S) or Production (P) by clicking the corresponding buttons under Deploy.

Please notice that docker-compose.yaml files are provided only for local testing as they are not used in the remote deployment. Services can also specify in .protected_files.env a set of read-only files that are forbidden to be modified by teams. Commits trying to alter these files will be rejected during git push. Dockerfile is always among the protected files.