Dailydave mailing list archives
Re: Fwd: RE: We have the enemy, and the enemy is... you
From: H D Moore <hdm-daily-dave () digitaloffense net>
Date: Thu, 13 Apr 2006 22:20:19 -0500
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)
Current thread:
- RE: We have the enemy, and the enemy is... you Sandy Wilbourn (Apr 13)
- <Possible follow-ups>
- Fwd: RE: We have the enemy, and the enemy is... you Olef Anderson (Apr 13)
- Re: Fwd: RE: We have the enemy, and the enemy is... you Alexander Sotirov (Apr 14)
- Re: Fwd: RE: We have the enemy, and the enemy is... you Matt (Apr 14)
- Re: Fwd: RE: We have the enemy, and the enemy is... you H D Moore (Apr 14)
- RE: Fwd: RE: We have the enemy, and the enemy is... you Dave Korn (Apr 14)
- Re: Fwd: RE: We have the enemy, and the enemy is... you Chris Wysopal (Apr 14)
- RE: RE: We have the enemy, and the enemy is... you Paul Melson (Apr 14)
- RE: RE: We have the enemy, and the enemy is... you Andrew R. Reiter (Apr 14)
- Re: Fwd: RE: We have the enemy, and the enemy is... you Alexander Sotirov (Apr 14)