How to ROP exploit?

In the last blog I attempted to hack a server (with permission, naturally) and discovered it had a debugger running that gave me a foothold. However I couldn’t get full control of the system without a skill upgrade in the realm of return-oriented programming (ROP) chaining. Fast forward to this week and I’ve upgraded the skills so let’s pick up where we left off.

In a typical buffer overflow attack the buffer includes the attacker’s shell code so when you overwrite the EIP (extended instruction pointer aka where the computer should go to execute the next command) with the start address of your shell code you basically control the system. Our test target has ASLR and NX/DE protections in place to prevent this attack from working so to proceed we need to bypass these protections

Here’s a very simple exploit example: we want to call a function discovered with a debugger/disassembler. The following picture shows the list of functions within the target application using Radare2 and lists the function’s address in green next to the function’s name in red.

2019-07-09 11_36_59-Kali Linux [Running] - Oracle VM VirtualBox.png

We will be targeting sym.ret2win as marked by the asterisk above. Before we can call it we need to know some specifics about the buffer itself. I run pattern_create to overflow the RSP register:

2019-07-09 11_38_57-Kali Linux [Running] - Oracle VM VirtualBox.png

From the “AA0AAFAAb” string we can determine the buffer is 40 characters long. Trust me on this one - the process is a bit long but if anyone is interested in how to determine the buffer length using this method drop us a line at security@largnet.ca.

When constructing exploit we know we need 40 characters of anything to fill the buffer and the address of 0x00400811 which we will convert to little endian 64bit to get "\x11\x08\x40\x00\x00\x00\x00\x00"

The exploit we created is:

python -c 'print ("\x90"*40 + "\x11\x08\x40\x00\x00\x00\x00\x00")' | ./ret2win

That’s all it takes to overflow the buffer for our example here. The test target from the previous blog is a bit more complicated than the example so eventhough we’ve learned a bit about ROP chaining we still need to learn a bit more to get full control of the system.