SecurityInsider
Le blog des experts sécurité Wavestone

Nuit du Hack 2017 - CTF Challenge Writeup - Part 2



The 15th edition of Nuit du Hack took place at Disneyland Paris' New York Hotel Convention Center. Wavestone was present during the day to present its cybersecurity-related activities. Additionally, we were hosting a jeopardy CTF challenge, with the following rewards for the winners:
  1. An XYZ Mini 3D printer
  2. A retro gaming kit based on a RPi 3
  3. A drone

The article below presents the second part of the intended solution of the challenge's author.

← Link to part 1

Introducing - the connected missile

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:
  • HTTP on port 8080
  • SSH on port 2222
If you try to play with the missile interface online, you will end up with the following alert:


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:



World War III - 1

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:
  • Log in to the USA admin account using the SQL injection
  • Create a new missile
  • Initialize the missile
  • Launch it against North Korea
Once these steps have been performed, the flag appears:


World War III - 2

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:



Suicide

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:



Rooting the connecting missile

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/.

SNMSH - Secure Nuclear Missile Shell

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:


The final step is to tell tar to execute our binary (which for me was in /tmp). We have to create two files in the /var/www/html directory, and a symbolic link pwn.sh to /tmp/pwn.sh:

  • --checkpoint=1
  • --checkpoint-action=exec=sh pwn.sh
Finally, we execute /tmp/elevate_to_backup and we can read the flag:



W00t R00t?

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!



Special flags

Versioning #1 / #2

The hint for these flags was in the name of the flag. Versioning refered to the fact that a Version Control System was used for the web application. In our case, it was linked to Github, so a .git directory was present and could be browsed using the Path Traversal vulnerability (f=../../.git):


Git is mostly using SHA-1 checksums for its objects to handle:
  • Data storage
  • Object relationships
  • etc
Data is store inside objects using Zlib compression, but going through every commit and every object of this repositorty by hand will be too difficult. Instead, why not rely on the standard git utility, provided we have a valid .git directory?
We can use the Path Traversal to list recursively .git sub-directories, then use the LFI to download the files in each directory. We designed a script that automates this task:


Then, we can cd to the root directory and call our favorite commands:

We can investigate further the commit 45bccb292520b4251fe68b3c13b37ab0ec64711b, where a flag was deleted:



I believe I can fly(er)

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:



I hope this is impossible

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!

← Link to part 1

Thanks for playing with us,
Jean MARSAULT

Aucun commentaire:

Enregistrer un commentaire