Sunday, January 17, 2010

In case you missed them, here are entries one and two. These tutorials are designed to build upon skills taught in each of the preceding tutorials, so I recommend that you complete the first two before you attempt this one.

In this entry we will be doing another SEH Stack based overflow, however in this case our buffer will be translated into a hexadecimal value in memory at the point where the SEH overflow occurs. This requires us to structure our buffer slightly differently, and also requires us to use a different method to find our SEH overwrite offset.

The vulnerable application we will be using is Serv-U 9.0.0.5, which has an exploitable vulnerability related to its handling of overly long Session cookie values.

Warning! Please note that this tutorial is intended for educational purposes only, and you should NOT use the skills you gain here to attack any system for which you don't have permission to access. It's illegal in most jurisdictions to access a computer system without authorisation, and if you do it and get caught (which is likely) you deserve whatever you have coming to you. Don't say you haven't been warned.

Required Knowledge

To follow this tutorial you will need to have basic knowledge of:

TCP/IP networking,

management of the Windows Operating System (including installing software, running and restarting services, connecting to remote desktop sessions, etc), and

running Python scripts.

You need to have good enough knowledge of the attacking system you use (whether it be BackTrack, another type of Linux, Windows or anything else) to be able to run programs and scripts as well as transfer files.

Knowledge of basic debugger usage with OllyDbg, including the ability to start and attach to programs, insert breakpoints, step through code, etc, is expected. This is covered in my first tutorial.

I will also expect at this stage that you know how a SEH Based Buffer Overflow exploit is achieved. This is covered in my second tutorial.

Python programming skills and knowledge of Metasploit usage are a bonus but not required.

System Setup

In order to reproduce this exploit for the tutorial, I used a victim system running Windows XP SP2, and a attacking system running BackTrack 4 Final.

You don't need to reproduce my setup exactly, but I would suggest sticking to Windows XP SP2 or earlier for the victim system. The attacking system can be anything you feel comfortable in, as long as it can run the software I have specified below, and as long as you are able to translate the Linux commands I will be listing below into something appropriate for your chosen system.

If required, you can get a XP SP2 Virtual Machine to use as your victim by following the instructions in the Metasploit Unleashed course, starting in the section "02 Required Materials" - "Windows XP SP2" up to the section entitled "XP SP2 Post Install".

Your victim system must also use a X86 based processor.

In this tutorial my attacking and victim systems used the following IP Addresses. You will need to substitute the addresses of your own systems where ever these addresses appear in the code or commands listed below.

Attacker system: 192.168.20.11

Victim system: 192.168.10.27

The two systems are networked together and I have interactive GUI access to the desktop of the victim system via a remote desktop session. You will need to be able to easily and quickly switch between controlling your attacking system and the victim system when following this tutorial, and you will need to be able to transfer files from your victim system to the attacking system, so make sure you have things set up appropriately before you proceed.

Required Software on Attacking and Victim Systems

Your attacker and victim systems will need the following software installed in order to follow this tutorial. By using BackTrack 4 Final for your attacking system you will take care of all the attacking system prerequisitites.

For this particular exploit, we need to send a rather large buffer to the vulnerable application, so ensure that the network between the two systems is reliable. If you are having issues reproducing the exploitable crash, the networking layer could be causing the problem. Confirm that you are not getting RST packets from the victim system while sending the malicious HTTP request if you can't make the application crash. If this is the case then you will need to troubleshoot the problem at the network layer.

Serv-U also doesn't give you an obvious error when it isn't listening on port 80 because some other application has already bound to that port. Confirm the process that is listening on port 80 by using the following commands:

Check the output of the following for the process listening on port 80 and note its process ID (PID):

netstat -ano

Match the PID listening on port 80 with its process name using the output from the below and ensure that the Serv-U.exe process is the one listening on port 80:

tasklist

Ensure that all required software is installed and operational before you proceed with this tutorial.

Attaching the Serv-U Application to a Debugger

I have covered the process of attaching a vulnerable application to a debugger extensively in my last two tutorials, so I will just provide a very brief overview of the process here.

The process that you want to attach to in OIllyDbg is named Serv-U.exe, and by default it will be installed as a Windows service named "Serv-U File Server". Stop and start the process by using the Services Control Panel option, and use OllyDbg to attach to the process once it is running.

As before, you will need to restart the vulnerable process and reattach to it in the debugger each time you want to reproduce the exploitable crash.

Triggering the Exploitable Crash

