Microsoft released patches for 28 individual vulnerabilities today, covering everything from a stack overflow in Internet Explorer 5.0 to a command execution flaw in the desktop search component of Windows Vista and Server 2008. Although BreakingPoint Labs will be uploading a StrikePack tomorrow covering these bugs, we thought it would be interesting to talk about a bug that Microsoft did not patch.
Earlier today, PC World published an article by Robert McMillan that discusses <http://www.pcworld.com/article/155190/new_web_attack_exploits_unpatched_ie_ flaw.html> an unpublished code execution flaw in Internet Explorer 7. This flaw is being exploited in the wild and was discovered by the KnownSec <http://www.KnownSec.com/> team, who then posted details to the 360 <http://bbs.360safe.com/viewthread.php?action=printable&tid=597258> Safe forum. Ryan Naraine wrote an article on the ZDNet Zero-Day Blog <http://blogs.zdnet.com/security/?p=2283> that summarizes the flaw and confirms that today's patches will not address this vulnerability. To find a live exploit sample, I followed a link on McMillan's article to the SCANW blog entry <http://www.scanw.com/blog/archives/303> . This blog entry recommends that users enable DEP and add two domain names to a blacklist (wwwwyyyyy.cn and sllwrnm5.cn). I plugged these domains into Google and found links to the drive-by exploit pages hosted on these domains (1 <http://www.google.com/interstitial?url=http://wwwwyyyyy.cn/9/123.htm"&; quot;> , 2 <http://www.google.com/interstitial?url=http://sllwrnm5.cn/a243/fx.htm> ), as well as additional domains where the exploit is being hosted (down.hs7yue.cn, js.tongji.cn.yahoo.com, www.baikec.cn, www.laoyang4.cn, www.oiuytr.net, and www.taisha.org). After digging through the encoded exploits, I found two URLs which were serving live samples. Both were being hosted on Microsoft IIS systems as static web pages, which allowed me to determine when they were last modified on the server: hzzp://wwwwyyyyy.cn/9/as.htm Last-Modified: Mon, 08 Dec 2008 05:25:50 GMT Date: Wed, 10 Dec 2008 00:20:10 GMT (sample @ 18:20 CST) hzzp://sllwrnm5.cn/a1/ss.htm Last-Modified: Tue, 09 Dec 2008 19:43:55 GMT Date: Wed, 10 Dec 2008 00:21:03 GMT (sample @ 18:21 CST) Converted to Central Standard Time, we see that the first exploit was last modified at 11:25pm on Sunday night, while the second was last modified at 1:43pm today. The forum post by KnownSec has a date of "Sun, 07 Dec 2008 14:36", which assuming Chinese Standard Time, places the Central Standard Time equivalent at 10:43pm on December 6th, or over a 24 hours from the time that the two samples I found were last modified. The KnownSec team must have discovered an older version of the exploit or a different source web site. The timeline is interesting, but the fun part is the exploit itself. The first of these two samples is plain, readable code. There are no nasty encodings or other attempts to hide the attack from anti-virus and IDS products. The second is encoded, but trivial to take apart and obtain the final decoded output. The exploit can be broken down into three parts. The first part is a set of three functions used by the exploit. The first function provides the equivalent of a sleep() call, the second sprays a string into the process heap using a common technique, the third returns a string of a specific size and is used by the heap spray code. The second part of this exploit is the shellcode. Without getting into too much detail, this shellcode downloads the real payload - a Windows executable. The third part is the actual vulnerability trigger. After cleaning up the code and removing the unnecessary bits, I ended up with: <XML ID=I><X><C> <![CDATA[ <image SRC=http://ਊਊ.AAAAA.lan SRC=http://BBBB.lan > ]]> </C></X></XML> <SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML> <XML ID=I> </XML> <SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN> </SPAN> The bug, as far as I can tell so far, is dependent on the two SPAN tags. The first SPAN tag instructs Internet Explorer to format the data source referenced in the XML document as HTML. The second SPAN tag is exactly the same, but does so inside the first SPAN tag. This leads to heap corruption that overwrites an object pointer with the first four bytes of the host name of the first <image> SRC attribute. Internet Explorer will expand those unicode entities in the host name into two-byte values, resulting in a total of four controllable bytes overwriting the object pointer. In this case, I picked ਊ which is equivalent to 0x0a0a in hexadecimal. Two of these together expand to the 32-bit pointer of 0x0a0a0a0a, which is an address often used in browser heap overflows due to its "reachability" via heap spraying. Going back to the original exploit, we see that the code stuffs a huge string into memory with the contents set to "\x0a\x0a\x0a\x0a" repeatedly, followed by the shellcode. This code is trying to force the browser to allocate so much memory that the process address 0x0a0a0a0a points into a buffer full of the string "\x0a\x0a\x0a\x0a". The reason for this will made clear later in this post. After stuffing this string into memory, the exploit then waits 6 seconds using the sleep() function. Once this completes, the exploit uses the document.write() method to dump the XML/SPAN code above into the document. The browser renders this code, triggers the heap corruption bug, overwrites an object pointer, and then tries to call a method on that object. This eventually leads to a block of assembly code like the following: mov ecx,dword ptr [eax] push edi push eax call dword ptr [ecx+84h] At this point, the eax register points to 0x0a0a0a0a. This register is storing a pointer to the object that the exploit clobbered with the unicode entity inside the first <image> SRC attribute. The first instruction of the code above reads 4 bytes of data at the address eax points to and stores it in the ecx register. Since the exploit forced the browser to allocate so much memory containing the 0x0a string, the ecx register will now be set to the value 0x0a0a0a0a as well. Finally, the browser pushes the edi and eax registers onto the stack, reads the pointer located at ecx+0x84, and call this pointer. Again, since ecx points to 0xa0a0a0a, ecx+0x84 points to 0x0a0a0a8e. The address 0x0a0a0a8e also points into the giant string of 0x0a characters ending with the actual shellcode. Now the browser is executing the string of 0x0a characters as if it were executable code. The 0x0a byte happens to decode to the x86 instruction "or cl,[edx]". This instruction reads the data pointed at by the edx register and uses the boolean OR operation to combine the lower 8 bits of this value with the lower 8 bits of the ecx register (cl). Since the edx register happens to point into readable memory, this is a "do nothing" instruction (aka nop or noop equivalent) and will continue executing until it hits the end of the string. By appending the shellcode to the end of this string, the exploit was able to successfully abuse this vulnerability to run shellcode, which in turn downloads and executes the real payload, a standalone Windows executable. This object pointer/heap spray technique is a common way to exploit heap corruption vulnerabilities on Internet Explorer and is another reason why Microsoft rated so many of this month's Internet Explorer flaws as 'Critical'. Exploiting this flaw relies on two core requirements; being able to force the instruction pointer to the location of the shellcode and being able to execute the shellcode once the instruction pointer has been set. The first requirement boils down to being able to allocate memory at a known location with arbitrary contents. If it is possible to control the exact location where memory is allocated, a large buffer that doubles as a nop sled is no longer necessary. The second requirement depends on the operating system, configuration, and hardware of the target system. Many of the articles that discuss browser exploits recommend that users enable Data Execution Prevention (DEP). This setting essentially breaks common heap overflow techniques by preventing shellcode from executing in memory regions that are considered "data", such as the Internet Explorer heap. Unfortunately, DEP is not enabled in Internet Explorer 6 or 7, so unless DEP is manually enabled, it does the target little good. When dealing with Internet Explorer 6 targets, an easy way to meet the first requirement is to use the heapLib <http://phreedom.org/presentations/heap-feng-shui/> javascript library developed by Alexander Sotirov. This library provides an API for fake vtable allocation at reliable, predictable addresses. This removes the need for a heap spray or nop sled on Internet Explorer 6 targets. While most of heapLib's features are useful against Internet Explorer 7, my own attempts to use it to test this particular flaw failed. The fake vtable appears to be purged from memory, which reduces its utility when exploiting an overwritten object pointer vulnerability such as the one covered in this post. Solving the second issue involves bypassing DEP when it has been manually enabled and defeating NX and ASLR protections on Windows Vista and Server 2008. At Black Hat USA 2008 (among other venues) Alexander Sotirov and Mark Dowd co-presented a talk entitled How to Impress <http://phreedom.org/presentations/how-to-impress-girls/> Girls with Browser Memory Protection Bypasses, which focuses on making browser exploits reliable, regardless of what protection mechanisms are in place. The techniques outlined in their talk and the associated paper <http://taossa.com/archive/bh08sotirovdowd.pdf> should be a perfect fit for reliably exploiting this particular flaw, even on operating systems such as Vista that enforce ASLR. BreakingPoint customers will receive exploit coverage for this flaw, as well as those patched by Microsoft in Wednesday's StrikePack. Posted by HD <http://www.breakingpointsystems.com/community/blog/authors/HD%20Moore> Moore (2008/12/09 [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
