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:
the read_3_digits function
the add_art function
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:
Add two ascii_arts A1 and A2.
Add two comments C1 and C2 (Cx is a comment for Ax).
Add ascii_art A3.
Remove comment C2 and add comment C3 (it will be put in C2’s place).
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.
