Skip to content

Latest commit

 

History

History
79 lines (58 loc) · 3.36 KB

0502.md

File metadata and controls

79 lines (58 loc) · 3.36 KB

Playing CTF

We will start our CTF at 12:00:00 5/1. The CTF will end at 12:00:00 5/7.

Attack

Attacks in this CTF should be a proof of backdoor or bugs you found. In other words, an attack should be a runnable program, and it should be replayable by the defending team.

There are two types of attacks. We will call them (1) type-one attack, and (2) type-two attack. Both attacks require a proof to get a point.

  1. Type-one attacks are the ones that exploit the intentionally created backdoors by each team, including both easy one and hard one.

  2. Type-two attacks are the ones that trigger a bug that the authors did not know. Type-two attacks include functional errors and logical errors. Thus, you don't need to get unprivileged access to victim's account or its key to perform a type-two attack: all you need to do is to show that the target server behaves unexpectedly.

GitHub Issue

An attack in this CTF is an "encrypted" GitHub issue created in one of the target repositories. Suppose there are three teams A, B, and C in this CTF. When one of the members in team A creates an issue in team B's repository we consider it as an attack. However, not all of the attacks will award points. Each attack should be validated by the defending team (see the following section).

Attack Validation

An attack can be either successful or not. Each team is responsible for validating the attack within 24 hours. If the attack was successful, the defending team should mark the issue with a success tag. Otherwise, mark the issue with failure tag. If the issue is duplicate from the previous attacks, then you can mark it with duplicate tag.

In summary there are three kinds of tags that you can use in this CTF:

  • success
  • failure
  • duplicate
PGP Encryption

Every attack (an issue) should contain a PGP-encrypted text (ASCII armored encrypted data). Since you can encrypt any files (including zip file), you should put the name of the file in the title for convenience. For example, if your exploit requires multiple py files, then you create a zip file, and write an issue, titled "team1-exploit.zip". The contents of the issue should not contain any other text, but only the PGP-encrypted text for the zip file.

When you encrypt your attack, you should use public keys of the team members in the target team as well as the keys of the instructors. In other words, the encrypted attack can only be readable by the target team, you, and the instructors. Also, the attack should be signed by one of the team members. This way, the other teams cannot replay your attack.

Scoring

We will give scores based on the following scoring rules. A successful attack means an encrypted issue validated by the defending team.

  1. Type-one attacks

    1. A successful attack on an easy backdoor: +1
    2. A successful attack on a difficult backdoor: +5

  2. A successful type-two attack: +5

  3. A failure to validate an attack within 24 hours: -5

Reference

This is a simplified version of Git-based CTF (without automatic exploit verification, and etc.), which has been presented in USENIX ASE 2018. Read this paper if you are interested in: "Git-based CTF: A Simple and Effective Approach to Organizing In-Course Attack-and-Defense Security Competition", SeongIl Wi, Jaeseung Choi, and Sang Kil Cha. In Proceedings of the USENIX Workshop on Advances in Security Education, 2018.