Hack Like a Pro: How to Build Your Own Exploits, Part 1 (Introduction to Buffer Overflows)

Welcome back, my fledgling hackers!

With this first article, I am initiating a new series intended to convey to my readers the skills necessary to develop your own exploits.

As many of you know, soon after an exploit is found in the wild, software developers begin to work on patches to close the hole or vulnerability that was exposed. Soon, that exploit will no longer work, except on unpatched systems. (Despite this, don't underestimate the number of unpatched systems. Many firms don't patch out of neglect or fear that a patch will break a working production system. There are millions of unpatched systems!)

Furthermore, soon after an exploit is developed, AV software developers create a signature for the exploit, and the ability to send or install the software on the target system becomes problematic (not impossible, but problematic).

The key to overcoming these issues is to develop your own exploits. If you can develop your exploits, there will be no patch and the AV software won't detect it. In essence, you will have developed the hacker's holy grail—a zero-day exploit!

This series is designed to provide you the background and skills to develop your own zero-day exploits. It's not for the beginner or those without a good IT background, but we will start slowly and go step by step through the process, giving you time to build the skills you need.

Expect this series to have numerous tutorials (from 10 to 15) on the anatomy of buffer overflows and the knowledge and skills you need to find and exploit them along the path to building our own zero-day exploits. We will eventually develop our own stack-based buffer overflow, which involves overfilling a variable on the program's memory stack and overwriting adjacent memory areas.

Let's begin with some basic concepts and terminology.

Buffer Overflows

In many of my numerous hacks here on Null Byte, we have been able to get a command shell or meterpreter on a remote computer. In the jargon of the industry, this is referred to as "remote arbitrary code execution." What is taking place in all of these cases is better known as a "buffer overflow."

A buffer overflow is a condition where a variable is overstuffed with data and "arbitrary" (i.e., the hacker's) code is executed. This code can be anything, but ideally, it a command shell or terminal to give hacker control of the victim system.

Buffer overflows are far and away the most dangerous and destructive vulnerabilities within any application or operating system. In its simplest form, a buffer overflow is simply a variable that does not check to make sure that too much data is sent to it (bounds checking) and when too much data is sent, the attacker can send and execute whatever malicious code they want in that address space.

Memory Basics

To understand buffer overflows and the terminology that the industry uses, you need to understand a bit about memory. Let's use a simple analogy.

Let's imagine that our memory is like a large three-ring binder. You know, the type we have carried to school or work. When a new program executes, it begins to fill up the pages in this three-ring binder with data (stack) it needs, filling it from the top towards the bottom. When the program begins it execution, it requires temporary data that it uses and discards quickly. It then fills the binder with this data from the bottom toward the top (heap).

The memory area directly after the program is called the "stack" and the memory area at the end of the memory area is called the "heap." If the book is large enough, then these two areas will never collide.

Stack vs. Heap Memory

Stack is short term memory, is fixed in size, and is used to store function arguments, local variables, etc.

Heap is long-term memory and holds dynamic memory.

General-Purpose Registers

On Intel-based CPUs (both Mac and Windows), there are several general-purpose registers that can be used to store data. In future tutorials, we will be learning how to manipulate and use these registers to create our zero-day exploit. These are:

• EIP - instruction pointer
• ESP - stack pointer
• EBP - base pointer
• ESI - source index
• EDI - destination index
• EAX - accumulator
• EBX - base
• ECX - counter
• EDX - data

NOP Sled

A NOP (no operation) is an instruction that tells the program to do nothing, and a NOP sled is a sequence of NOPs that are meant to slide the CPUs instruction flow to the desired location in memory registers. Many exploits use NOP sleds to direct the execution pointer to the malicious (hacker) code after pushing out the data from the stack or heap.

These are some of the basic concepts and terminology you will need before we can begin building our exploit, so make certain you understand these concepts and bookmark this page before we proceed in this exploit-building series. If you follow this series closely, by the end you will capable of developing your very own zero-day exploits.