Exploit Development under Windows

Today we are going to demonstrate how to exploits can be developed under Windows operating system. We are going through a process of reverse engineering, but first we have to give you some definitions.

Memory Corruption: its when a programming error causes a program to access memory in an invalid way, overwriting memory reserved for a different variable. It causes access to uninitialized or freed memory that may allow an attacker to take control of a program.

Memory Corruption Classes: buffer overflows, format string injection, integer overflows, uninitialized memory use and more ..

Memory Corruption Exploits: their goals usually is to inject a machine code payload "shellcode" and get the target program to run it.

So today we are talking about Exploit Development and we will have to:

• Identify methods of controlling memory corruption.
• Leverage controlled memory corruption to affect the program's behaviour in a way that  would give an attacker more privileges, capabilities, or access to the system.
• We would like to make it execute our payload.
• Getting a remote root /SYSTEM shell !

We are going to analyse a vulnerable windows application and will use immunity debugger to inspect the program. Registers, stack and opcodes will be demonstrated in the post. We will take a whole look in the program state in the debugger.

We are going to use FUZZING where we will learn how to use it to find the vulnerability. Fuzzing involves sending malformed strings into the application input and watching for unexpected crashes.

The steps we are going to do in order to exploint windows buffer overflaws:

• Replicating the Crash.
• Controlling EIP.
• Locating Space for the shellcode.
• Redirecting the execution flow.
• Finding a return address.
• Basic shellcode creation.
• Getting our shell.

In our demonstration we will use a simple vulnerable chat server called SikaBoom, it can be downloaded from here

Replicating the Crash:

Immunity Debugger with vulnerable program loaded

We will start fuzzing on port 4321 which is the listening port of the vulnerable program using a python script called uiofuzz.py can be downloaded from here. Before launching the fuzzer lets open wireshark in live capturing mode.

start uiofuzz.py by:

where argument -n is for network fuzzing mode, -ip is for the remote ip of the host computer where SikaBoom is listening on for connections, -port is the port number to be fuzzing through and in our example its 4321 the same port of SikaBoom, -c is the type of characters to be used in the fuzzing process and here we chooses a stream a A letters.

Suddenly the fuzzer stops and we got a crash in SikaBoom server, Go to wire shark to see how many bytes used to crash the server.

by following the TCP Stream we found that 18908 bytes was sent and caused the crash.

here is when the server was crashed.

here we see that the server wasn't able to execute the EIP at 41414141 which is the hex code of AAAA \x41\x41\x41\x41 and here at the ESP 0022F970 we can see the stream of 'A's. Now we want to get exactly how many 'A's needed to crash the server so we will use a tool from metasploit called pattern_create.rb and patter_offser.rb.

pattern_create.rb will be used to create a pattern of 18908 bytes in order to know the exact byte where the server crashed, launch the script by:

here is the generated pattern

here we will use a simple python script to send these bytes to the server after restarting immunity debugger, you can get the python script from here. here we execute the python script after changing the remote ip of the machine where the server is running on.

the server crashed at EIP 6A413969

lets get the byte position that was the reason of this crash by running pattern_offset.rb tool as follow:

we needed exactly 268 bytes to cause a flow in the memory, next we need to test if the EIP can be controlled or not, we will insert 268 'A's and 4 'B's into our poc script to see if the server crashed at the 'B's or not. new poc can be downloaded from here.

after launching the poc the server stopped again

the server crashed at EIP 42424242 which are the 4 'B's in our poc

the next step is to locate the space for the shellcode. as seen above the ESP where the 'C's start is at 0022F970 we need to get the space between the start and the end of these 'C's but right click on the esp and choose follow in dump, then get the address at the beginning and the ending of the 'C's stream, in our example the starting ESP is 0022F970 and he ending is 0022FD98, by calculating the difference [ending - starting] the space needed is 428 hexadecimal = 1064 decimal.

next we need to redirect the EIP to our shell code by calling the DLL needed to launch the shellcode. press Alt+E to open the modules window where you will find kernel32.dll address , double click on it to follow in dump

no we have to ways either by searching for call esp ot jmp esp
we will try to search for call esp, we found it at address 7C836A08, in this type of processors we need to write the address reversely as 08 6a 83 7C and by hex it will be exactly \x08\x6a\x83\x7C.

lets test our poc again with the address to the kernel32.dll

you can download the poc from here , the server crashed at kernel32.dll address  ,it means that we can control the EIP and execute our shellcode.

now we are successfully able to redirect the execution flow of the program. we will now write a simple shellcode that calls the calculator, note that we are using windows xp sp3, our shell code is:

        
        "\x31\xC9\x51\x68\x63\x61\x6C\x63\x54\xB8\xC7\x93\xC2\x77\xFF\xD0"

      
the poc including the shellcode can be downloaded from here, lets execute the poc and see what happened.






Calculator was successfully launched!

in real world exploitation the calculator shell code is replaced by meterpreter or windows shell shellcode. 

Hope that this was well demonstrated. your comments are welcomed :)




By Anwar Mohamed
Inspired from Mohamed Ramadan