We publish this information to clarify some of the aspects of the competition for the members eager to find out more. Some aspects of this document will change until the first CTF is online. However, the general idea and the spirit of the competition is here. We know you don’t like reading long documents. We will try to compress the information in less words, if possible.

CTF general information and rules:

1. The ranking in the competition is based on the time it takes you to complete the challenges. In order to make it a fair game for all our participants, the time counter starts when you connect to the VPN for the first time until you submit the trophy or trophies. We may impose an upper limit for the VPN access, such as to be able to have access for maximum 24 hours into a 48 hours time frame. We are still discussing this aspect.

2. The trophies are listed as such:

a) superuser-trophy.txt – found into the home directory or the desktop directory of the superuser (root in case of unices, Administrator if we’re going to introduce Windows challenges in the future)

b) user-trophy.txt – found into the home directory or the desktop of the unprivileged user that may be used to get a foothold on the machine. This trophy is not present for the machines that can be compromised without having the need to elevate your privileges (aka having a remote root vulnerability). Most of the time, it won’t be the case.

3. The trophies are SHA-1 hashes of 32 pseudo-random characters. That means: it makes no sense to try to brute-force our submission form. We won’t accept invalid trophies in order to provide you the opportunity to reset the machine if something goes wrong. If you abuse the form, you will get dropped from the competition. Besides, we also need a “proof of work” in order to be eligible for a prize.

4. In order to validate your time, we ask you for a “proof of work” in the next 24 hours after the competition finishes. That means:

a) a screenshot showing your superuser access, or unprivileged access if you didn’t get any further.

b) a technical report describing in detail all your steps needed for compromising the machine.

Please remember: document each step. Because we don’t have unlimited eyes for reading reports, we will review just the reports for the positions which qualify for receiving one of our prizes. We need to be able to reproduce your work based on your report in order to obtain the same result. If the report is incomplete, we won’t be able to provide you the prize. You will be disqualified and the next contestant will take your place. Bear in mind that the product of a penetration testing is your final report. While it isn’t as much fun as breaking machines, it is necessary. Besides, we only ask for a technical report as your work doesn’t need to be presented to a CEO of a large corporation, therefore an executive report is useless for the purpose of the CTF.

5. You don’t need to compromise anything in order to qualify for the raffle, if we’re going to have one. All participants are eligible for it, therefore it all depends on your luck and the entropy collected by random.org.

6. After the competition is finished and the winners are announced, we will publish the configuration that we used for creating the machine or the machines that were part of the CTF. We will also publish any information for creating the base image for the configuration deployment. The configuration will be published as SaltStack state and the files that were deployed onto the CTF machine. For reference, we use salt-ssh for deploying the configuration as it is a setup that doesn’t use a master – minion architecture. We will also publish our unit tests for validating the fact that the CTF machine holds the proper configuration.

7. In case of disputes, we may publish the reports of the people that were disqualified in order to be peer-reviewed by the community. We may also publish the reports of the winners for the same purpose. We won’t make this information to be available for the public eyes. The published reports, if the situation asks, are going to be available just for the participants. We design the challenges with public vulnerabilities or known misconfigurations. Most of them can be found on exploit-db.com or other public sources. We don’t target 0-day vulnerabilities, so you won’t have to disclose your knowledge about arcane methods for getting access to a machine. We use Kali and the basic tools for the purpose of demonstrating the concept of a CTF challenge when we discuss the technical aspects of a competition.

8. The use of mass-vulnerability scanners is discouraged. It will likely drop your VPN connection or freeze the target machine. We don’t design the challenges to be one-click pwn. The proper information gathering is the key for success. You should think before you act. Our challenges are not script kiddie friendly, especially if we’re going for tiered competitions where multiple levels are provided in order to advance.

9. We don’t provide any hints during the competition. We provide you the same advice as the awesome folks at Offensive Security: Try Harder™ . However, we will answer properly formulated questions about certain aspects of the competition if there are technical problems. A properly formulated question is something like: “I tried to use the tool foo with the arguments bar over the protocol baz in order to obtain information X”. Even though we make our best to be sure that the challenges are reliable, edge cases may appear. We kindly ask not to abuse the support during the challenges. Most of the time if the information you’re looking for isn’t there, then it isn’t there. Think of this competition as of a proper penetration test. There’s no hand holding there, and even more, in a proper penetration test don’t have the luxury of resetting a machine if you crash the services or the machine goes into a kernel panic. You do have this luxury here.