ROP ROP #7

Before you proceed any further, make sure you have all the requirements fulfilled.

  • ASM knowledge
  • Debugger familiarity
  • GDB
  • Basic ROP knowledge
  • Brain

Setup

In this post, we will try to learn ROP (Return Oriented Programming) by using the last ropemporium pivot 32bit binary. Lets setup our machine for debugging by installing PEDA and downloading the target binary.

We have downloaded the binary and extracted it, time to start gdb.

Crash

We have found the offset at 44 which means that the EIP will hold the next 4bytes.

Control

The issue here is the very little space available on stack, we have only 13bytes allocated on stack after our return pointer. This means we have to find a way to more space somewhere. We know that due to ASLR we cant just use stack addresses to do that without any memory leaks. Also we can see that our payload overwrites the EBP and the binary gives out some address value. First lets find out where our all ‘AAAA’s went

Great, we can do some calculations to get the addresses we need to make our payload. We will proceed according to the following plan

  • Set 41 to 44 bytes in the 2nd input as the address provided by the binary (to reach the start of our first payload), this will be stored in EBP.
  • Memory address to instruction leave; ret to point our ESP to EBP+4 (read more about leave instruction if confused) in order to have more space available on stack.
  • Set the 4bytes of our first input as address to foothold_function in libpivot library.
  • Set the next 4bytes of our first input as address to ret2win in libpivot library.

This sounds great, lets move on to get our flag.

Flag

We will use all the above information to craft our exploit and it will look something like below

Start our binary as server and test our exploit.

Shell

We have executed a system command via the string available in the binary, now we will try to get a shell via the user supplied input. We will try to pass a pointer to system() for our user supplied input from mapped memory region due to malloc, I’ve modified the exploit a bit and it is advised that the reader should identify the changes and try to find out why I did that. Enough blabbering, on to our exploit now

As some of you might’ve already guessed by now, there is a problem with the above approach. The problem here is the different OS versions due to which there can be change in offsets and our calculations will not work. We can however try to identify the host OS with nmap scans etc but there is a better way to do this which isn’t dependent of different OS’s.

The Correct Method

As discussed above, we will now use another method to leak the resolved address of foothold_function from GOT table and use that do our offset calculations. This is a bit different from the first one where we overwrote the return pointer with the second input, however here we are sending only first input. If you’re confused you should try to find out the reason yourself. Please check the comments in the code to have a better understanding of what’s going to happen

To get the shell, we need to modify our second payload

——END——

Published by

Leave a Reply

Your email address will not be published. Required fields are marked *