How to take part in RuCTF

We always welcome new people in RuCTF and you have several ways to visit Yekaterinburg and participate in the largest russian student CTF.

Most of the teams receive invitations to RuCTF Final because of:

• excellent performance shown during the qualifying event
• winning one of our friendly competitions

We also have one joint Guest Team, formed by the participants of the other teams, who haven't received an invitation.

You can join the guest team if:

• no team from your University is playing RuCTF 2016 Finals
• you haven't played in RuCTF Finals previously
• there is a limit of max 3 persons from one University in the Guest Team

If your team has not received an invitation and you can't play in the Guest Team you can join RuCTF as an observer or conference speaker. Observers and speakers can't play in Finals, but can watch the game onsite, observe the organizers' work and attend the conference. Any person can register as an independent observer.

RuCTF Quals

This year RuCTFE 2015 served as a qualifying event.

RuCTF Finals invitation process

These rules can be changed at any moment and we recommend to revise this page again before the competition.

Organizers invite best student-only teams according to the results of RuCTF qualifying event. PhD students and recent graduates are allowed.

Invited teams have to provide organizers with photocopies of their IDs to prove their status. Organizers can ask to show original documents before the competition starts.

Invited teams must have from 4 to 7 people. Team playing Finals should be a subset of team playing qualifying event.

RuCTF Finals

At the beginning teams get identical servers with a set of vulnerable services. Teams' goal is to find the vulnerabilities, fix them in their services and use them to get private info (flags) from other teams' services. The game is continuously monitored by checksystem, which regularly puts new flags on teams' services. It also receives stolen flags.

It is difficult to give a complete set of rules for a CTF challenge, so these rules can change at any moment before the challenge starts. That is why we recommend you to check the rules on this site one more time before the competition starts. Just in case :)

DEFINITIONS

TEAM

A group of people with a captain.

SERVICE

A vulnerable application written for the challenge.

FLAG

A string that matches regex: /^[A-Z0-9]{31}=$/. Flag's lifetime is limited and outdated flags do not score.

Checksystem

Automatic system, which puts new flags into the services, checks the availability of the services and manages scores. It also shows current scoreboard and services status.

GAME ROUND

A period of time for checksystem to check and score all the teams. It usually takes not less than 1 minute.

ORGANIZERS /

A group of people that run the whole competition. Organizers do their best to provide quality and fun to all participants. Still organizers are to penalize/disqualify teams for rules violation and to solve the critical situations not described in these rules. Teams should be prepared to meet such decisions with understanding. Also organizers do determine the winner. In general, this decision is based on the scoreboard.

TEAMS ARE ALLOWED TO /

• Do whatever they want within their network segment. Most likely the team would like to patch vulnerabilities in their services or block exploitation of vulnerabilities;
• Attack other teams. Didn't expect that, huh?

TEAMS ARE PROHIBITED TO /

• Filter out other teams' traffic;
• Generate large amount of traffic that poses a threat to network stability of organizers' facilities;
• Generate large amount of traffic that poses a threat to network stability of any other team;
• Attack teams outside of the VPN;
• Attack the game infrastructure facilities operated by organizers.

Game flow

Game starts when organizers provide the identical servers with a set of vulnerable services to the playing teams. Within the first hour the game network is closed and teams should focus on their server administration and vulnerabilities search. An hour passes and the network opens. During the next 8 hours teams can exploit vulnerabilities to get other teams' flags.

SCORING SYSTEM

Key params in scoring system are SLA and FlagPoints. Their values are individual for each service of each team. Team's score is calculated as the sum of the products of the corresponding SLA and FlagPoints of all team's services.

SLA(team, service) is the percentage of the game time, during which that service of that team was in the UP state. E.g. if the service was always UP, SLA would be 1. If 4 hours passed from the game start and the service was UP only during the first hour and then was not UP for the rest 3 hours, SLA would be 0.25.

FlagPoints(team, service) is a non-negative number, which correlates with the team's 'understanding' of that service. If the team can exploit service's vulns to get flags and has fixed those vulns in its own service, its FlagPoints will increase during the game. On the other hand if the team can't exploit service vulns and doesn't bother itself with fixing them, its FlagPoints will rapidly approach zero while its service is being exploited by other teams. If the team can only fix vulns but not exploit them, its FlagPoints will not change. At the beginning all teams have 0 FlagPoints.

Flag's price is the number of FlagPoints got by the attacker and lost by the victim for the stolen flag. It depends on the position of the attacker and the victim in the scoreboard. Flag scores even if the attacking team does not have this service in the UP state.

Flag's lifetime is the amount of time during which the flag should be available in the service for checksystem. Teams should steal the flag and post it to checksystem until it is expired.

If the flag was stolen from a team that was higher on the scoreboard in the previous round, attacker earns the maximum number of FlagPoints which is equal to the number of playing teams. Otherwise the number of FlagPoints decreases exponentially down from maximum to 1. Victim looses the same amount of FlagPoints but does not fall under zero.

Luckily all this complex text can be expressed in pseudocode:

    def on_game_start(team):
        team.sla = [1] * number_of_services
        team.flagpoints = [0] * number_of_services    def on_flag_post(attacker, flag):
		victim = flag.owner
        victim_pos = scoreboard[victim]
		attacker_pos = scoreboard[attacker]
        service = flag.service
        max = number_of_teams
		
		flag_score = attacker_pos > victim_pos ? max : exp(log(max) * (max - victim_pos) / (max - attacker_pos))		attacker.flagpoints[service] += flag_score
		victim.flagpoints[service] -= min(victim.flagpoints[service], flag_score)
    
    def get_score(team):
        return sum(map(lambda x: x[0] * x[1], zip(team.sla, team.flagpoints)))
  

SCOREBOARD

Apart from FlagPoints, SLA and total score, scoreboard shows statuses of each service. Statuses are as following:

• OK — means that service is online, serves the requests, stores and returns flags and behaves as expected.
• CORRUPT — means that service is online, but past flags cannot be retrieved.
• MUMBLE — means that service is online, but behaves not as expected, e.g. if HTTP server listens the port, but doesn't respond on request.
• DOWN — means that service is offline.

NETWORK SCHEME RuCTF