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.
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)]
.footnote[Borrowed from [wikipedia](https://en.wikipedia.org/wiki/Stack_buffer_overflow)]
]
---
.left-column[
## How does this work?
]
.right-column.center.middle[
<imgsrc="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[
<imgsrc="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[
<imgsrc="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 (48 bytes) [2]:
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)<br>[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 <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
# 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:
