mailing list archives
Apache Win32 Chunked Encoding (new version)
From: hdm at metasploit.com (H D Moore)
Date: Sat, 19 Mar 2005 04:23:13 -0600
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.
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 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 :-)
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...
Size: 8852 bytes
Desc: not available
- Apache Win32 Chunked Encoding (new version) H D Moore (Mar 19)