PHDays III CTF: An Inside Look (Part 1)

On May 23 and 24, 2013, within the framework of the annual international forum on practical information security, Positive Hack Days III, one of the largest competitions on the principle of Capture the Flag - PHDays III CTF was held. This year, a lot of energy was spent on organizing the competition, and the result did not leave anyone indifferent. After this event, we decided to talk about how the preparation for the competition was going and present the view from behind the scenes.



CTF is an information security competition in a format similar to a team game. Each team is provided with its own network infrastructure with pre-installed vulnerable services. Teams must study the services, look for vulnerabilities in them and, using them, attack the services of their rivals. At the same time, they need to maintain their own services in working condition and correct errors in them in order to protect themselves from the attacks of rivals.



When making a successful attack on an enemy service, the team receives some secret data, called the "flag". The flag is evidence of a successful attack. Also, in addition to services, teams are given a set of pre-prepared tasks that can bring additional flags.

')

Begin preparation

Having a great experience of participation and organization of CTF-competitions, we understood that the main thing for the competition is tasks. However, without a good “wrapper” - legends, the game world, fascinating rules and visual components that ensure the immersion of both players and spectators — the competition would be little more interesting than the Olympiad in mathematics.



First of all, it was decided to work out the legend and the rules, and then use them as a starting point for creating the tasks themselves. In an attempt to link together the freshly baked game components, we decided to learn more about the process of creating games.



After developing the concept of a legend, came through game mechanics. First of all, we decided on the format of the competition: it was supposed to be a mixed CTF with regular Jeopardy CTF, services (classic CTF) and innovation - tasks with a limited time to solve and constantly increasing price of points, which we called “boss tasks” . This format, it seems to us, makes it possible to widely evaluate the skills of the participants and brings dynamism to the game.



Next, it was necessary to understand what players can do with tasks and what they get for it. Terms such as the essence of the game, the activity and the involvement of players have surfaced. By drawing entities on the board and defining actions on them, we were finally able to fix the rules. It remains only to determine the balance of the game - the distribution of points for tasks and internal game resources of players.



We started with setting priorities in solving various types of tasks - services and tasks. We needed to decide who is the winner for us - the team that decided all tasks, or the team that completely analyzed all the services, wrote exploits to them and fixed the vulnerabilities in their services. We also needed to compare among themselves any partial solutions of tasks or services. Ranking allowed to create a balanced system of assessments of tasks, which in turn gave the teams the freedom to choose tactics when solving the entire CTF.



An important point in the development of CTF was the fact that the Positive Hack Days forum, within which the competition was to take place, is not limited to the battle of hackers, which means we have a large audience of people who may be interested in what is happening on the game, not to mention the fans teams.



In order not to leave anyone aside, there was a need for a system that visually reflected the course of the game, and also so that there was an immersion in the world we had invented. In fact, this system should visualize game events in the viewer in almost real time. And since we are talking about the game, the system should look like a game: colorful pictures of the world, stylish heroes, beautiful special effects and uneven (as far as possible) events. One muse visited us all: we want the game to look like Heroes of Might and Magic, affecting more than one generation. And it would be perfect if we could run it on various mobile platforms! ..



Special thanks to Maxim Korobtsev ( gametrek.ru ) for his great help in developing a unique game design and CTF rules.

Rules and game mechanics

In addition to the legend, in the first weeks of brainstorming, original game mechanics and rules of the game appeared, adding to the process of solving tasks a bit of strategy. We tried to develop the mechanics in such a way that the players always had a choice of several strategies for playing the game, each of which could lead them to victory.

The game set includes:

• 10 teams :)
• 5 team services (mine)
• 3 common services (no-man’s mines),
• 25 tasks,
• 4 bosses (villains).

Purpose of the game: to collect as much gold as possible. The most “well-off” team wins.





Schematic display of game mechanics (option 1)



Essence of the game:

1. Round - a five-minute interval of game time. At the end of each round there is a miscalculation of the events of the game, as well as updating the flags in the services.
2. A flag is some secret information that can be found in services, tasks or bosses.
3. Gold is an element of the secondary subgroup of the first group of the sixth period of the periodic table of chemical elements of DI Mendeleev with atomic number 79. Also, the type of game points that determines the position of the team in the ranking.
4. A resource is a type of game points obtained from performing actions on team services. Each service brings its own kind of resources.

