Old skool stack smashing

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 vulnerability 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[
<img src="Stack.png" width="100%" />
]
---
template: inverse
# How does this work?
---
.left-column[
## How does this work?
]
.right-column[
## Start with some code:

``` C
#include <string.h>

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[
<img src="Stack_Overflow_2.png" width="70%" />

.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)]
]
---

.left-column[
## How does this work?
]
.right-column.center.middle[
<img src="Stack_Overflow_3.png" width="70%" />

.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)]
]
---

.left-column[
## How does this work?
]
.right-column.center.middle[
<img src="Stack_Overflow_4.png" width="85%" />

.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 (37 bytes) [2]:
```
\x6a\x17\x58\x31\xdb\xcd\x80\x6a\x2e\x58\x53\xcd\x80\x31\xd2
\x6a\x0b\x58\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89
\xe3\x52\x53\x89\xe1\xcd\x80
```

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-251.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
# Exploitation workflow
---
.left-column[
## Exploitation workflow
]
.right-column[
- Find input to overflow
- Figure out exact needed length for overflow to overwrite return address
- Place shellcode in memory, ideally with a NOP-sled in front
- Figure out shellcode location
- Use overflow to point the return address at shellcode/NOP-sled
  - Do take endianness into account
]
---
template: inverse
# Demo
---
.left-column[
## Demo
]
.right-column[
This is the code for the binary:

``` C
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

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
# Protections
---
.left-column[
## Protections
]
.right-column[
- Stack canaries 
 Place a value before the return address and check if it's been changed before returning from a function.
- Nonexecutable stack 
 W^X (write or execute) won't execute code on the stack (but will still follow return addresses).
- Randomization 
 Change function and stack addresses around so whenever a program is executed the locations are different.

All these can be worked around given the right conditions. They just make things annoying, euh, harder.
]
---
template: inverse
# DIY
---
.left-column[
## DIY
]
.right-column[
Now it's your turn.

Log into the provided VM. 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 <stdio.h>
#include <strings.h>

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 **HINT**) 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 <program>` start radare2 in debugger mode and analyse program
- `afl` list functions
- `pdf@<function>` disassemble function (e.g. `pdf@main`)
- `pxw @<location>` print memory (e.g. `pxw @ebp`)
- `db <address>` 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`)
]
---
template: inverse
# Quick GDB reference
---
.left-column[
## Quick GDB reference
]
.right-column[
- `gdb --args <program> <arguments>` start gdb with a program with arguments
- `disas <function>` disassemble a function
- `b *<address>` set a breakpoint on an address
- `x/200x $esp` show the memory contents for 200 bytes starting at the address $esp points to
- `x/200c <addr>` show the memory contents for 200 characters starting at the address
- `r` run
- `r < foo.txt` run with stdin filled from a file
- `c` continue
- `s` step into
- `info functions` list all functions
- `p (char*)getenv("PATH")` find the memory location of an environment variable for the running program (use a breakpoint!)

Many improvements exist to make gdb nicer for reverse engineering, such as:
- https://github.com/pwndbg/pwndbg
- https://github.com/hugsy/gef
- https://github.com/longld/peda
]