CTF Class 2018 By: Shawn Stone Pwn 2 CTF Class 2018 By: Shawn Stone

Overview Dealing with stripped binaries Buffer leaks Format Strings Leaks (canary, libc) GOT,PLT ROP

Dealing With Stripped Binaries Finding your buffer (ASLR Disabled) Same as before look for some form of input function set a breakpoint at the input function and get your buffer address from the arguments passed to the function Finding offset from buffer to return address on the stack Use cyclic patterns as before Find the buffer as described before then subtract it from the address of the return address most likely rbp+8 on a 64 bit system (check the function prologue to make sure this is the case). OR cheat and use pwndbg’s retaddr command

Dealing With Stripped Binaries Finding main Use gdb ‘info file’ command to get the entry point (or use readelf or whatever other method you prefer) Disassemble the entry point ‘x/30i <entry_point>’ Look for the first argument to __libc_start_main

Dealing With Stripped Binaries Top: not_stripped Bottom: stripped gcc -s Or strip -s *Note: radare will usually find main for you but sometimes it will not. Knowing how to do this will help you with other assembly languages as well.

Dealing With Stripped Binaries Example ARMv5: Main is at 0x000107b8

Dealing With Stripped Binaries For the most part radare and IDA will be your best option for doing your static analysis. You will want to know how that translates over to gdb. If you do have access to IDA it is useful to use pwndbg’s integration with IDA to use the IDA database to include comments, decompiled code, etc. in GDB from IDA. Use libc functions to help you determine what a particular function is doing. Use strings to get a better idea of what a function is doing. A menu is often times one of the greatest helps to figuring out what is going on in a binary.

ASLR (Review) ASLR - Address space layout randomization Randomizes certain parts of the binary What is not randomized when PIC is disabled?

