DevStart Blogi Napisano Styczeń 19, 2015 Zgłoś Udostępnij Napisano Styczeń 19, 2015 IntroAfter selecting this challenge we were welcomed by a rather laconic description:Once connected to the service, we were greeted by the following menu:MenuIt 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 functionBecause 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 functionthe add_art functionthe 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:VulnerabilityThese 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.ExploitationBecause 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. ConclusionsTo 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. Wyświetl pełny artykuł Cytuj Link do komentarza Udostępnij na innych stronach More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.