Types of resources (in order of increasing cost):

• tree,
• coal,
• iron,
• oil,
• crystals.

Resource Actions:

• buying / selling resources for gold (resources can be bought / sold for gold, and the cost of buying resources is more than the cost of sale);
• buying Tasks (see Tasks Actions);
• obtaining a resource for maintaining its service in a healthy state (see actions on command services);
• getting a resource for attacks on rival services (see actions on team services).

1. Service - a vulnerable application with a flag that is updated once per round and that belongs to one of the teams.

Actions on command services:

• Maintenance in working condition of the service. If the service is in working condition, then each round it produces a certain amount of resource for its owner.
• Attacks on the services of rivals. The team can attack the services of rivals by exploiting vulnerabilities in their services. And for a successful attack, the attacking team takes part of the resource of the victim team that was developed for the round. Thus, the more opponents the team attacks, the more resource it gets.
• Protection (patching) of your service. The more opponents successfully attack a team’s service, the less resource it will receive at the end of the round, so it needs to protect its mines by closing vulnerabilities.

The number of points that teams receive for services is calculated using the following formulas:

• If a team stole someone else’s flag, for it it receives 0.4 * C / N , where C is the total amount of the resource brought by the service per round, and N is the number of teams that have passed this flag, including the team that owns the service, if service recognized as workable.
• If the team is the owner of the service and it is in a healthy state during the whole round, the team gets the rest of the resource minus the stolen one.

2. Generic service is a vulnerable application, with a flag that is updated once per round and does not belong to any team.



Actions on shared services:

• Attacks to shared services. A team can attack common services by exploiting vulnerabilities in their services. And for a successful attack, the attacking team gets a fixed amount of gold.

3. Task - this is a previously prepared task with one flag, which requires certain skills to solve it.



Actions on task:

• Opening (purchase) Taska. Initially, all tasks are closed for teams. Information is available on the cost of the task, on the remuneration and skills needed to solve it. In order to start solving a task, the team must buy a task, spending a certain amount of resources on it.
• Solving the task. If the team has decided the task, then it receives a certain amount of gold, depending on the complexity of the task. Also, the skill values ​​required to solve a task are added to the corresponding skill of the team.

4. A boss is a previously prepared task with one flag, with a limited lifetime (3 hours), variable remuneration and requiring certain skills to solve it.



Each round from all teams collects some amount of gold (tax), which is put in the piggy bank boss.



Actions on bosses:

• The decision of the boss. If the team decided the boss, then the remaining lifetime of the boss is reduced to 30 minutes, and the tax ceases to be charged. All teams that decide the boss in the allotted time, divide his piggy bank equally and get a plus to the skills required for his decision.

5. Skill (skill) - the type of game points that show:

• what skills are needed from the players to solve a specific task;
• What skills do team players have based on the tasks they have solved.

Skill Types:

• Web - the skill of working with the Web;
• Reverse - reverse analysis skill;
• Pwn - skill exploitation of vulnerabilities;
• Forensic - knowledge of forensic examinations;
• Ucucuga - skill solving non-standard / non-obvious tasks;
• Crypto - knowledge of cryptography;
• Network - knowledge of network infrastructure and protocols;
• Misc - a variety of skills that are not related to any of the previous species.

Skill actions:

• getting skill for solving task (see action on task);
• getting the skill to solve the boss (see boss actions).

6. Achivka (reward) - reward, outstanding team for the fulfillment of certain requirements. In total, the game can get 42 types of awards.





Schematic display of game mechanics (option 2)

Network infrastructure

When the rules of the game were ready and everyone already had an idea about how the competition would take place and what was needed for it from a technical point of view, the design of the network infrastructure began.

Design

According to all the canons of the genre, the design began with the assignment of requirements based on rules, game mechanics and common sense, and only after that it was possible to proceed directly to the design of the network.



Each team must have its own subnet, and requests from one subnet to another must be hidden behind NAT, so that players cannot distinguish the attacks of opponents from requests of the jury system based on the IP address.



In addition to command subnets, there should be a separate segment for hosting interactive tasks and common services. Moreover, it is necessary that the service could obtain information about the subnet from which the request was sent in order to identify the command.



By default, players' access to all tasks should be limited, but immediately after the team purchases a certain task, the entire subnet should have access to it.