ASLR (Review) How do we get around this? Leak Brute Force Special Conditions System already in GOT mmap or mprotect already in GOT more... Use the dynamic linker (How the ELF Ruined Christmas https://www.usenix.org/node/190923 )

StackGuard (Review) StackGuard - places a ‘canary’ or ‘cookie’ on the stack in some functions based on the compiler option specified. This canary is placed above the return address and stored ebp in the function prologue so that if a local buffer is overrun it will first overwrite the canary before the return address. The canary is then checked before a return call.

StackGuard (Review) How do we defeat this? Leak Data Based Exploits (overwrite function pointer on the stack, manipulate index value on the stack, etc.) Brute Force Canary Structured Exception Handling exploit (Windows) Some functions with small buffers are not protected Canary doesn’t change when you fork a process (maybe you find a leak in one process and exploit in another)

Leaking Data So, how do we leak data? There are many ways and depending on the vulnerabilities your method will change We will learn two types of leaks. What information you are able to leak depends on where your vulnerabilities are located. Buffer Overflow Leaks Format String Leaks

Buffer Overflow Leaks ROP Based Leaks - We will discuss these later today Buffer overflow leak before canaries ended with a null byte Buffer overflow in a loop (Small example below)

Buffer Overflow In A loop Notice the check happens after the loop ends What if we overflow up to the point just before the canary is stored on the stack and then print the canary?

Buffer Overflow in a Loop Before Overwrite: After overwrite: rbp-0x20 -> 0x7fffffffd460 0x400650 0x7fffffffd468 0x4004e0 0x7fffffffd470 0x7fffffffd560 Canary -> 0x7fffffffd478 0x6b5c162ef30f4e00 rbp - > 0x7fffffffd480 return address -> 0x7fffffffd488 0x7ffff7a2d830 rbp-0x20 -> 0x7fffffffd460 AAAAAAAA 0x7fffffffd468 0x7fffffffd470 Canary -> 0x7fffffffd478 0x6b5c162ef30f4e0a rbp - > 0x7fffffffd480 0x400650 return address -> 0x7fffffffd488 0x7ffff7a2d830

Buffer Overflow In A Loop Pwntools p.sendline(“A”*0x18) p.recvuntil(chr(0xa)) #or run p.recvline() canary = “\x00” + p.recv(7) #we prepend the null byte Issues Very circumstantial but comes out in CTF’s enough. Usually there is some menu function with a buffer overflow in a loop You have to have the right kind of buffer overflow. For example ‘gets’ will not work because it will automatically append a null character at the end of your buffer.

Format String Vulnerabilities User controlled format strings Many different format string controlled functions printf, sscanf, sprintf, fprintf, etc. Format %[parameter][flags][width][.precisio n][length]type

Format String Vulnerabilities Common Format Specifiers %s - expects a c-string argument %x - expects an unsigned int (print hex) %d - expects an int (prints decimal) Common width specifiers %lx - prints long in hex %llx - prints long long in hex

Format String Vulnerabilities Direct Parameter Access Example: %2$llx Print the second parameter on the stack expects a long long hex value This is mostly disabled when FORTIFY_SOURCE is enabled.

Format String Vuln: Leaking Data %s, %x, %d On a 64 bit system lets leak 10 long long values off of the stack we start the payload with 8 A’s so when we see 4141414141414141 appear on the stack we know how far away our buffer is. Then we can calculate how much further we need to go to leak the canary or we can use this information as part of a Format String Write or arbitrary leak AAAAAAAA.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx.%llx Result AAAAAAAA.0f7302.7fff80345.0.4141414141414141….

Format String Vuln: Leaking Data Arbitrary leak Once we know which parameter our format string is at. We can replace the 8 A’s with and arbitrary address. Say we want to leak the libc address from the GOT of __libc_start_main which is at 0x08403060 (32 bit binary) “\x60\x30\x40\x08%4$s” Treat 0x08403060 as a pointer to a c-string (assuming your format string is the 4th parameter) What is printed out will be the contents of 0x08403060, the libc address of __libc_start_main

Format String Vuln: Leaking Data Arbitrary leak There is a way to do this in a 64 bit binary but it is more difficult since we can’t have null bytes at the beginning of our format string. Don’t worry about arbitrary leaks or data writes in this class. Pwntools fmtstring Automated tools for format string exploits http://python3- pwntools.readthedocs.io/en/latest/fmtstr.html

What do we want to leak? Depends on the problem but maybe… Canary Buffer address A libc address Other sensitive information...

Leaking libc Where might we find libc addresses? GOT (usually at a predictable address) Stack (leak through buffer leak method or format string, and others...) Heap (leak through buffer leak method or format string, and others...)

Leaking libc Example Suppose we know the address of __libc_start_main+240 is on the stack (the return address of main) Using the techniques we discussed so far we determine the address of __libc_start_main+240 on the stack is the 110th parameter to a format string vulnerability on the stack. We can therefore leak the address in a 64 bit binary with the format string “%110$llx”. Usually we want to find the libc base address so that we can use it with pwntool or calculate the runtime addresses of function we want to call as part of our exploit. To calculate this...

Calculating libc base from leaked __libc_start_main+240 First figure out the offset in the proper libc for the address you leaked In pwntools you can use libc = ELF(‘./path/to/libc’) then off = libc.symbols[‘__libc_start_main’]+240 Now calculate the base address of libc libc_base = leaked_addr-off At this point we have calculated the base address we might then use this to figure out the runtime address of system. In pwntools you can use libc = ELF(‘./path/to/libc’) libc_sys = libc_base+libc.symbols[‘system’]

GOT and PLT How do we load shared libraries? Static libraries are copied into the executable but it would be bad if every process in your system kept it’s own copy of libc functions. Solution: Use redirection to lookup at runtime the address of functions that our needed I Highly Recommend Reading, attend Advanced PWN During Saturday Hacking if you want to learn more: https://cseweb.ucsd.edu/~gbournou/CSE131/the_inside_story_ on_shared_libraries_and_dynamic_loading.pdf https://systemoverlord.com/2017/03/19/got-and-plt-for- pwning.html

GOT and PLT Relocation Table A table of relocation structures Contains Symbols and their GOT entry location, and some other information

GOT and PLT Lazy Loading - The dynamic loader does not load any shared function addresses until they are called (Partial RELRO and no RELRO) Immediate Loading - The dynamic loader loads addresses of shared functions at program startup (FULL RELRO with then protect the GOT, PLT, etc. with read only protections)

GOT and PLT GOT - Global Offset Table A table that contains the address in memory of a libc function if it has been dynamically loaded if it has not it contains an address that jumps back into the PLT to call the dynamic loader. PLT - Procedure Linkage Table A table of stub functions, one for each dynamically loaded function, plus some extra stubs

Some Exploits ASLR… No Problem Overwrite an entry in the GOT with a pointer to code you control (NX Disabled) Leak libc address and then overwrite GOT entry with the address of ‘system’ Change structures the dynamic loader uses to load symbols (A little more advanced) https://www.usenix.org/node/190923

Some Protections RELRO Partial compiler command line: gcc -Wl,-z,relro some sections(.init_array .fini_array .jcr .dynamic .got) are marked as read-only after they have been initialized by the dynamic loader non-PLT GOT is read-only (.got) (most likely just the first two entries of .got are read only) GOT is still writeable (.got.plt)

Some Protections RELRO Full compiler command line: gcc -Wl,-z,relro,-z,now supports all the features of partial RELRO lazy resolution is disabled: all imported symbols are resolved at startup time. bonus: the entire GOT is also (re)mapped as read-only or the .got.plt section is completely initialized with the final addresses of the target functions (Merge .got and .got.plt to one section .got)

Return Oriented Programming A type of code reuse attack Code reuse attack - software exploits in which an attacker directs control flow through existing code with a malicious result. ROP Gadget - small instruction sequences ending with a “ret” instruction How do we find these gadgets? https://github.com/JonathanSalwan/ROPgadget Try multiple tools if you aren’t finding the gadgets you want ROP Chain - a sequence of gadgets Possible to defeat most mitigation techniques mentioned so far.

Return Oriented Programming Calling system(‘/bin/sh’) rbp-0x20 -> 0x7fffffffd460 AAAAAAAA 0x7fffffffd468 0x7fffffffd470 Canary -> 0x7fffffffd478 0x6b5c162ef30f4e00 rbp - > 0x7fffffffd480 0x400650 return address -> 0x7fffffffd488 Addr of pop rdi;ret; 0x7fffffffd490 Pointer to /bin/sh\x00 0x7fffffffd498 Addr of system

Return Oriented Programming Pwntools http://docs.pwntools.com/en/stable/rop/rop.html context.arch = ‘amd64’ b = ELF(‘./path/to/binary’) libc = ELF(‘./path/to/libc’) libc.address = 0x608000 #0x608000 is the libc base address that you calculated previously. rop = ROP(libc)

Return Oriented Programming Pwntools rop.system(next(libc.search('/bin/sh\x00'))) #Make sure you are using the correct libc! on the local system this can be found using the ldd command and remotely they will usually provide libc to you, if not there are ways for determining the version of libc being used rop.dump() #will print the rop chain for you str(rop) #will convert the rop chain by packing the data in the chain

Relevant Links How ELF binaries are run: https://lwn.net/Articles/631631/ GOT and PLT https://systemoverlord.com/2017/03/19/got-and-plt-for- pwning.html