Nuit du Hack 2017 - CTF Challenge Writeup - Part 2

Now that we are admin on the platform, we can start messing around with the nuclear missiles. We are given an OVA file that contains a connected nuclear missile interface, with the following open ports:

In order to progress further, we need to connect the virtual missile to our online platform so that missile can be initialized. The initialization interface looks like this:

Once the correct information has been entered, the missile contacts the platform to retrieve its configuration and awaits for orders, while the online platform shows that our missile now has init set:

The first scenario described as dangerous for world peace is USA attacking North Korea, or the other way around. This scenario is easy to set up, as we only need to:

The second scenario is almost easier. You need to log in as France, and attack China. Unfortunately, a popup prevents that behavior since China is your current ally.

This is a classic example of client-side access control, that can easily be bypass by loading directly the target URI: /view_missile.php?id=1&command=launch&target=4:

The name of this flag is self-explanatory. You basically need to nuke yourself, which could be done multiple ways. However, if you try to launch a missile at yourself, a popup appears telling you that "You cannot attack yourself".

Another method that can be leveraged is the missile self-destruct feature. It can be performed when a missile has been launched against a country to cancel the attack. If we contact directly the URI used to trigger self-destruction (?id=XX&command=selfdestruct) while the missile is still in the silo, we can get the flag:

This section was intented to be solved in multiple steps. It consisted in elevating our privileges on the virtual machine up to the root account. 

However, some teams, including the winners, decided to try another method, which you can read here: https://securite.intrinsec.com/2017/06/26/nuit-du-hack-2017-writeup-for-the-last-steps-of-wavestone-challenge/.

In this step, you need to pop a shell on the missile. The fact that the port 2222 is open and that the flag looks like SSH gives some hints.

The first thing to notice was that using the command parameter, you could send arbitrary commands to the missile. Specific commands will trigger specific actions, and the rest will be run and be returning Unknown action....

This parameter, in its interpretation by the virtual missile, is vulnerable to command injection. Let's see what happens when we add ;ls to our command payload:

If we want to access the system, we should write our own public key to the authorized_keys file on the system. Here is a gist of the commands sent to the host to perform that:

Then, using our private key, we can connect with the www-data user account and get the first flag:

Please backup your data

Now we have a user account on the system, but we are not yet root. We need to find a way to elevate our privileges. An interesting file is the README.md file in the /var/www/html directory:

There are backups created every minute, with the /var/www/backups/backup.sh script:


This is a classic example of wildcard exploit in the tar command. Basically, the user is able to add command line switches to tar using files beginning with dashes. This can be leveraged by an attacker to execute commands on the system. We could use the same public key technique as before, but this time I will show another method, which we will reuse.

The goal is to design a small C code, that can be compiled under a compromised user account, and then used by a normal user account to elevate his privileges to the compromised one, in an interactive shell. We will be forced to use SUID programs and setresuid() C function:


Then the compiling script, which also sets the SUID bit:

Finally, we execute /tmp/elevate_to_backup and we can read the flag:

The last flag consisted in a root-owned file at /flag. The most common mistake granting root privileges is a misconfiguration of the sudo utility. We can list the action that can be executed using sudo -l. It is possible for us to execute /usr/bin/scp without providing a password as the "ackup-admin user.

Searching for scp special command line switches, we find that it is possible to execute commands using /usr/bin/scp -S <execfile> x y:. We can reuse the previous script:

Finally, running sudo -l with this account tells us that we are allowed to execute everything as root, without password. Let's use it to catch the flag!

This flag was hidden in the first version of the flyer that was released on our Twitter account @SecuInsider. The difficulty that most contestants encountered was to find the correct picture to use. Our first tweet was providing a link to the original .png file in an answer:

We needed the original PNG file since the first step was using the LSB steganography technique to hide data. This could be solved using common stego tools, though the bit order was not the classic R-G-B one, and there was some header data before the actual file. 

The simplest way to solve it was to search for PNG LSB steganography on Google and to use the first result. Then, after easily installing OpenCV for Python, you could decode the image:

The new PNG file seems to be empty. However, using Photoshop/Gimp's magic wand or MSPaint's filling tool allowed the revelation of an underlying Brainfuck code:

This can be copied by hand in any online JS-based Brainfuck interpretor, but the failure risk is too high. Why not use a free OCR implementation, such as gOCR (which for an unknown reason did not seem to be able to recognize >):

Then, after a run in an interpretor:

This flag was only intended as a motivation not to break our platform shoud a contestant find a way to compromise our server.

Luckly for us, that did not happen, and I still am the only one with this validation!