The gaming infrastructure must also include a segment belonging to the jury. It houses the Juray system, a web server with a user interface, the server part of the visualizer, as well as computers from which the entire gameplay is configured and monitored. From this subnet should be open access to all tasks, services and commands. And, of course, for all subnets should be free access to the Internet.

Implementation

The Cisco Catalyst 3750X 24 switch, located in the server room, was selected as the network core. The Cisco ASA 5510 firewall was connected to it, which also served as the default gateway for all segments of the CTF network (teams, tasks, services, jury). He distributed IP addresses (DHCP) for all computers on the network, provided IP address translation (NAT), restricted access to tasks, and also provided access to the Internet.



A Cisco Catalyst 3750G 24 switch was connected to the core of the network. D-Link DES-1008E switches of ten teams and a jury were connected to each network, each of which belonged to its own segment (VLAN).



Also, two powerful servers were connected to the main router for interactive tasks, common services and a jury system:



1. 2 processors, 4 cores, 64Gb RAM, 1Tb HDD.

It was raised by VMware ESXi with two virtual machines. The first was the server version of Ubuntu 13.04 with a set of Jury services:

• Jury System,
• User Interface,
• all necessary for the operation of services.

The second was the service of the visualizer running Windows 7.



2. 2 processors, 6 cores, 128Gb RAM, 1Tb HDD.

It also ran VMware ESXi, which had 36 virtual machines running:

• 20 for interactive tasks,
• 3 for general services,
• 13 under the bosses.

Gaming network layout

General project architecture

As soon as the legend and rules were ready, it was necessary to begin designing the overall system architecture. Next will be described the device site as a whole, as well as each individual component.





Schematic representation of the overall project architecture



The main element is the Jury System - a system that processes all game logic. Its tasks include the handling of game events and the scoring of teams. All other parts are external interfaces rather than independent subsystems.



Flag Acceptor Interface - the flag receiving interface. It is a subsystem of the Jury System; presented in this diagram to display the ability of teams to hand over flags stolen from both common services and from services of opponents.



MongoDB is a game state database. It stores and updates all the current state of the game: points scored by teams, task status (open or closed for each of the teams), complete descriptions of the tasks and bosses themselves, duration of the game, etc.



User Interface (UI) is a user interface of commands implemented as a web application. According to the rules of the game, teams can open tasks, buy / sell resources, solve tasks, receive information about the current rating, etc. The UI is responsible for this functionality. As the initial data for display data from MongoDB are taken. Processing requests from users is implemented through RPC, built in turn on AMQP.



Visualizer is a gameplay visualization system that accumulates and displays game events. Since not all information can be transmitted via events, the system takes some data from the system state to MongoDB.



Network Access Interface - interface to control access to tasks. At the beginning of the game, all tasks are not available to teams. As soon as the team opens any task, it opens access to it using this interface.

Jurey system

As described above, the Jury System (the jury system) is responsible for rendering the game logic. When designing it, we tried to achieve the following goals:

1. Correct implementation of the rules of the game . You can not give any of the participants any cheater. The most important thing for us was the observance of the rules of the game.
2. Stability of work. During the game, participants should not have difficulty working with the jury system. Sudden drops can lead to an imbalance of the whole game: the chances will not be equal and the competition will not be objective. For this reason, to achieve stable performance, we spent a lot of effort on testing.
   
   
   
   For safety net, we created a special system for restoring the state of the game after the fall of the jury system.
3. Work speed From the experience of CTF games, we knew that the delay in responses from the system could be fatal for the team, especially if the task was decided at the last minute. The faster the system processes the request from the user, the faster the team can proceed to the next task.
4. Security. Along with the correct observance of the rules, an important aspect was also the security of the entire system. The game was attended not by simple programmers, but by real hackers. It was impossible to prevent the illegal accrual of points or unauthorized access :)

Objectives are marked, now you can paint the tasks of the Jury system:

1. Processing rounds

• According to the rules, each round new services should be “flooded” with the teams, and at the end of the round, all flags received from the teams must be credited with resources. The flags of the current round are deleted.
• At the end of the round, “remove” taxes from the team if there is an active boss.

2. Processing user requests

• The implementation of the purchase / sale of resources.
• Handling opening / solving tasks.
• Handling bosses solution.

3. Reception of flags from services from teams