After checking the POC in the original advisory, looking at otherexamples of the exploit, and one other advisory, I discovered that the exploitable crash can be reproduced by sending an overly long Session cookie to the Serv-U application in a HTTP Post request.

After some trial and error involving sending different buffer sizes to the Serv-U application, and viewing the structure of the stack in the debugger, I eventually settled on a Session cookie size of 96000 bytes as being optimal for exploitation. I won't reproduce the entire process I used here, because it makes for pretty boring reading, but it basically involved modifying the size of the buffer sent, and confirming that the SEH Handler on the stack was overwritten and that there was space inside our sent buffer after the SEH Handler. The second criteria is not absolutely necessary, but it makes exploitation slightly easier.

Since the crash is triggered by a Session Cookie sent in a Post request, we can essentially trigger it via sending the following to port 80 on the target system:

POST / HTTP/1.1
Host: Hostname
Cookie: Session=[96000 characters]

A skeleton exploit that will trigger the crash by sending a long string of "A" characters (the ASCII representation of a byte value 0x41) is shown below:

When we trigger this crash we will get an access violation, and if we check the SEH Chain (View->SEH Chain menu option) we see that it has been overwritten with 'AAAAAAAA'.

This is unusual, because we sent the application a buffer full of 0x41 bytes, and if the SEH Handler had been overwritten from our buffer we would normally expect to see a value of 41414141, or four lots of 41. Instead, each byte that makes up the the SEH Handler overwrite has the value 'AA'.

It looks as though the ASCII representation of the bytes we have sent (which is 'A' for 0x41), have been converted to a hexadecimal nibble (half a byte) so that the value of two of the bytes we have sent are now represented in a single byte in memory.

Lets further test this theory by sending some different values in our buffer and checking to see how they are represented in memory when the application crashes.

The 'abcd' has been translated to hexadecimal ABCD, apparently that fact that our ASCII string was lower case didnt stop this Hexadecimal translation from occurring. Lets try 'fghi'. (For the next few examples to conserve space I will only show the lines of code I changed)

buffer="fghi" * 24000

This time the SEH Handler points to Crash points to 000F000F. The lowercase 'f' was converted to a Hexadecimal F, and the 'ghi' characters, which don't have a Hexadecimal equivalent, were converted to 0.

Lets try one more - 'efgh'.

buffer="efgh" * 24000

This time the SEH Handler points to 00EF00EF. So ASCII characters A-F, regardless of case, are translated to hexadecimal values A-F, and any other character converts to a 0.

Lets do a check with numbers '0123' to confirm our Hexadecimal theory.

buffer="0123" * 24000

This time, the SEH Handler value is 23012301. So our ASCII string of characters that we send to the application in the Session cookie is interpreted as a Hexadecimal value in the memory buffer that overwrites the SEH Handler.

Finding the Overwrite Location

In the previous two tutorials, we found offset values within our buffer via using the Metasploit pattern_create.rb script. This method is not going to work in this case however, because the Metasploit script uses characters outside of the 0-9, A-F range, and it uses both uppercase and lowercase characters. Any of these out of range characters will be translated to a 0, or the case information for the A-F characters will be lost, and this will prevent us from being able to provide the correct input value to pattern_offset.rb to find the offset.

We will have to use a different method to find the overwrite location. Knowing that characters 0-9 and A-F will be represented in the memory display we see in the debugger, we can use a set of structured buffer made up of these characters only to narrow down the exact overwrite location.

Given that we have 16 characters we can use, we first break the buffer of 96000 into 16 x 6000 character blocks. Then, based on what the overwrite value of the SEH Handler is, we will know which 6000 character block our overwrite occurs in. The following code will do this for us:

When we run this exploit, the value of the SEH Handler is set to DDDDDDDD. If you want to, you can confirm that the buffer is structured as expected by right clicking on the SEH Handler Value in the SEH Chain window and selecting Follow address in stack.

On the stack you should be able to see that the SEH Handler sits within a large buffer of D values (with the exception of some minor mangling just before the SEH Handler).

This means that our overwrite occurs in the 'D' section of our buffer. This gives us a range of 78000 and 84000 where our overwrite location sits, given that 0xD x 6000 is 78000 and 0xE x 6000 is 8400.

Now lets narrow this down further. 6000 divided by 16 is 375. Lets create a buffer of mostly 'A' characters, but lets put a block of 6000 characters made up of an even distribution of values 0-9 and A-F (375 of each) between bytes 78000 and 84000.

The next value of the SEH Handler is AAAAAAAA. This means that the overwrite occurs between bytes 3750 (0xA x 375) and 4125 (0xB x 375) within our 6000 byte buffer, or between bytes 81750 (3750 + 78000) and 82125 (4125 + 78000) within the total buffer.

