iCTF 2013 (06.12.2013)


Профессор Giovanni Vigna из Калифорнийского университета г.Санта-Барбара, США

Начало соревнования:
6 декабря 2013 года в 20-00 (December, 6nd, 08:00h PST)

10 часов

Тип соревнования:
«Классический» CTF

Тип участия:


IRC: irc.ictf2013.net Port: 6667 Channel: #ictf


 Add your comment
  1. Attention, iCTF 2013 participants! With the goal of having a game that’s
    well-understood and enjoyed by the participants, we’re releasing the game
    description early. Here it is!

    This year’s iCTF is played by accomplishing a series of «goals», each
    representing a step toward world domination. For example, let’s say that,
    being a country, you wish to nuke your fellow competitors (other countries)
    out of existence. Before you can do this, you need to build a nuke. Before
    you can do that, you have to enrich some uranium, and before that, the
    uranium has to be mined.

    Each of these major goals comprises many minor ones. Mining uranium
    involves cooperation between your uranium mines, transportation
    infrastructure, and heavy machinery industries. Refining uranium requires
    careful coordination of many science labs and government offices, and,
    obviously, building a nuke and running a nuclear war is complex business.

    Sadly, each team will start with no uranium, no enriched uranium, and no
    nuclear weapons. Thus, the first goal is to mine some uranium.

    Of course, the other countries want to get their uranium before you do, and
    this is where modern warfare comes in. Modern warfare is fought not with
    guns, but with computer programs. Why spend the effort to blow up your
    enemy’s excavator when you can just hack in and have it drive right down
    the vertical shaft? The latter is considerably safer and more cost
    effective, and that’s why everyone’s doing it!

    While trying to push your fledgling nuclear program along, you’ll have to
    defend it against your opponents’ cyber attacks. And, while doing this, you
    might as well throw some lobbies of your own.

    Each goal involves a series of steps. For example, when mining uranium, you
    must first perform maintenance on your mining equipment, then transport the
    equipment (without breaking it) to the mines, mine out the uranium, and
    transport the uranium back. At each step, different parts of your
    infrastructure are required, and it’s those parts that will be targeted by
    your cyber-enemies. If your enemies’ attacks are successful and undetected
    against the portions of your infrastructure that are critical during the
    current stage, your uranium production capacity will be negatively
    impacted, and it will take you longer to progress to the next goal.

    The astute reader might have noticed the qualification «and undetected». If
    you detect a cyber-attack, you can stop it before it can wreak cyber-havoc.
    Stay cyber-vigilant. Your country has developed a state-of-the-art
    cyber-situation-awareness web form which allows you to designate certain
    «network flows» as malicious. Use it carefully. If you mark an attack as
    malicious, you escape its effects. However, if you mark benign traffic as
    malicious, you will cause errors in your infrastructure that are identical
    to an undetected attack.

    Naturally, you can’t risk an international incident, upset the UN, and so
    forth, so you have to be careful, attacking only through a third-party
    proxy. Fortunately, the Zombie Dwarf Institute, emboldened by earlier
    successes in cyber warfare and sabotage, has gone rogue and turned into a
    full-fledged dark ops cyber-unit. You will submit your cyber-exploits to
    cyber-ZDI, and they will use it in their cyber-sabotage.

    In exchange for your exploits, ZDI will pass on some of the intelligence
    they gather, in the form of intelligence credits. You can spend these
    credits to temporarily make parts of your infrastructure immune from
    attack, if you can’t be bothered to properly identify attack traffic.

    The winning team will be the team that builds and launches the most nukes.
    No one cares how much un-enriched uranium you have if you’re not packing!

    The technical details are as follows:

    Each team will be given access to a virtualized host with a number of
    vulnerable services. The organizers will host these hosts, but the teams
    may ask for their servers to be reinitialized at any time.

    There are four goals in the game, each with a number of steps that are
    carried out in a cyclical pattern. Each step has an associated set of
    «critical» services that needs to be up, running, and uncompromised in
    order for the step to be successful. Completing a cycle will result in a
    certain amount of resources, counted toward the total number required for
    that goal. This amount is inversely proportional to a combination of the
    following factors:

    1. The percentage of attacks that were successful against the critical
    services and that went undetected.

    2. The amount of non-attack traffic to the critical services that was
    mis-identified as malicious.

    3. The number of times that the critical services were non-functional.

    Exploits are to be delivered to the organizers, who will run them against
    the current critical services among the other teams working toward the same
    goal. You will not be attacked with your own exploits, don’t worry.
    Additionally, ZDI will run all exploits against all eligible teams in a
    balanced way. That means that if there are fewer exploits submitted for a
    service, they will be run more frequently, rewarding rapid exploit

    The exploits must be a python source file or a tarball containing python
    source files. A testing environment for exploits will be provided on the
    teams’ hosts. Your exploit must not permanently break a service’s
    functionality, or require a service restart. Please keep in mind that *any*
    abuse of the game infrastructure, including abuse or fingerprinting of the
    exploit submission service, will result in immediate termination from the
    game with no warning.

    Teams that are successful in carrying out an exploit (i.e., they capture a
    flag, and are undetected) will receive ‘intelligence credits’ representing
    the resulting data disclosure. These credits can be used to «protect» their
    services at specific times.

    There are three ways to protect services from attack:

    1. Patch the vulnerability, without breaking the service’s actual

    2. Successfully mark the connection (identified by start time, source port,
    and destination port) as malicious.

    3. Spend credits to make a service invulnerable to attack for the current
    instance of the step. Only one service may be made invulnerable in this way
    at a time.

    Teams can only attack other teams that are carrying out the same mission.
    If a team advances to the next mission alone, they will be put in a waiting
    mode until at least one other team advances to that mission. While they are
    in this mode, the resources required for the previous mission will be
    gradually reduced.

    The winner of the game is the team with the most resources out of the
    highest achieved goal. That is, if the states of the first goal produce
    resources of type X and those of the second goal produce resources of type
    Y, only the number of Y resources count toward the rankings.

  2. я чутка приболел. Я правильно понимаю, что собираемся в политехе в 19:00 в эту пятницу?


    Your goal is to be the best country in the world, building up and unleashing a nuclear arsenal!


    Your Machine

    You will be given non-root access to a virtualized server. On this server, there will be a number of services running.

    Your job is to keep the services up, detect attacks against the services, patch your services, and develop exploits to be used against other teams’ services.

    When patching your service, you must keep the original functionality. If any of the scripts that simulate a user using the service is unable to fully exercise your service, then the service is considered non-functional.

    You will gain Resources (to progress in the game) by keeping your services up and detecting attacks. You will gain Credits to spend on bonuses by developing exploits.

    To detect attacks, you will be able to use tcpdump on your machine’s interface. There will be a publicly-accessible web interface where you can specify if a netflow in the last round was an attack and you will instantly see the results of your detection (i.e., if the attack was correctly detected or if the detection represents a false positive).

    A netflow is identified by (source_ip, source_port, dest_ip, dest_port, timestamp). The timestamp that you see in the web interface will be when our side created the TCP connection. The timestamp you see from your vulnerable machine may differ slightly.

    The Levels

    There are four levels in the game. Everyone starts out on the first level, with zero Resources. At each level you generate a specific Resource, and once you generate enough Resources you will be promoted to the next level.

    You will only attack and be attacked by teams at your level.

    Your team’s ranking will be based on what level your team is in and how many Resources you’ve collected in your current level (that is, Resources collected in previous levels don’t matter).
    Teams in level 4 will be ranked above teams in level 3, and so on.

    Collecting Resources

    Here’s what a sample level looks like (specifics like color and so on could change):

    Red states are active, Blue states are inactive, and the smaller light blue nodes are services that are associated with each state.

    In the example, “Mine Uranium” is the active state. Service dexware is active, because it is associated with “Mine Uranium.”

    We will only generate traffic against active services. This traffic will consist of “benign” traffic and “attack” traffic. Part of your job is to decide which is which.

    Each change of the level is called a “tick.” The tick will change (almost) every 3 minutes.

    So, how do you create Resources?

    Resources are allocated every “round.” A round is a complete traversal of the level, with the XMAS state being the last state.

    The XMAS state is special, it will last for 1 minute, and there will be no traffic. This will give you time to identify attack traffic in the previous states.

    So, there will be a round every 10 minutes, as every level has 3 states and 1 XMAS state. After the XMAS state, a round is complete and Resources are awarded to each team.

    Calculating Resources

    Every round you will be awarded Resources for how well you performed in that round.

    The maximum Resources you can receive in a round is 500. The lowest is 0 (but you’re not going to be that team).

    300 of the 500 Resources are rewarded for having the active services up.

    So for N active services on the round, if you had Nup of those services up and functional, you will receive 300 * (Nup / N) Resources.

    The remaining 200 of 500 resources are awarded based on how many attacks you detected. A successful undetected attack is an attack that:
    1) correctly captures your flag
    2) has not been marked as an attack (more precisely, NONE of the associated netflows have been marked).

    You will also lose Resources for each incorrectly marked benign netflow.

    So for Na number of successful attacks, Nd number of attacks you detected, and Nw number of incorrectly marked netflows, you will receive 200 * ((Nd — Nw) / Na) resources. Of course, if there are no attacks, you will receive 200 Resources.

    So, for the math types, here’s the whole formula:
    Total_Score_Of_The_Round = max(0, 300 * (Nup / N) + 200 * ((Nd — Nw) / Na))

    Let’s look at an example.

    For one round of the example level above there are two services involved (dexware and mathconsole),
    which are active each in two states. In total, there are 4 instances of a service being up and «attackable» in a round.

    Let’s say that, out of the 4 service instances, you had 2 services up. And, during the round there were 2 successful attacks, and you correctly marked one netflow as an attack, but you also incorrectly marked two benign netflows as an attack.

    How many Resources would you receive in this round? Go ahead, I’ll wait.


    N = 4, Nup = 2, Na = 2, Nd = 1, Nw = 2

    (300 * (2 / 4)) + (200 * ((1 — 2) / 2) = 150 + -100 = 50

    Now let’s say that you do better. Out of the 4 active services, you had 4 services up. And, during the round there were 4 successful attacks, and you correctly marked four netflows as an attack, but you also incorrectly marked one benign netflow as an attack.

    N = 4, Nup = 4, Na = 4, Nd = 4, Nw = 1

    (300 * (4 / 4)) + (200 * ((4 — 1) / 4) = 300 + 150 = 450


    To be promoted to the next level, you must generate enough Resources at the current level.

    Here is our current idea of the limits for each level (subject to change before and possibly during the competition):

    L1: 6,000 resources
    L2: 4,500 resources
    L3: 3,000 resources

    Therefore, you must generate 6,000 resources to be promoted from level 1 to level 2, and once there you must generate 4,500 of level 2’s resources to be promoted to level 3. And so on.

    If you are the first team to be promoted to a level, you will not start generating Resources, which means that there will be no traffic to any of your services. Use this time to develop elite exploits. Once another team is promoted, you will both start generating Resources.

    Services, Exploits, and flag_id. Oh My.

    In the CTFs of old, each service had a single flag.

    Our services have multiple flags, and these flags are part of the service. A flag could be user passwords, the status of the user, or nuclear launch codes, depending on the service.

    Don’t steal all the flags; you’re supposed to be stealthy.

    Your exploit should only steal a specific flag. But how will your exploit know which flag to capture?

    In comes the concept of a flag_id. A flag_id identifies the specific flag to capture and is service dependent. For instance, if the flag are user passwords, the flag_id could be the specific username. If the flag is the status of the user, the flag_id could be the specific user_id. If the flag is the nuclear launch codes, the flag_id could be the specific nuclear site.

    Imagine the following database table for a fake service:

    | user_name | user_password | status |
    | adam | 9cb4afde731e9eadcda4506ef7c65fa2 | ICTFFTW |
    | test | 098f6bcd4621d373cade4e832627b4f6 | FLG47M9glVIWW3AG |
    | l33t | 11119102f1634c7967cc1b58947295d8 | FLGmBSlIkZoWSy2p |
    | vigna | 9cb4afde731e9eadcda4506ef7c65fa2 | FLG4V2tHkaodSy2p |

    The flag_id for this service is the user_name. The flags are clearly the status.

    If your exploit is given “l33t” it will be expected to return “FLGmBSlIkZoWSy2p” (of course by exploiting the service).
    If your exploit is given “vigna” it will be expected to return “FLG4V2tHkaodSy2p”

    Unlike those poor souls who competed in the 2012 iCTF, you will not have to guess what the flag_id is for a service. The web interface will clearly state, for each service, a description of the flag_id.

    So, your exploit will accept, as a parameter, the ip and port to exploit, and the flag_id to capture the specific flag. Your exploit will return only that flag.

    Your exploit will either be a single Python script or a .tgz bundle.

    So that you can test your exploits, your vulnerable machine will have a script that will run exploits exactly as we will run them. You’ll only be able to run the exploits against yourself.

    Specific exploit interface details and examples will be released Thursday.

    Submitting Exploits

    You will submit your exploit for a specific service through the web interface. Only your latest exploit for each service will be run. This information will also be shown on the web interface.

    We will test your exploit to make sure that it can successfully capture the flag from an unpatched service. You will get automatic feedback from this process that will be shown in the web interface.

    Any team caught messing with or trying to evade the testing service and automated feedback will be banned from the competition. Exploit each other, not us.

    Your exploit should steal the flag. DOSing the teams’ service is also grounds for banning. Play fair, win fair, write dirty exploits.

    Running Exploits

    Each tick ZDI (aka us) will run at most one exploit against each active service for each team. Eligible exploits are ones that have passed the exploit submission process (see previous section), and are from teams in your level.

    The specific exploit to run against a particular team’s service will be randomly chosen between all eligible exploits from teams in that level.

    Every time one of your team’s exploit script successfully captures the correct flag for the service, AND DOES SO UNDETECTED by that team, you receive one Credit.

    For example, if you are the first team to submit an exploit for service mathconsole, when mathconsole is active, your exploit will be run against all the teams in your level (except for you). This means that if none of the teams detect your exploit and everyone has their service up, you will get at most N Credits, where N is the number of teams.

    However, once another team submits an exploit for the service, the most credits you can get is N/2, and so on.

    You will know from the scoreboard who has submitted an exploit for what service.

    Spending Credits

    You worked hard to write those stealthy exploits, and we want to reward you for it.

    Welcome to the auction house.

    Here, you can spend your hard earned Credits on bonuses to help your team. Or hurt your competitors.

    Each auction starts at the beginning of a tick, and ends 30 seconds before the end of the tick.

    During the action, you can place a bid on one of the bonuses. Each bonus will have a different minimum bid. You cannot revoke a bid, and you cannot place more bids than you have credits.

    Each bonus item can only be won by a limited number of teams, specifically the teams that bid the most.

    You will not know what the bids are for the current auction, but you will know the winning bids for the previous auctions.

    If you successfully win the bid, you will receive the bonus and your credits are deducted. If you loose a bid, you get back your credits.

    What are these bonuses, you ask?

    1. Protection for the next tick. If you win this bonus, you will not be attacked during the next tick.

    2. Mute a team’s exploits. If you win this bonus, we will NOT run exploits from a given team for the next tick. You tell us which team when you make the bid.

    3. Show attack netflow. If you win this bonus, we will tell you one netflow id of an attack in the current tick (the current tick that you’re placing a bidding). It’s your job to identify this netflow as an attack.

    4. Purchase our exploits. If you win this bonus, we will give you a ZDI verified exploit for a service of your choice. It’s your job to submit it as your own, make tweaks as necessary, and so on. You will only be able to buy this bonus once.

    Oh yeah, one more thing: you’ll be able to set a message that will be shown to everyone if you win a bonus. We’re a university, so keep it clean.

    Important Note

    We reserve the right to change the parameters of the game. But at least we’ll update you when we do.

    Please ask if you have any questions, but understand that we are working on getting the game up and running and stable and scalable. If you think you can answer another team’s question, please do so.

  4. Teams!

    This email contains *key* information on how to successfully «Pown All The

    As described in a previous email, you will need to develop exploits and
    them to us for evaluation. Once they are approved, they will be added to
    game network, and they will be fired against the other teams! (That’s
    pretty cool, you may want to continue reading this email. Just saying…)

    This email describes how the submissions need to happen.

    You can submit your exploit through the web interface. This year, you will
    able to submit two kind of exploits: a Python script, or a bundle.

    — Python script submission

    You need to provide a self-contained Python script that defines the
    class according to the following Python-based interface:

    class Exploit():

    def execute(self, ip, port, flag_id):

    # Your exploit gets as parameters the IP/PORT of the service to
    # attack. The IP is a string, the PORT is an integer. The FLAG_ID’s
    # role has been described in a previous email.

    # Put your awesomeness here. You are free to import/use whatever
    # standard Python library you want.

    self.flag = [ … ]

    def result(self):
    return {‘FLAG’ : self.flag }

    The execute() and the result() methods are *mandatory*. Everything else is
    to you. To test and run your exploit, we will first call the execute()
    and we will then call the result() method. Make sure that result() returns
    flag as in the example (a dict with ‘FLAG’ as key). Take the exploit.py
    attached to this email as a starting point.

    The python libraries that you will be able to use are the ones available on
    the vulnerable box, no more!

    — The bundle submission

    You will be able to submit a bundle of Python files. The bundle must be a
    file. The bundle must contain a file called «exploit.py». This file will be
    taken as your main script, and it should implement the Exploit class as
    previously discussed. Of course, you will be able to add additional Python
    files. The directory where we will extract the tgz will be added to the
    sys.path, so you will be able to load the additional code. Take the
    in attachment as a starting point.

    Now, some other important details.

    — Requirements and vetting process

    The script *must* be *pure* python. No, don’t write your stuff in brainfuck
    then run it through os.system(). Just don’t.

    The script *must* only steal the flag. That is, it *must not* overwrite any
    flags, and it *must not* damage the target VM. If you try to do something
    nasty, your submission will be rejected right away, and we will get upset.

    If you submit a bundle, no pre-compiled bytecode is allowed. Don’t
    include .pyc or .pyo files, or, how surprisingly, your submission will be

    If you are curious about how we are going to test your exploit, take a look
    the attached «test_exploit.py» script (described in the next section). We
    using the same code only as a starting point to approve your submission,
    it’s good that you know what’s going on, so that you can catch the easy bugs
    early on.

    In case you submit your exploit to us and we reject it, automated
    feedback will be provided (like «Wrong flag», or a small stacktrace in case
    an exception).

    — Testing

    You will be able to test your submissions before actually sending them to
    In attachment you can find the «test_exploit.py» script that you can use to
    test your exploit locally. This script will be made available on the
    VM as well. As the submissions to our infrastructure are rate-limited, our
    advice is
    that you first test your exploit locally and, only when it’s working, you
    submit it to us.

    As a final friendly reminder, all the attacks against the testing
    and all attempts to fingerprint the system will *NOT* be tolerated.
    As we have all your submissions, it is easy for us to track who you are,
    and ban you from this and future iCTFs. We know you are cool. Play cool.

  5. Фотик возьму, наверное…

Leave a Comment