31C3 CTF - Mynx (Pwn 30)

Intro

After selecting this challenge we were welcomed by a rather laconic description:

Once connected to the service, we were greeted by the following menu:

Menu

It appeared to be some kind of a storage service for ASCII art. We could upload ASCII arts, add comments and apply filters. After fuzzing the input for a while we didn’t discover anything useful, so it was time to look inside the executable.

Reversing the binary

 

The file command revealed that it was an x86 ELF executable. After opening it in IDA we could see a main loop which was responsible for displaying the minimalistic menu shown in the previous picture. Its C representation looks something like that:

Main function

Because vulnerabilities are often caused by badly handled user input it is a good idea to look for some potential overflows. There are 3 places where input from user is requested:

1. the read_3_digits function
2. the add_art function
3. the add_comment function

Unfortunately we were not able to find any  obvious problems in the code. In every single place the length of input was limited and buffers were large enough to store the input data.

When adding a new structure, the program looked for the first free slot and placed the structure there. We reconstructed the “art” and “comment” structures, which were both 256 bytes long:

Vulnerability

These structures were filled when a new ASCII art or a comment was added. The interesting fact was that, when a comment was added, 252 bytes of input were read into a buffer of size 251, so there was an overflow after all! 

It was just a single byte, but that was all we needed. Using this one byte we could overwrite the first byte of the next structure which was a type field. So we could convert a comment object into an art object and vice versa. The first one was particularly useful because when a comment was interpreted as an ascii_art then the first 4 bytes of the comment string were interpreted as a function pointer named “filter_method”. By applying a filter we would be executing arbitrary address with our string as first argument. In other words, we could simply call system() and get a remote shell. :)

All we needed was to overwrite a comment and change it to art. After that there would be two ascii_art structures with the same id (ascii art and its comment converted to ascii_art). We needed our transformed comment to be earlier in memory so that it was selected first. We achieved this by making use of the  remove_comments function. This step could have been done in many different ways but we discovered the following first: 

1. Add two ascii_arts A1 and A2.
2. Add two comments C1 and C2 (Cx is a comment for Ax).
3. Add ascii_art A3.
4. Remove comment C2 and add comment C3 (it will be put in C2’s place).
5. Remove comment C1 and add comment C2 (it will be put in C1’s place).

With the last one we overwrited C3’s type field and turned it into an ascii art. It was placed before the original A3 and thus when ascii art with id=3 was requested our spoofed art was selected. Applying a filter resulted in arbitrary address call with the argument being an address of a controlled string.

Exploitation

Because ASLR as well as NX were enabled (no PIE/RELOC though), we needed a memory leak in order to call the system function (or we could have created a ROP but come on - we had function call with our string as argument).

Fortunately for us, there was a printf function imported by the executable, so we could force a format string vulnerability by simply calling it with a controlled string.  Sadly, our format string was not stored on the stack, so leaking .got entries became much, much harder than it typically is.

Cheer up, not everything was lost. The “main” function is not called directly at program startup but through the __libc_start_main function which is a part of libc, so the return address from the main function also resides in libc. And this one is definitely on the stack. 

After finding the correct offset and leaking the address, all we needed to do in order to get the flag was to find out what version of libc the system was using (so we could calculate the distance between the leaked return address and the system function). 

In the end, we failed to  identify the specific libc build and consequently had to brute force the offset remotely. It took approximately 8 hours, but we eventually got the system address right and obtained the flag.

 

         

Conclusions

To exploit this challenge we used function pointer overwrite, combined with custom memory management, and then forced format string vulnerability by calling printf function. Knowing libc base address we called system() and spawned remote shell. 

It was a great CTF challenge and I personally enjoyed how the solution leveraged one vulnerability to cause another. I thank the organizers for interesting contest and I hope it will be even better next year.