Re: Re[2]: ms03-043 questions

["Dave Korn" <davek_throwaway () hotmail com>]

----- Original Message -----
From: "einstein, dhtm" <einstein_dhtm () front ru>
To: <vuln-dev () securityfocus com>
Sent: Thursday, November 06, 2003 6:03 AM
Subject: Re[2]: ms03-043 questions


> Çäðàâñòâóéòå, Adik.
>
> Âû ïèñàëè 3 íîÿáðÿ 2003 ã., 12:29:19:

[SNIP]

> A> my exploit for MS03-043 takes advantage of global SEH. I overwrote it
> A> with a pointer to my shellcode. make sure ur message body size is
> A> somewhere around 3656. works fine for win2k and winxp. btw u need to
> A> send packet 2 times on win2k, on winxp access violation exception is
triggered
> A> only with 1 packet send.

 Have you made sure the MAC address of the destination host was in the
sending machine's ARP cache before you send?  If you attempt to send any
kind of IP datagram to a host on your lan, and the arp cache doesn't have
the relevant MAC address (either the dest host's MAC, if local, or the
default gateway's MAC, if remote), then the TCP/IP stack will replace the
packet with an ARP request.  In the case of TCP you don't usually notice
this except as a slight delay, because the tcp retries sending the initial
SYN packet several times, but if you're attempting to send a single UDP
datagram, it might be dropped and replaced with an ARP request, and UDP
doesn't retry automatically.  My exploit works fine on 2k with just a single
packet, but you have to ensure the arp cache is valid, perhaps by pinging or
sending any other kind of network comms to the dest machine first.  I would
suspect that when you were testing, the XP hosts's MAC was in your ARP cache
and the 2k host's MAC wasn't.

 Also, it's important to ensure the system has been up and running in its
logged-in state for at least a little while before you test it.  There are
lots of other services running in the same process space, and during the
first minute or two after login, lots of processing and heap manipulation is
going on within services.exe/svchost.exe (2k/xp).  Leave the machine to get
into a steady state before you test, however, and you should find your
results pretty much 100% reliable.  This has been my experience, anyway:
send the packet early on, you tend to just crash some other thread in the
service host before the messenger thread gets overflowed and owned; wait
until it settles down, no problem.

> A> my exploit executes successfully but its not
> A> 100% reliable. try experimenting with message size. u might get
> A> different results
>
> Do you mean the "final" exception handler (which is usually set by
> SetUnhandledExceptionFilter) or per-thread handler at fs:[0] ?
> This article: http://www.jorgon.freeserve.co.uk/ExceptFrame.htm
> explains SEH in detail but the main difference of Heap based overflows
> is that it's usually not easy to locate you shellcode in memory (like
> in stack-based overflows). How do you overcome this difficulty ?

 When the UnhandledExceptionFilter finally jumps through the pointer in
KERNEL32!BasepCurrentTopLevelFilter, take a look at the memory around the
area pointed to by esi/edi/ebp, and somewhere you'll find a pointer to your
shellcode (varies according to windows version and sp).  For instance, under
W2k SP2 you'll see that both [esi + 0x48] and [ebp + 0x70] point to the area
just before your overwritten malloc chunk header.  Then you simply need to
find a jmp [esi+048h] instruction somewhere in the memory space of the
service host process, and use that address to overwrite the UEF.  Read Dave 
Aitel's recent paper about the DCOM bug, "MSRPC Heap Overflow - Part II", 
for a similar example.

     DaveK

_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection 
http://www.msn.co.uk/specials/btbroadband