Vicious exploitation. Searching for buffer overflow vulnerabilities with Angr

Unconstrained

Let’s write and build a test object: a small program a priori vulnerable to buffer overflow. Build flags ensure a static ImageBase and the absence of a stack canary, which makes hacker’s life much easier.

The code stores the input string in a local buffer. Your task is to overflow this buffer in a way that transfers the control flow to the win function.

Let’s find out the actual addresses using a debugger. At the entry point of the func() function, the return address is on top of the stack. The prologue saves the old EBP on the stack and then subtracts 0x24 from ESP, thus, creating a ‘pocket’ for local data on the stack.

The stack looks quite conventionally. Let’s try to override the return address.

The script searches for such input data that will transfer control to address 0x8049196. How does it work? You start the simulation and wait for the unconstrained box to be filled. It contains states with more than 256 possible destination addresses the control flow can be transferred to. In most cases, this means that the EIP register partially or completely depends on symbolic variables under your control. Just in case, you can check whether each bit of the EIP register is symbolic. Then you set a constraint: the register must be equal to a certain value. After that, you start concretization of solutions.

First of all, let’s check whether everything works properly. Pwntools can be used for this purpose:

Getting the much-anticipated result:

Writing VEX analyzer

Overflows frequently occur in functions like strcpy. If they are imported from external libraries, it’s not a big deal to find them and check their usage manually. However, optimizing compilers often replace them with inline versions.

If the compiler is popular and widespread, IDA Pro will find strcpy by Flirt signatures. But if you change a few compiler flags or use an unfamiliar version, IDA becomes blind. Let’s write a universal solution applicable to any compiler, regardless of processor architecture and build flags.

The strcpy function is often implemented as memcpy with strlen performing preliminary string length calculation. But optimized (e.g. in Visual Studio) versions are also available:

As can be seen, the code performs three operations:

• read a byte at a certain address;
• write the received byte to another address; and 
• return control to the beginning of the loop.

Each operation represents a primitive (i.e. an indivisible logical block that can be found in VEX code) First, let’s find a loop and then check whether it contains a read operation followed by a write operation applied to the read bytes.

In Angr, a basic block is a piece of code located before the command that transfers control. The algorithm is as follows: you analyze each block found by CFGFast; then you check whether the block has an exit that transfers the control flow to its own beginning (a primitive loop); after that, you analyze the VEX code by listing all commands inside the block; next, you find the read operation and remember the variable where the data are placed; and finally, you find the write operation and check where the same variable is used both in the read and write operations.

Importantly: you are looking for a read operation applied to one byte by specifying the data type as Ity_I8. By changing the size, you can filter out other loop implementations. But for the sake of simplicity, let’s stop there. Time to apply the script to a file with memcpy compiled in Visual Studio.

Experiments with other files bring additional variants.

In my humble opinion, the result is quite decent. You can find not only inline functions, but also makeshift memcpy functions that often contain implementation errors.

Attacking an application

I am going to use Freefloat FTP Server (zip) as a target; this is a classic example used by novice hackers programmers to polish their buffer overflow skills. Objectively, the easiest way to crash it is to write a protocol fuzzer. But I found it interesting and instructive to do this in a new way.

You cannot start emulation from the very beginning of the program since it would take huge amounts of memory and time. First, you have to choose an entry point. The moment when the data are received (i.e. WS2_32.recv) seems to be the ideal variant.

When you go two calls deeper into the IDA pseudocode, you see the function that parses the input at 0x402190. This is a class method, and the structure with all its data is passed to this class via ECX. I reconstructed it in IDA:

The code that fills out the initial structure can be found at the very beginning of the thread. Using the New operator, memory for it is allocated from the heap; then a second buffer 1024 bytes in size is allocated there; and a reference to it is placed inside the structure in INPUT_ptr_1024.

Your objective is to simulate the creation of this structure using your own code:

You create a new state at the entry of the parser. Then you ask Angr to fill uninitialized registers and memory areas with zeros. After that, you create a symbolic variable and substitute the input string with it. Angr supports interaction with structures; so, you can use them to write str_ptr.

If you run a test simulation, you’ll see that the number of active states quickly becomes greater than 300 (not to mention 8 gigabytes of RAM consumed by this process).

Avoiding path explosion

Let’s examine a possible implementation of strcpy:

Everything is simple when you are dealing with specific values, but if the string src_ptr is symbolic, then a fork occurs at each step of copying: exit the loop or go through another round.

Standard path searching will create two states for each iteration. In other words, to successfully ‘copy’ a symbolic string 128 bytes in size, 256 possible paths are required, and 255 of them lead to wrong places. And if the string is subsequently copied a few more times, then the number of possible paths increases to 256³!

Therefore, if you use standard path searching, it would take forever to create a complete copy of a long string. Let’s write a selection algorithm that goes through cycles to a specified limit without transferring control before the due time.

Angr makes it possible to replace almost any part of built-in algorithms with your own ones; in this particular case, let’s replace the successors function. It takes a specific state and returns addresses where the control flow will be transferred next.

The algorithm detects the presence of a loop and counts the number of iterations: if their number has reached the maximum depth, it exits; if the number of iterations is less, it continues running the loop.

Also, let’s substitute successor_func to remember the found unconstrained state: you won’t be able to find it in another place.

Reducing the number of states

The next step towards optimization is to limit the number of states to be examined. There are several branches inside the parser; each of them checks its own command: first QUIT, then USER, and so on. There is no point in going through all the commands simultaneously; instead, it’s better to perform a deep emulation of each command separately. First of all, let’s find the state at address 0x402212: it corresponds to the USER command branch.

Then you continue emulation without a specific goal. But if everything goes according to the plan, then at the end of the emulation (i.e. when all states reach ret of the first function), you’ll find unconstrained_state:

The code displays the input string that will enable you to seize control over execution.

Testing the exploit

Running the script:

It connects to the FTP server and crashes it. Congrats!