Simplified Buffer Overflow Exploit Development (Part 1)

Introduction

This is an oversimplified write up on writing buffer overflow exploits. I kept it really simple as it is meant for my own reference. If you want more content, there are tons of material online. A buffer overflow attack is a means of overflowing an allocated buffer in memory with malicious shellcode/opcode to overwrite the EIP to execute arbitrary code. The analogy is similar to filling a bucket of water until it overflows, just that a computer buffer is filled from the top to the bottom.

Diagram illustrates a simple diagram of a computer buffer

The stack starts from the top and end at the bottom. This is a simplified version of a stack, take note on the 3 registers because you will be working with it in the debugger.

EIP = Instruction Pointer
EBP = Bottom Stack Pointer
ESP = Top Stack Pointer

Another analogy is dumping garbage into a bucket until it overflows, when it does, we know exactly how much to overflow it. The right amount of 'garbage' is then replaced with the right amount of malicious code such as a reverse shell with /bin/bash or cmd.exe for code execution.

Take note of the following:

PUSH = adds something to the top of the stack
POP = pushes 4byte down the stack
MOV
RET

Mem address starts from 0x00000000 and ends at 0xFFFFFFFF. The goal here is to overwrite EIP with the mem address of the shellcode. This is usually at the start of the stack(ESP), however, the stack is a dynamic and keeps growing so we will use a 'jmp esp' register in the application's dll to hunt for the shellcode, since we won't know where exactly the shellcode resides, we pad the shellcode with NOP sleds. Below illustrates the stack being populated:


AAAAAAAAA      0x1a00bb44  9090909090    0x01020300    evil code..
Random Pattern      EIP                NOP Slide      JMP ESP         Shellcode
------------------------------------------------------>>>>>>>>>>>>>

Fuzzing

Firstly, to overflow the stack you need to gauge how much 'garbage' to stuff into it. This is where fuzzing comes into play. Fuzzing is just throwing random pattern into the stack to find the right measurement for overflow. This is commonly referred to as an 'offset'. To do this, we use combination of msfpayload and simple python script.

Exploit Development

Much of the exploit development is done inside a debugger, for Windows, you can either use OllyDebugger or Immunity. For Linux, there are dozens of GUIs for gdb(command line). For this tutorial, we'll be using Immunity since we are focusing on Windows Exploit Development. By attaching the the vulnerable program to Immunity, we'll be able to step into the memory allocated for the program and examine its behaviour as we fuzz it. This means you will have to understand the basics of maneuvering around Immunity, such as setting break points, stepping into memory registers and searching for 'jmp esp'. Reading Hex values is also an important skill to have but that is easily referenced in a Hex table.

Shellcoding

Once the offset is found, we can replace the pattern with shellcode. The shellcode is also known as opcodes, is a small assembly code to direct code execution on the victim machine when the EIP is overwritten. For this, we can use msfvenom, though, such shellcode are easily detected by commercial AV products, so if you are serious about AV evasion, you will have to write your own shellcode. Here are some universal bad chars to avoid in shellcode:

• 00 for NULL
• 0A for Line Feed \n
• 0D for Carriage Return \r
• FF for Form Feed \f

Exploitation

Once we have assembled the exploit, just send it off to the vulnerable program's socket (if remote), or load it via an argument (if local) and see magic happen. Usually, the vulnerable program will cease to function or exit with an exception, however, there are techniques in the shellcode to avoid this from happening. Some Windows services also respawn when terminated which helps too. In this tutorial, we did not take into account Windows Stack Protection such as DEP and ASLR for Linux. That in my opinion, are advanced Exploitation techniques which I have yet to full comprehend.

In the next part, I will walkthru a working example of building an exploit using an outdated program that is vulnerable to a remote buffer overflow. Stay tuned...