Weaponizing ROP with PwNtools

By Andrei Grigoras

Content• Who am I ?

• Buffer Overflows

– What are they

– How to detect

– How to exploit

• Defensive Mechanisms

– ASLR

– NX

– Canaries

• ROP technique

– 32 bits

– 64 bits

• Weaponization with pwntools

– Classical approach

– Automation process

echo $(whoami)

• 3rd year student at The Faculty of Automatic Control and Computer Science - UPB

• SOC Analyst since June – SecureWorks

• eJPT certified

• CTF player, HackTheBox member, Security addict

• Passionate driver, table tenis player, fan of biking, Tech lover

Buffer Overflows (aka BOF)

According to cve.mitre.org:

There are 10222 CVE entries that match your search.(buffer overflows)

From which 356 from 2019

a. What are theyA BOF occurs when you are writing more data than the

program was expecting. This way, you overwrite data that is outside the allocated buffer which cause the program to crash or behave different.

There are a number of different buffer overflow attacks which employ different strategies and target different pieces of code such as:

Stack overflow attack - the ones we will be convering in this presentation

Heap overflow attack

Integer overflow attackUnicode overflow

b. How to detect

Look for signatures such as:

int x[20]; int y[20][5]; int x[20][5][3];

printf() ,fprintf(), sprintf(), snprintf(). %x, %s, %n, %d, %u, %c, %f

strcpy (), strcat (), sprintf (), vsprintf (), gets()

malloc(), calloc(), realloc() - rarely

The pattern is to look for places where you might be able write more data than the program would expect (thus exceeding expected boundaries).

GOLDEN RULE :

IF IT IS A C/C++ PROGRAM THEN IT’S MOST LIKELY VULNERABLE TO BUFFER OVERFLOW

The percentage of memory safety issues has been hovering at 70 percent for the past 12 years.

c. How to exploit

A piece of cake: just craft you own input

Therefore, we need to override the buffer so that we have control of the return address. This way, we can jump to the malicious code we place on the stack

pad = "\x41" * 76EIP = 0xbffff780shellcode = “\x31\x32\x33“NOP = "\x90" * 100 Payload = pad + EIP + NOP + shellcode

Defense Mechanisms

a. Program Level - Canaries(SSP stack guard)

Their goal is to protect the stack frame from being overwritten by the attacker.

The compiler adds a canary value between the local variable and the saved EBP. At the end of the function the canary value is checked to see if it’s the same.

The recommended method is to let the compiler add the code for extra precautiong++/gcc flag is -fstack-protector

To bypass, you would have to bruteforce canary value and place the correct one during the overflow. However, in practice could be really hard(null-terminator, randomness, 64 bits)

BUT NOT IMPOSSIBLE(SEH)

b. OS Level – DEP/NX

• Non-executable memory• Method not effective when exploitation is based on jumping to already existing

code.• Usually used in addition to ASLR + Canaries• However, sometimes, a simple “system()” is not enough and therefore we need to

execute our own crafter shellcode

BUT… You can use the Return Oriented programming technique to call functions such as VirtualProtect or mprotect as they always resides inside the code

c. Address Space Layer Randomization(aka ASLR)

• Any exploitation, so far, inquires knowing specific code/function addresses

• This method was designed to stop ANY buffer overflow by having random addresses each time a program is run(components are moved to different address in virtual memory)

• In 32bits this can be easily bruteforced as the entropy is not large enough

• However, there is a workaround for this “invincible” defense:

– Find vulnerable code

– Exploit in order to leak a function address(randomized)

– Get the base address of the function from libc and calculate the offset

– Jump back to the beginning of code and exploit normally by calculating

each function address with the formula

func_address = libc_func_address + offset

But, this can be really hard to achieve depending on the other factors(NX, canaries, limited number of rop gadgets)

Return Oriented Programming(aka R.O.P)

• Exploit technique that can help exploiting BOF in the presence of defense mechanisms

• Leverage pieces of code that are already residing inside the executable. These are called gadgets.

• The technique implies chaining multiple gadgets in order to accomplish complex tasks.

• However, the limitations are directly proportional to the number and types of gadgests available

• For x64, there is a nice paperwork called “Return to CSU” that explain how to get full exploit capabilities by only using the gadgests from “__libc_csu_init”.

a.x32 bits• In 32 bits, the key point is to take control of the EIP(instruction pointer) as you can jump

to any function from there. The easy part is that, the fuction arguments are placed on the stack.

• A classical payload would have to overwrite with junk data until reaching the EIP and then, perform any action you want by modifying its address and, optionally, add parameters.

•

system = \x32\x64\x23\x21 # system addressreturn= \x32\x62\x22\x22 # exit bin_sh= \x33\x63\x23\x23 #string /bin/bashbuffer = "A" * 52 + system + return + bin_sh

b. x64 bits• Mostly similar to x32 with one tiny little difference: the function parameters, according

to x64 conventions, are placed inside registers.

• This means that, in order to run system command, we need to have control of RDI.

• Therefore, this method is more gadget dependent.

• For example, to do a simple read function on a buffer overflow attack we would have to do the followings

