This is the third and final pwn of VolgaCTF. ASLR is now activated, which would
not have changed the outcome of the two previous challenges, therefore there
must be something else…
Basic information
From the organizers:
The binary has the same attributes as the previous one.
Operation
The operation has changed and the fragment of new code that was seen in the
previous binary is now used:
Now we have to solve a real challenge before being able to reach the rest of the program:
Solving the SHA1 challenge
I went for a bruteforce over the five bytes using the permutations function
of the library itertools:
Usually the bruteforce should not take more than 10 seconds, when it did, I
just killed it and relaunched it to get a new challenge.
Rest of the program
When the SHA1 challenge is succeeded, we have access to the rest of the program
which seems to be a papers manager:
The first and main menu is handled by that function:
At 0x00401810 the choice is read through the gets function. At 0x0040183b
and 0x00401843 the choice used to select a function in a table array located
at 0x401e40:
Vulnerabilities
String format
The parts that we were exploiting in the two previous challenges have been
replaced with that SHA1 challenge that doesn’t seem to be vulnerable.
Vulnerabilities must now be found in the papers menus. As in the previous ones,
canaries are enabled, therefore we should find a way to leak one. If we want to
reuse the previous ROP chain, we’ll also need a pointer to the libc. Let’s hunt
for a string format in each of the seven following attributes of a paper:
Once done, the option number 9 Quit must be chosen and then on the main menu, the option number 4 View paper info:
The fields abstract, tags and URL are vulnerable to string format. Only one of
them is needed. Let’s inject some more %ps into the abstract field:
We have all what we need:
libc pointer: 0x7f3d1c0df9e0 is the 2nd leaked value
canary: 0x9d8b247c324e4400 is the 19th leaked value
These are values stored in the stack frame of the function handling the main
menu, therefore an overflow should be found on the menu.
Let’s find the base address of the libc during that run:
The offset of the leaked libc pointer is:
Stack buffer overflow
The main menu is vulnerable to buffer overflow. It is possible to insert
arbitrary values in the choice selection to write passed the buffer. Let’s
break right before the call to gets:
Saved rip is located at 0x7fffeb9b79d8, the canary at 0x7fffeb9b79c8 and
the start of our buffer at 0x7fffeb9b79a0. This gives us the following
payload:
40 bytes of padding, zeros are good candidates
canary
8 bytes of padding
ROP chain (the same as the one used in the previous challenge)
When that payload is passed as a choice to the main menu, the program will
reprint the menu and ask again for a choice. At that moment the option 5 Exit
is chosen to exit the function and return on the ROP chain. As shown in the
jumping table show above, here is the instrcution that are executed when the
Exit option is chosen:
We see the check of the canary and then the return.
Creation of the overall payload
To recap what we have to do:
resolve the SHA1 challenge
create a paper with just an abstract containing string formats