# Service Overview

The website allows to generate/register a new token, which is used as login to the service. After logging in, the service acts as some kind of cloud-storage, so the user can upload files to his folder and download them again.

# The Vulnerability

At the login, the login-token is stored in the user’s session and the login is considered successful if the token is not empty. When uploading and downloading files, the token is used in the path. And, since there was no restriction on the allowed chars nor any escaping, it was possible to perform path traversal attacks.

To leak the tokens of all other users, we simply have to login as ../ and our cloud-storage does not refer to ./data/<someid>/ but to ./data/. Now, the service happily lists all the folders/tokens.

We finished the exploit before the network was open and thought we are done with the service. However, it turns out, the gameserver stores the flags not as text, but as MIDI files. (In hindsight, yes, the name and the javascript piano might be hinting on that, but I somehow did not expect that in this moment of happyness)

# The stego part

Sebi (for some people also known as steg1), our most valuable stego expert, opened up the MIDI file in Audacity and quickly found out that the combination of active notes over the time represent the flag.

# Parsing the flag

Using r2 (only as an hex editor) and wikipedia, I got a really quick overview about the MIDI file format. After the 52B header, the interesting data consists of 4B structs:

Now, we can tell for each time interval, which notes are enabled. Using that bitmap, we simply hardcoded by hand the sequences for each character we found in our own flags. Completely by hand was a bit difficult, so I built a little script that plotted the part of the flag that could not be parsed together with the sequence we have to add to our character mapping.

Also a little problem was that the representation of some characters were subsets of other characters. For example, the beginning of an U is represented like an l. To overcome this issue, we built the parser in a way that it looks ahead and chooses the longest matching character.

# Discussion

Until we fixed all the bugs in our code, the exploit was unfortunately not really useful anymore. I assume this is because each exploit created an empty directory, which massively slows down the speed of the exploit. After talking to some other CTF teams, I found out that the path traversal can indeed be used to upload a php shell. But, somehow I thought during the CTF that the html folder is not writable and have not tried to exploit it. I think with an RCE, it would have been possible to find the new and non-empty folders efficiently.

Although the vulnerability was not very special, the MIDI parsing made this challenge interesting. Overall, the ENOWARS were really fun and we are looking forward to the next one.