name: inverse layout: true class: center, middle, inverse --- # Old skool stack smashing Ward Wouts
https://wizeazz.nl/smash/ --- # Agenda 1. Introduction 1. What is a stack? 1. How does this work? 1. Vulnerable fuctions 1. Now what can we do with this? 1. Shellcode? 1. Endianness? 1. Demo 1. DIY 1. Quick Radare2 reference --- # Introduction --- layout: false .left-column[ ## Introduction ] .right-column[ C is full of holes, let's get to know one. Old skool, so no OS or hardware protections. Which today is mostly relevant in IoT. (Remember, the `S` in `IoT` stands for Security.) Stack smashing is making use of a buffer overflow vulnerability in code using variables on the stack. This type of vulenrability has been known for a long time. This attack was first properly documented in Phrack #49. .footnote[Phrack #49(http://www.phrack.org/issues/49/14.html#article)] ] --- template: inverse # What is a stack? --- .left-column[ ## What is a stack? ] .right-column[ Stacks in computing architectures are regions of memory where data is added or removed in a last-in-first-out (LIFO) manner. The stack is used to pass arguments between functions, to allocate space for fixed variables, and to remember how to get back out of the current function. For x86 systems the stack grows from the largest memory address up. .footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack-based_memory_allocation)] ] --- .left-column[ ## Say wut? ] .right-column[ Whenever a function is called a frame is added to the stack. Whenever a function ends the frame is deleted. Such a frame consists of variables, a stored stack pointer and a return address. ] --- .left-column[ ## This is not helping you know... ] .right-column.center.middle[
] --- template: inverse # How does this work? --- .left-column[ ## How does this work? ] .right-column[ ## Start with some code: ``` C #include
void foo (char *bar) { char c[12]; strcpy(c, bar); // no bounds checking } int main (int argc, char **argv) { foo(argv[1]); return 0; } ``` .footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)] ] --- .left-column[ ## How does this work? ] .right-column.center.middle[
.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)] ] --- .left-column[ ## How does this work? ] .right-column.center.middle[
.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)] ] --- .left-column[ ## How does this work? ] .right-column.center.middle[
.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)] ] --- template: inverse # Vulnerable functions --- .left-column[ ## Vulnerable functions ] .right-column[ Anything that doesn't take buffer sizes into account. The big ones being: - gets - strcpy - sprintf ] --- template: inverse # Now what can we do with this? --- .left-column[ ## Now what can we do with this? ] .right-column[ We can change the flow through the program: - Jump to a different function in a known spot in memory - Jump to our own shellcode somewhere in the buffer (can also write past the return address) - Jump to our own shellcode in the environment *Full nerd: By overwriting the return address we can change to which instructions the Instruction Pointer (`EIP` in 32-bit x86, `RIP` in 64-bit x86) points. `EIP` and `RIP` are so called registers. There are more, like `EBP`/`RBP` which is used for pointing at the stack frame pointer. The other registers are used like variables.* .footnote[Lots of shellcode [here](http://shell-storm.org/shellcode/)] ] --- template: inverse # Shellcode? --- .left-column[ ## Shellcode? ] .right-column[ In hacking, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode. [1] Here's a bit of shellcode to open `/bin/sh` on 32-bit x86 (48 bytes) [2]: ``` \xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01 \x75\xf6\xeb\x05\xe8\xea\xff\xff\xff\x32\xc1\x51\x69\x30\x30 \x74\x69\x69\x30\x63\x6a\x6f\x8a\xe4\x51\x54\x8a\xe2\x9a\xb1 \x0c\xce\x81 ``` As strings in C are NULL terminated, shellcode should not have `\x00` in it. `\x90` is a NOP (No Operand) in x86. You can use a bunch of those in front of shellcode to increase the chances of ending up in your shellcode. This is called a NOP-sled. Sometimes swapping out some shellcode for some other shellcode is the trick. .footnote[[1] Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Shellcode)
[2] Shellcode from [shell-storm](http://shell-storm.org/shellcode/files/shellcode-491.php)] ] --- template: inverse # Endianness? --- .left-column[ ## Endianness? ] .right-column[ In computing, endianness refers to the order of bytes (or sometimes bits) within a binary representation of a number. It can also be used more generally to refer to the internal ordering of any representation, such as the digits in a numeral system or the sections of a date. In its most common usage, endianness indicates the ordering of bytes within a multi-byte number. A **big-endian** ordering places the most significant byte first and the least significant byte last, while a **little-endian** ordering does the opposite. For example, consider the unsigned hexadecimal number 0x1234, which requires at least two bytes to represent. In a big-endian ordering they would be `[ 0x12, 0x34 ]`, while in a little-endian ordering, the bytes would be arranged `[ 0x34, 0x12 ]`. x86 is a **little-endian** architecture ] --- template: inverse # Demo --- .left-column[ ## Demo ] .right-column[ This is the code for the binary: ``` C #include
#include
#include
int main(int argc, char * argv[]){ char buf[128]; if(argc == 1){ printf("Usage: %s argument\n", argv[0]); exit(1); } strcpy(buf,argv[1]); printf("%s", buf); return 0; } ``` Binary here: https://wizeazz.nl/smash/code/demo .footnote[Borrowed from [Overthewire.org](https://overthewire.org/wargames/narnia/)] ] --- template: inverse # DIY --- .left-column[ ## DIY ] .right-column[ Now it's your turn. Use google cloudshell https://console.cloud.google.com/cloudshell/ to run ssh to log into `XX.XX.XX.XX` (not available now) with ssh using user `hulkX` password `smashX`. Binary and shellcode are in `/smash` **Alternative** If you want to use your own system, Do this as preparation: - Install radare2: `$ sudo apt-get install -y radare2`
**OR**
`$ git clone https://github.com/radareorg/radare2.git && cd radare2 && sys/user.sh`
for a persistent installation. - Turn off ASLR: `$ sudo sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"` - Check: `$ sysctl -a --pattern randomize` - Enable debugging: `sudo sh -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"` - Download binary:
`$ curl -O https://wizeazz.nl/smash/code/diy` - Make executable: `$ chmod a+x diy` .footnote[Linux and ASLR settings [here](https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/)] ] --- .left-column[ ## DIY ] .right-column[ Assignment: - Make the binary print `You win`. This is the code for the binary: ``` C #include
#include
void winner() { printf("You win\n"); } void whoareyou() { char name[250]; printf("What's your name? "); gets(name); printf("\nHello, %s\n", name); } int main() { whoareyou(); printf("You lose\n"); } ``` ] --- .left-column[ ## DIY ] .right-column[ Now, if you managed that: - Try to make it open a shell via shellcode. Especially fun if you make the binary SUID root:
`$ sudo chown root.root diy && sudo chmod u+s diy` - Can be done both via shellcode in an environment variable (usually more reliable) and via shellcode in the buffer Tip: `gets()` behaves weirdly and will close your shell immediately. The trick is to do something like:
`$ (echo -e MYINPUT; cat)|./diy`
This won't give you a prompt! ] --- template: inverse # Quick Radare2 reference --- .left-column[ ## Quick Radare2 reference ] .right-column[ - `r2 -Ad
` start radare2 in debugger mode and analyse program - `afl` list functions - `pdf@
` disassemble function (e.g. `pdf@main`) - `pxw @
` print memory (e.g. `pxw @ebp`) - `db
` Set breakpoint - `dc` continue to breakpoint - `ds` step into - `V` go to visual mode - `q` leave visual mode - `p` next view (2x for debugger view) - `s` step into - `S` step over - `?v HEX` build in calculator (e.g. `?v 0xdead0000+0xbeef`) - `?vi HEX` hex to integer (e.g. `?vi 0x400`) ]