#immunity debugger

This is  the second video about how to crack a program with Immunity Debugger!

This is a video about how to crack a program with Immunity Debugger!

Introduction

I wanted to gain some hands-on experience with developing a proof-of-concept for a buffer overflow type of attack. 

Buffer overflow attacks basically come about when an application has a buffer (a block of memory set aside) in which input data gets stored that is larger than the buffer that is to hold that data. This results in the ability of an attacker to gain control of the application's flow of instruction, and to have the ability to redirect the application to run the attacker's own code.

I wrote a simple test application that contains a buffer overflow vulnerability to test out the process of gaining control over a vulnerable application, and this post describes how I did it.

Background information

The basic idea of how a stack works is the following:

The stack data structure is like a stack of plates. We are limited to what we can do with this data structure. When we want to store data onto the stack, we can only "push" data (like the plates analogy) onto the top of the stack. When we want to retrieve data, we can only "pop" from the top of the stack. So, the stack data structure is a "last in, first out" sort of structure.

In an application, the stack is used to be able to keep track of needed data that each function uses when it runs. In terms of memory location, the stack grows from higher memory address to low memory address. In other words, the stack grows downward in the application's process space.

The top of the stack is tracked by a register called "ESP" (Extended Stack Pointer). Whenever data gets pushed onto the stack, the ESP register's value gets decremented, and whenever data gets popped off of the stack, the ESP register's value gets incremented.

During a call to a function, memory on the stack is set aside for a few pieces of data. The called function's parameters, the address of the next instruction to be run once the called function returns, the "base pointer", and local variables are all saved onto the stack.

Once the function that has been called has finished, this function needs to clean the stack by removing the data that was allocated for it. It does this by decrementing the ESP register and placing the address of the next instruction to be run into a register called the "EIP" (Extended Instruction Pointer). 

Vulnerable applications will take data and store this data into a buffer without doing any checks on whether the data will fit the memory allocated to store that data. Without any bounds checking, an attacker will be able to feed the vulnerable application with a large piece of data and be able to overwrite EIP, thus having control over the next instruction that the application should run!

The Proof-of-Concept Process

I created the test application that included the vulnerability, and the code is shown here:

#include "stdafx.h"

void readFunc(const char *, FILE*);

int main(int argc, const char * argv[]) { FILE * pFile = NULL;

readFunc(argv[1], pFile);

printf("The end.");

return 0; }

void readFunc(const char* arg, FILE * pFile) { char strInput[32] = {0}; const char * strMode = "r"; pFile = fopen(arg, strMode);

fscanf(pFile,"%s", strInput);

fclose(pFile); }

I used VS 2012 to build the above test application. In order to simplify the attack scenario, I did the following:

In Project Properties->C/C++->Code Generation->Security Check, I turned off this option (set to /GS-). This is so that in the stack, security cookies aren't embedded around the buffer, and so when I overwrite the buffer and then write past the stack frame, the test application will still keep running.

In Project Properties->Linker->Advanced->Data Execution Prevention (DEP), I turned off this option (set to /NXCOMPAT:NO). This is so that when I fill the stack with shellcode, it will be able to run.

In order to be able to run the application on WinXP, I used the "Visual Studio 2012 - Windows XP (v110_xp)" platform toolset.

I chose Windows XP SP2 as the environment that I used to run the vulnerable application.

First, I needed to try to control the test application's EIP register. I did this by trying to feed the application a long list of autogenerated characters. I used Metasploit's  pattern_create ruby script. Given a string length, this script will generate a string with a known pattern. I then ran Immunity Debugger on my vulnerable application. I noted the contents of the EIP register. I then used Metasploit's pattern_offset ruby script to determine the offset location of the hexadecimal pattern that I saw in the EIP register.

Next, I created a python script to generate the input string for the test application (shown below). It also includes something called a "NOP slide". A NOP is an instruction that does nothing. This NOP slide is used to (eventually) place some shellcode in a correct offset such that it can be recognized as valid instructions. 

Again, I ran Immunity Debugger on my vulnerable application and fed the application the string that was generated by my python script (shown above). Below is the resulting output from Immunity:

As we can see from above, the EIP is filled with 42424242, which is BBBB in hex.

Next, I needed a way to redirect the application to run instructions written found in the stack. The instruction is "jmp esp" (FF E4) and I found this instruction by the following method:

In Immunity Debugger, went to "View"->"Executable Modules". There is a list of libraries that have been linked with the vulnerable application. I started with ntdll.dll.

I opened ntdll.dll and did a Ctrl-F in order to find the expression "jmp esp". I then took note of the memory location of this instruction. This is shown below (top left window pane, first line - for me, this instruction lives in the address 7C941EED):

Once I found the memory location of the "jmp esp" instruction, I substituted that for the contents of the EIP in my python script, as shown below:

(Note: the EIP string in the above python script is written backwards, in order to match the little-endian format of memory address)

Finally, I was able to redirect the application to run the next instruction from the stack (note that I took out the shellcode and only placed the nop slide into the stack - I still need to work out why the shellcode isn't working and this will be the topic of the next post). I also found out about the INT 3 opcode (0xCC). Debuggers use this opcode to put in debug breakpoints in code. This opcode comes in handy when you put it int he middle of the NOP slide in order to just do a check on your proof-of-concept.

"Weee! I'm riding a nop slide!" - Sandra 

Next post will be all about shellcoding! Stay tuned!

Source: