Apache Win32 Chunked Encoding (new version)

[hdm at metasploit.com (H D Moore)]

A few users have reported reliability problems with the Apache Win32 
Chunked Encoding exploit module. This module was rewritten shortly after 
the 2.3 release and switched from a jmp ebx/esi to a pop/pop/ret return 
address. This change allows the exploit to work against Windows XP and 
Windows 2003 targets. Unfortunately, the new method also requires a 
bruteforce of the return address alignment[1].

The code assumed that it would need to shift the address pattern 3 bytes 
at the most to line it up with the overwritten SEH function pointer. 
After further testing, it became apparent that some systems required a 
full 4 byte shift as well as a 0-3 byte alignment to correctly cover this 
pointer. Additionally, some combinations of operating system and apache 
version would shift the entire request around depending on the length of 
the string.

The solution was to allow for 0-7 byte alignment bruteforcing and pad the 
end of the request to even out the request size regardless of the pad 
value. The brand new module (attached) has been tested on Windows NT 4.0, 
Windows 2000, Windows XP (SP1 and SP2), and Windows 2003. The tested 
Apache versions include 1.3.9, 1.3.12, 1.3.17, 1.3.22, 1.3.24, and the 
versions included with Oracle (8i (8.1.7) and 9i (9.1.0, 9.2.0)). 

The new module will try the most common alignment values first. To use the 
new module, select a TARGET value that best matches the vulnerable 
system. Use the "check" command to determine the version and select the 
target that covers the detected version. If this fails, there is a chance 
that this is a custom build of Apache and that you will need to use an 
operating system specific return address instead. If you are attacking an 
Oracle 8i system, keep in mind that the server will fall down and die 
after the first attempt (successful or not). If all else fails, set the 
TARGET value to 0 for automatic and let it run through the entire list of 
possible return addresses and alignment values. 

Any test results or feedback would be appreciated, this bug affects so 
many things that I figured it was worth the time to do it right :-)

-HD


1. So why are we bruteforcing the return address alignment when this is a 
simple SEH overwrite? Reliability. Each version of Apache will shift the 
SEH location around by a few bytes. Since there are so many "custom" 
Apache builds out there, it does not make sense to hardcode the exploit 
to the publicly-available binaries. The common alignment values are 
placed first in the list of target values, but oddly-compiled servers can 
still be reliably exploited (such as Oracle's modified Apache). 

The request we send contains a set of chained backward jumps that will 
bring execution all the way back to the shellcode in the beginning of the 
buffer. This technique uses the standard SEH trick of placing a jump 4 
bytes before the address, but instead of jumping forward, it redirects 
execution to the previous jump:

[shellcode] [jmp -900] [pad] [jmp -16] [ret] [jmp -8] [ret] [jmp -8] ...

The [pad] value is incremented in size from 0 to 7 bytes, assuring that  
we will eventually line up the buffer with the SEH offset and redirect 
execution to the jump chain. The module specifies that the 
Payload->MinNops value is 200;  giving us some breathing room for the 
final jump before the getting to the payload. Different operating systems 
and versions will trash the  beginning of the payload with another copy 
of our request, this ensures that we will always be able to slide into 
the payload without hitting garbage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache_chunked_win32.pm
Type: application/x-perl-module
Size: 8852 bytes
Desc: not available
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20050319/58edccc5/attachment.bin>