148 lines
4.4 KiB
Markdown
148 lines
4.4 KiB
Markdown
# Exploits
|
||
|
||
- The easiest way of getting access to a machine is having the user install something for you
|
||
- A software or hardware bug that allows an attacker to circumvent an OS’ security perimeter
|
||
|
||
#### Memory Management
|
||
|
||
- In C and C++, the programmer performs memory management
|
||
- Flexible, powerful, fast but dangerous
|
||
- Buffer Overruns
|
||
- Stack Overruns
|
||
- Heap Overruns
|
||
- Memory-managed languages avoid this, but of course may have their own vulnerabilities
|
||
|
||
### Buffer Overflows
|
||
|
||
- When a program is executed, contiguous blocks of memory can be allocated to store arrays (buffers)
|
||
- If data is written into a buffer that exceeds its size, an overflow occurs
|
||
- The data will overwrite the memory beyond the buffer
|
||
|
||
#### Program Memory
|
||
|
||
- Memory is stored in virtual address space from `0x0000...` to `0xFFFF...`
|
||
- Parts of the program are held in different regions by convention
|
||
- Different restrictions are placed on these regions
|
||
|
||
|
||
|
||
##### The Stack
|
||
|
||
The stack holds information on local variables and function calls (stack frames)
|
||
|
||
1. A function call will push a new frame onto the stack
|
||
2. A return will pop it off, and go to `ret`
|
||
|
||
```c
|
||
void function(int a, int b, int c)
|
||
{
|
||
char buffer1[5];
|
||
char buffer2[10];
|
||
}
|
||
|
||
void main()
|
||
{
|
||
function(1,2,3);
|
||
}
|
||
```
|
||
|
||
|
||
|
||
###### Stack Smashing
|
||
|
||
- In C and C++, low level functions like `strcpy` perform no bounds checking at all
|
||
- This is partly due to the fact strings are null terminated, if we provide no null character `strcpy` will continue to run
|
||
- If `str` is long, we can write into other memory
|
||
|
||
```c
|
||
void function(char *str)
|
||
{
|
||
// allocate local buffer
|
||
char buffer[128];
|
||
// Copy str into local buffer
|
||
strcpy(buffer, str);
|
||
}
|
||
```
|
||
|
||
|
||
|
||
###### Stack Canaries
|
||
|
||
- Stack canaries modify the prologue and epilogue of all functions to check a value in front of the return address is unchanged
|
||
|
||
|
||
|
||
- If you can work out the canary value, there is no issue
|
||
|
||
###### Data Execution Prevention (NX)
|
||
|
||
- Modern operating systems will mark the stack as non-executable
|
||
- `NX` on AMD, `XD` on Intel and `XN` on ARM
|
||
- An `NX` stack means that adding in our exploit code won’t work
|
||
- We can circumvent this using a `return-to-libc` attack
|
||
|
||
###### Further Protection
|
||
|
||
- To defeat `ret2lib2` various `0x0` null bytes are inserted into standard library addresses
|
||
- Developers also restrict access to obvious system calls
|
||
- Address Space Layout Randomisation (`ASLR`) moves the addresses of libraries and programs around
|
||
- They don’t have to move too much before your hand-crafted `ret` addresses will break
|
||
|
||
###### Return-Oriented Programming
|
||
|
||
- Let’s forget about injecting code, how about just using existing code in the actual exploitable program
|
||
- No individual section of this program will do what we want
|
||
- Find short sections, *gadgets* and link them together
|
||
|
||
|
||
|
||
##### Race Conditions
|
||
|
||
- With concurrent threads or processes, timing can lead to security vulnerabilities
|
||
|
||
|
||
|
||
- Here the victim unknowingly modifies the wrong file
|
||
- This can happen because the CPU context switches and can execute these two processes simultaneously
|
||
- Running this continuously for about 10 minutes, this will work once
|
||
|
||
##### Heartbleed
|
||
|
||
- Heartbleed is a bug in `OpenSSL`
|
||
- Open source `SSL` library
|
||
- Started in `OpenBSD`
|
||
- Used almost *everywhere*
|
||
- Specifically targeted the heartbeat extension
|
||
- Extension to regular `SSL` and used for keep-alive purposes, to stop quiet connections being closed
|
||
- Client sends a message to the server to say it’s alive
|
||
- Server responds (also alive)
|
||
|
||
|
||
|
||
**The Bug**
|
||
|
||
```c
|
||
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
|
||
bp = buffer;
|
||
|
||
/* Enter response type, length and copy payload */
|
||
*bp++ = TLS1_HB_RESPONSE;
|
||
s2n(payload, bp);
|
||
memcpy(bp, p1, payload); //BAD
|
||
bp += payload;
|
||
|
||
/* Random padding */
|
||
RAND_pseudo_bytes(bp, padding);
|
||
|
||
r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload +
|
||
padding);
|
||
if (r >= 0 && s->msg_callback)
|
||
s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,
|
||
buffer, 3 + payload + padding,
|
||
s, s->msg_callback_arg);
|
||
```
|
||
|
||
This bug would just memcpy a bunch of the server’s RAM and send it back to the client. This can expose RSA keys.
|
||
|
||
This is called a **buffer overread** attack.
|