Function definition: ssize_t read(int fd, void *buf, size_t count);

buf += p64(0x40159b) # pop rdi; ret;

buf += p64(0) # unsigned int fd

buf += p64(0x432f29) # pop rdx;pop rsi; ret;

buf += p64(30) # size_t count

buf += p64(0x6b6000) # char *buf

buf += p64(0x43168d) # pop rax; ret;

buf += p64(0) # sys_read

buf += p64(0x4546b5) # syscall; ret;

Weaponizing via pwntools• In this section we will focus on a basic C written vulnerable code with NX,

RELRO and ASLR enabled.

• We will see 2 approaches on this issue based on the same exploitation steps. The second one is the actual “flavor” that is more focused on programming efficiency, portability and coding style.

• Will have a bonus part where we will discuss how this can be prevented, but not completely. There are methods mostly only hardens attacker job.

a. Classical approach

• Step I: determine buffer offset which will trigger the overflow and let us have control of RBP. So offset is not seen as only the buffer length but also the extra padding added until overriding the RBP register.

I would recommend using GEF extension of gdb which comes with a lot of built-in feature including offset finding.

There is also the alternative of PEDA extension which has equivalent tools for this issue: pattern_create and patter_offset

What should be noticed is that, the RBP offset is 128, but in order to reach RSP we need 8 more bytes and therefore, the actual offset is 136.

• Step II: Leak puts offset located in Global Offset Table(GOT) and go back in to

– We want to have the program print the offset of puts in order for us to calculate functions offsets from LIBC

– Considering that stdio.h is statically linked, functions loaded into Procedure Linkage Table(PLT) and are not affected by ASLR randomization

– Therefore, if we know the puts address from plt(running an objdump) we can call the function: puts(puts_got_offset).

– Here, as this is x64 architecutre, in order to pass an argument to a function we also need a gadget. We can use any gadget extractor tool and look for “pop rdi”.

– So far the payload would look something like this:• junk = “A” * offset + gadget_address + puts_got_address + puts_plt_address

– The last step would be to go back at the beginning at the program so we can take advantage of the ASLR offset calculated by the following formula

• aslr_offset = puts_leaked – puts_libc_address

– So, we do another objdump and look for main address which will be placed as a return address after out payload ends(add address at end)

Stage I of exploit

• Step III: Control the program FLOW with the found offset

– We already have the ALSR offset that the LIBC functions were randomized with(simple difference).

– In most cases, we want to achieve a system(“/bin/sh”) (CTFs, pentest) but we could also execute shellcode by making parts of the memory executable(as NX is enabled)

– Similar to stage II, we have to grab system base address from LIBC and puts address too so we can have the offset calculated(using readelf)

– We can use the previous gadget to load “/bin/sh” into rdi then execute system

Final exploit

a. Automation• All the steps from the previous approach can be automated by pwntools

framework as all the search for addresses in LIBC and in the binary could be achieved if we define these as objects and then iterate through its fields.

• In order for this, we will define two ELF object, one being the binary itself and the other is the location of the LIBC used by the program

• We would also want to automate the search for the gadget. Fortunately, pwntools is able to do that by define a ROP object on the binary. Each address found will be appended to this object and when it is time to interact with the program we can just dump it’s content.

• Now, we will take each step from the exploitation and replace with specific functions relative to the objects we have created.

– To search for a string we would do libc.search(string) which returns an iterator for each virtual addresses that matches

– To find a address in a ELF object we can call object.symbols[function]

– The actual interesting part is interacting with a ROP object. For example if we wanted to automate the following:

• Payload = pop_rdi + string_address + puts_address

We can simply call, rop.puts(string_address)

Final Exploit

How do we defend ?• Compile binary fie fPIE (Position Independent Executable). This is similar

to ALSR but it randomizes the code addresses. In our example, we would not be able to predict main address as it would be different each time the program is run.• However, this could be bypassed if we had another vulnerable function that

could leak addresses.(like a format string exploit)

• Protect software against calls which can alter memory attributes (therefore, NX can not be bypassed)

• Remove ROP gadgets that could be turned against you

– There is a nice tool on github(one_gadget) that inspects all rop gadgets from a binary and chain them to achieve command execution

• Other measurements can be implemented at the level code to detect exploitation attempts.

Short recap before end

Refferences

https://ctf101.org/binary-exploitation/stack-canaries/http://hmarco.org/renewssp/data/Preventing_brute_force_attacks_against_stack_canary_protection_on_networking_servers-Paper.pdfhttps://blog.techorganic.com/2015/10/09/a-rop-primer-solution-64-bit-style/https://www.google.com/https://i.blackhat.com/briefings/asia/2018/asia-18-Marco-return-to-csu-a-new-method-to-bypass-the-64-bit-Linux-ASLR-wp.pdfhttps://www.apriorit.com/dev-blog/434-rop-exploit-protectionhttps://github.com/david942j/one_gadgethttps://cybersecurity.upv.es/attacks/offset2lib/offset2lib.htmlhttps://morph3sec.com/2019/06/24/64-Bit-Binary-ROP-Exploitation/http://docs.pwntools.com/en/stable/index.html