eliza#

Remote: eliza.challs.cyberchallenge.it,9131

Download binary: eliza

Solution#

First we check the security settings of the binary with checksec from pwntools:

The executable is position dependent (No PIE), so if we can manage to overwrite the return address in the stack, we can execute any function we want of the program. So now we just need to see if the process has any buffer overflow we can exploit and it’s done! right? Well, no. The executable has a canary which impedes us to use any buffer overflow to overwrite the return address without overwriting it as well, triggering the security mechanism that will stop the execution if the canary has been modified.

Now let’s start to actually reverse the code, so let’s fire up ghidra and check if we find any functions we would like. The challenge gently gives us a function called “sp4wn_4_sh311” that precisely spawns a bash process for us, how convenient.

Investigating the main we can immediately notice the eliza function, which contains the logic of the program. We jump to it and this is what we see:

In the disassembly code we can immediately notice a variable being allocated fist, that ,in our case, ghidra calls “local_10”.

This is the canary. Let’s rename it as such, and let’s understand what the function does. The code keeps asking us for input, reading 256 bytes and saving them into a variable only 72 byte-long. We have our buffer overflow. The code then checks if the string it read is longer than 16 chars, and if it is, it will print us the whole string (so until the ‘\0’ byte). This is a way we can leak the canary. In linux the canary ends with a \x00 to prevent any printf to leak it [1], so we need to overwrite 73 bytes, the 72 of the char array, and the last byte of the canary. In this way, the printf function will print every byte until the first \x00 it will encounter (probably belonging to the return address), including the canary.

Once read the canary, we would just need to repeat the process thanks to the while(true) loop, overwrite the return address with the one of the sp4wn_4_sh311 (which is fixed, 0x00400897), and finally, to break out of the loop, send a newline. To understand the padding between the canary and the return address we use the De Bruijn pattern. Finally we are connected to the bash shell of the remove, and with a simple ls we see the readable flag.txt file.

Exploit