呵，foreigner已经开始关注了~这个0day估计也就一周的寿命了~ 关注wordpad的0day中。。。哪儿有人放出点细节来嘛。。。
2008/12/10 大风 <[EMAIL PROTECTED]> > > > 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 > Safe > <http://bbs.360safe.com/viewthread.php?action=printable&tid=597258>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%22%22>, > 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 Girls with Browser Memory > Protection Bypasses<http://phreedom.org/presentations/how-to-impress-girls/>, > 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 > Moore<http://www.breakingpointsystems.com/community/blog/authors/HD%20Moore>(2008/12/09 > > > > > > > > *[Ph4nt0m] <http://www.ph4nt0m.org/> * > > *[Ph4nt0m Security Team]* > > * [EMAIL PROTECTED] <http://blog.ph4nt0m.org/>* > > * Email: [EMAIL PROTECTED] > > * PingMe: > <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wuhq&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>>
