# 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

![1646677005.png](img/1646677005.png)

##### 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);
}
```

![1646677112.png](img/1646677112.png)

###### 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);
}
```

![1646677357.png](img/1646677357.png)

###### Stack Canaries

- Stack canaries modify the prologue and epilogue of all functions to check a value ion front of the return address is unchanged

![1646679244.png](img/1646679244.png)

- 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 address of library and programs around
  - They don’t have to move too much before your hand-crafted `ret` addresses will break

###### Return-Oriented Programming

- Lets 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

![1646679620.png](img/1646679620.png)

##### Race Conditions

- With concurrent threads or processes, timing can lead to security vulnerabilities

![1646679670.png](img/1646679670.png)

- 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)

![1646679952.png](img/1646679952.png)

**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.