If we check the overwrite location on the stack we can see the 'B' values starting a little bit below the block of 'A' values that have overwritten our SEH Handler, so we know that we are within our 6000 mixed block.

Lets narrow it down once more. 375 doesn't divide evenly by 16, so we will use a block of 24 sets of 0-9 and A-F characters, making for a total block of 384. As long as we completely cover the 375 character space that we know our overwrite location sits within, it doesnt matter if we go a bit over. We insert this set of mixed characters into the 375 byte window where we know our overwrite location sits - sometime after byte 81750.

This again gives us a SEH Handler value of AAAAAAAA and when we check the stack we can see that the SEH Overwrite occurs after the tenth A character, and the pointer to the next SEH record (the 4 bytes immediately before the SEH overwrite) also has the value AAAAAAAA, and occurs after the second A character.

From this we can actually work out the exact overwrite address. For the pointer to the next SEH record it is 2 + 240 (0xA x 24) + 81750 = 81992.

Lets restructure our skeleton exploit and see if the SEH Handler is overwritten by the expected value of CCCCCCCC.

Now that we know the exact offset of the SEH Handler overwrite within our buffer, we need to find an appropriate address that can allow us to gain control of code execution via the Windows error handling routines.

As discussed in my previous tutorial on SEH Buffer Overflow exploitation, we need to find a module loaded by the application that hasnt been compiled with the /SafeSEH ON option AND which hasn't disabled all addresses in that module being used as SEH Handlers by using the IMAGE_DLLCHARACTERISTICS_NO_SEH flag.

As it did in the last tutorial, the OllySSEH Ollydbg Plugin crashed for me again, so Im doing things the slightly harder way once more.

I checked the list of loaded modules in OllyDbg (View->Executable Modules menu option) and looked first for a third party module loaded with the application.

As mentioned in my previous tutorials, a third party module (in other words one provided with the application itself) has the benefits of usually being compiled without the /SafeSEH ON and IMAGE_DLLCHARACTERISTICS_NO_SEH options, making it suitable for use with SEH overwrite exploits. It also provides a stable overwrite location that should work across multiple Operating Systems, since dlls provided with the application should be identical and should be loaded from the same base address on different systems.

Looking at the list I picked the first module provided with the Serv-U application that did not have a leading zero byte in the base address - libeay32.dll. I picked a module without a leading zero byte because zero bytes usually break buffer overflows, however it turns out in this case this doesn't actually matter because the character conversion that occurs creates each byte that appears in memory from two ASCII characters sent from our exploit. This means that we can actually create a zero byte in memory if we wish by using two ASCII zeros (\x30), effectively giving us no bad characters in this exploit!

Lets transfer this file to our attacking system and analyse it with msfpescan to confirm that it doesn't have the compiler options set that would make it unsuitable for use in providing a SEH Overwrite address.

Remember that If we see any SEHandler entries, it means that a SEH Handler exists in the dll and that the module was compiled with /SafeSEH ON. We see no such entries here, so we are safe on this count.

In the DllCharacteristics value, we want to confirm that the third byte from the left does not have the '4' bit set to confirm that the module does not have the IMAGE_DLLCHARACTERISTICS_NO_SEH flag set. If the value of the third byte (the one marked by 'X' in 0x00000X00) is not '4, 5, 6, 7, C, E or F' (in other words if the '4' bit or 00000100 is not on), then the module does not have this flag set. The third byte does not have the 4 bit set, so we are safe on this count as well.

Now lets proceed with finding an appropriate overwrite address in libeay32.dll. As discussed in my SEH Buffer Overflow tutorial, to take control of code execution, we can enter into our buffer by using a RETN instruction on the third value on the stack at the time that the initial exception is handled using the Structured Exception Handler. To do this we look for a POP, POP, RETN instruction in libeay32.dll.

View the code of libeay32.dll in OllyDbg (right click on it in the Executable Modules window and hit Enter or right click and select View code in CPU), and right click in the CPU pane and select Search for->Sequence of commands.

Enter the following commands to be searched for and hit Find:

POP r32
POP r32
RETN

Like so:

I found my a POP, POP, RETN instruction at 0FB010C1 in libeay32.dll which I will use to overwrite the SEH Handler to gain control of the CPU.

Making use of the Character Translation to Gain Control of Code Execution