• This task includes checking the validity of the flag for the current round and the team that passed the flag (you cannot pass your flags). If the flag passes the test, the one who passes it is placed on a special list in order to receive resources for it at the end of the round.
• The same flag can be handed over by the same team only once.

4. Processing bosses logic

• Bosses must be on time running and killed. The boss killing time is dynamic. After the decision of the first team, the boss will live for 30 minutes. It is worth recalling that the maximum lifetime of the boss is 3 hours.

5. Rewarding the team with achivki

• We came up with 42 different achivki, which can be marked commands. All of them are based on the consistent execution of various tasks by participants, so they in a certain sense characterize the tactics of teams. To implement this logic, it took the most database queries, but at least it's fun :)

Architecture of the jurei system



Interfaces for working with external components:

• Mongo Interface - interface for working with MongoDB. Initially, it was planned to save the current account in MongoDB, so that the UI could quickly get the actual data on the rating of the teams. Based on this goal, MongoDB was chosen because it provides fast reading. Writing to the base for the entire game takes place quite rarely and is timed to external events (passing teams with a flag, task) or by the end of the round (the beginning of the next).
• AMQP Interface - interface for working with AMQP. AMQP was chosen as the message transfer protocol. Based on this interface, RPC was implemented by the UI and Event Manager for the Visualizer and some parts of the UI.

Essence of the game:

• Teams - abstraction for describing commands,
• Services - description of services,
• Bosses - a description of the bosses,
• Resources - description of resources
• Tasks - description of tasks.

The processing of logic over game entities is assumed by “game managers”. I would like to mention some of their implementation features.

• Flag Acceptor - the entity is fully responsible for receiving flags from services from teams. In fact, this is a normal TCP-Server listening on a certain port, having a stream per command with a limited number of connections from the command. Separating the flow for a team is justified by a small number of teams (10 in total), as well as by load distribution: if some team passes the flags more actively than another, this does not slow down the work of others in the general case - the flow planning is given to the OS.
• Boss Manager - the entity is responsible for processing the logic of the bosses. I had to spend a lot of energy to accurately paint the logic of work, even in such non-game situations as overlapping the time intervals of the bosses. However, this logic was justified during debugging.
• Event Manager - the entity responsible for handling all game events. Based on this entity, the logic of game events logging was built, which allowed to process the statistics collected after the game. Absolutely all game events were logged, so in a sense it is possible to make a game replay, but so far we have not planned this idea. Logs from the game can be posted later.
• Service Checker Manager is an entity responsible for checking the serviceability of command services. Perhaps, it is worthwhile to stop here in more detail and to paint how this check takes place.

To check the serviceability of services, CTF organizers pre-write special programs, checkers. Services are usually completely abstract and vary from competition to competition, so in order to have a universal interface for working with checkers. Checkers are launched in separate processes with the following command line parameters: {GET or PUT} command, which determines what action to take - put a flag on the service or check its availability, the IP address of the server on which the service with the flag is checked, the flag itself. Upon completion, the checker must return the completion status:

• 0 - the service is working properly;
• 1 - the service is working, but the protocol is not executed (no flag);
• 2 - the service does not work (connection refused).

Since for one round you need to perform 2 actions for checkers - GET and PUT, they run for all teams 2 times per round: PUT - in the first quarter of a round with a random delay inside the quarter, GET - in the third quarter of a round with a random delay inside the quarter. At the time of launching the checkers for the execution of the PUT command, completion of all checkers that had not had time to work by that time was also completed. The status of the service in this case will display the error of the checker.



Architectural checkers are launched immediately on all services and on all commands, so checking services is the most resource-intensive task of the entire system. Therefore, special attention should be paid to writing checkers - they should work out as quickly as possible and use as few resources as possible. In general, from the point of view of programming, everything is as always :)



The remaining components are not of particular interest. The only thing I would like to note is the game recovery system after the fall. To implement this functionality, many game variables had to be saved to an external base. Since most of the data was already saved in MongoDB, it was decided to add the functionality to save the remaining ones and restore them from the database.



Finally, it is worth noting a few words about the implementation of the Juryan system. The entire system was written in C ++, as it was the most popular language among the system development team. In addition, the author is piously convinced that the same code written in Python will work more slowly. Qt was chosen as the development framework as the most convenient for the developers selected for the project.



Continuation



Authors: slim_d0g blackzert muodov ki11obyte Asperka



PS The PHDays website contains an interesting article analyzing gameplay.