Now if you remember from my first SEH Overflow tutorial, running the POP, POP, RETN instructions takes us into our buffer four bytes before the SEH Handler address. What we want to do to give us some usable buffer space to work in is to jump over the overwritten SEH Handler to the uninterrupted buffer space beyond. A JUMP SHORT 6 instruction will achieve this for us, but remember that we cant just enter the \xeb\x06 into our buffer directly because of the character translation to Hexadecimal. What we need to do is instead enter the ASCII equivalent of "EB06" and let the Hexadecimal translation convert this for us to the byte equivalent.

We also need to ensure that when we enter the overwrite location we take into account the little endian order of the x86 CPU, so we enter the overwrite location of 0FB010C1 as "C110B00F". Lets see the skeleton exploit:

If you set a breakpoint on the SEH Handler address and run this exploit, after you pass the exception through to the application to handle using the Shift + F9 keys, you should now be able to step execution through to the area of the buffer after the SEH Handler using the F7 key.

Remember that to set a breakpoint you can either select the address in the CPU pane and hit F2 or just hit F2 on the entry on the SEH Chain window once the crash has been triggered.

Adding the Shellcode

Now we have control of the CPUs execution path, we need to add some shellcode to our exploit so it will do something useful. Again, we won't be able to directly add the bytes of the shellcode directly to our exploit, we will need to convert them to ASCII characters first.

This command below will generate some reverse shell shellcode, and convert it to a workable format that can be easily pasted into our exploit.

An explanation of what this command is doing may be helpful. We run msfpayload using the R option to provide the output in raw bytes, and we then pipe this into 'xxd -ps' to convert the binary output from msfpayload into the Hexadecimal representation of the values of each individual byte. This is similar to what you would see in a Hex Editor and also similar to the C output format of msfpayload without the \x characters before each byte.

When then pipe this into 'tr 'a-f' 'A-F''. This is not strictly necessary since the case of the A-F characters doesn't matter for the purpose of the Hexadecimal translation, Im just doing it to make what we enter visually match what appears in the debugger.

Then we pipe that into 'sed 's/0A$//'' which removes the trailing line feed character added by msfpayload. We then pipe into 'sed 's/$/"/'' and 'sed 's/^/"/'' which adds double quotes to the end and start of each line for easier pasting into our exploit.

13 comments:

Do you involve inn the Ethernet Driver level events synchronizing with TCP sockets?I'm using an open source TCP stack Lwip(?) and the Ethernet driver on my board keeps having low level buffer overflow and reset.But these events are not feed to TCP socket level, resulting the onnection failure. I think I should connect the events at level driver with socket state to control the window size and gap time... Do you have any suggestions? Thanks

Could you elaborate the solution regarding the networking layer problem. I'm not able to trigger the vulnerability, and wireshark does find an RST packet.I tried changing the fragmentation and RTS threshold on my router and sending a smaller buffer, but still no result.

I tried sending the buffer from a machine on the same subnet. At first it didn't work, but after sending the buffer about 25-30 times the program crashed.So far I have not been able to crash the program again.

Then, about sending the buffer to the loopback address.I got a bit confused about the setup.I downloaded and installed the windows python interpreter from www.python.org on my target machine. Then I ran the skeleton exploits with address:127.0.0.1and port:80 , but the debugger didn't report an error!Trying to find out where I screwed up I installed Wireshark on my target machine and found out the Wireshark isn't able to capture on the lo interface in windows. This is were I got stuck.

Try sending from the machine itself and use the externally available interface instead of the loopback. This will eliminate errors caused by other elements of the network and should let you capture the traffic using Wireshark.

The value that the program expects to be entered here probably only has valid byte values in the range of 0x00 to 0x0f. It could be expecting an MD5 hash for example...

The translation is probably done to make storage of the value more efficient, e.g. the ASCII characters "AA" which would normally take up two bytes in memory can be stored in one byte after this translation.

By the way, if you check the code for Vulnserver you will see one (probably quite inefficient) method of performing this character translation. And theres also more overflow tutorials associated with Vulnserver in case you didnt know too,,,

I am currently testing a http fuzzing tool and would like to found the minimum amount of bytes of 'A's to crash a server. So I wrote a python script, it does crash the server but it doesn't overwrite the EIP of the debugger with 'A's. So I would like to seek assistance for my issue. I would like to know is it whether my python script the way I wrote having issue or other issue.

Depends on what server you're fuzzing. It looks like you're trying to overflow the URI component of a HEAD request with up to 256 A characters. Is the server you are fuzzing vulnerable to an EIP overwriting vulnerability in that parameter? Are you sure you don't need to add the HTTP version or any other headers to your request?