MS11-071 漏洞利用具体方法

    Windows漏洞(MS11-071)，运行txt文本可中毒，微软急修“文本病毒”漏洞：https://lcx.cc/post/1787/

    MS11-071：Windows 组件中可能允许远程执行代码漏洞：https://lcx.cc/post/1791/

    根据描述可以看出是因为Display Panning CPL Extension 也就是 deskpan.dll 引发的漏洞，不仅可以本地应用还可以远程应用，通过web让访问者点击链接就可以触发漏洞。这里不仅有文字说明还有视频可看详见：

    http://blog.acrossecurity.com/2011/05/anatomy-of-com-server-based-binary.html

    MS11-071是一个经典的DLL劫持漏洞，爆出MS11-071的是下面老外的这个BLOG：

    http://blog.acrossecurity.com/2011/05/anatomy-of-com-server-based-binary.html

    这个漏洞关联的两个DLL文件分别影响windows7和XP，仍然是系统的库文件兼容问题，但是这次明显严重得多，影响微软的多个富文本文档！

乌云上也有类似的案例：

    1.浏览器的HTML文档的DLL劫持漏洞。

http://www.wooyun.org/bugs/wooyun-2010-02530

http://www.wooyun.org/bugs/wooyun-2010-02197

    2.影音类文件的DLL劫持漏洞。

http://www.wooyun.org/bugs/wooyun-2010-02507

------------------------------------------- ↓ 国外原文 ↓ -------------------------------------------

Tuesday, May 24, 2011

The Anatomy of COM Server-Based Binary Planting Exploits

[May 6, 2011 update: we published a proof of concept for this vulnerability.]

Last week at the Hack In The Box conference in Amsterdam we presented some techniques for advanced exploitation of binary planting bugs. The stage was set by our previous blog post where we described how unsafely registered COM server DLLs, as well as safely registered COM server DLLs that make unsafe binary loading calls, could be abused for mounting binary planting attacks. This post reveals our work to the rest of the world.


The Magic Of Special Folders

One of the elements we used in our exploits were Windows special folders. Special folders are folders that can be shown by Windows Explorer but don't always behave like ordinary folders, which simply contain files and other folders. Some examples of special folders are Control Panel, My Computer, My Documents, Administrative Tools and Printers. Every one of these special folders is implemented as an in-process COM server with a specific class identifier (CLSID). For instance, the CLSID of My Computer is {20D04FE0-3AEA-1069-A2D8-08002B30309D}.

Let's begin with a small magic trick (works on XP, Vista and Windows 7): Create a new empty folder anywhere on your file system and rename it to folder.{20D04FE0-3AEA-1069-A2D8-08002B30309D}. (Note that the CLSID must be the extension of the folder name, i.e., must come after the final dot.) Immediately after renaming, the folder's icon will be changed to the icon of My Computer and, moreover, opening the folder will actually show the My Computer content.

Apart from having an obvious entertaining value, this trick also plays an important role in our exploits. Many applications, when processing files from special folders, or display the content of special folders, trigger the instantiation of such folders' COM servers based on the CLSIDs in their extensions. Which brings us to the first exploit.


Double-Click Attack 1: Wordpad on Windows XP

As already mentioned in our stage-setting blog post, all Windows XP installations have a registered COM server called "Display Panning CPL Extension" with CLSID {42071714-76d4-11d1-8b24-00a0c9068ff3}, implemented by a non-existing deskpan.dll. Consequently, if some application decided to instantiate such COM server, this would result in loading deskpan.dll from the current working directory. As you might have guessed, the special folders magic can make an application instantiate just any registered COM server. Let's do this with Wordpad.

The video below shows the following procedure:

1. create a "malicious" deskpan.dll;
2. create a new folder and rename it to files.{42071714-76d4-11d1-8b24-00a0c9068ff3} - note that Windows XP hide the folder extension, and that this special folder still behaves like an ordinary folder;
3. copy the malicious deskpan.dll to the new folder;
4. open the folder;
5. create a new rich text document in the folder;
6. double-click the rich-text document.

After double-clicking the rich text document, Wordpad gets launched and its current working directory gets set to the special folder (which is the expected behavior). However, for reasons unknown to us, Wordpad then triggers a call to the COM server-instantiating function CoCreateInstance with the CLSID of our special folder. This causes a registry lookup for the COM server DLL (deskpan.dll), and then an attempt to load this DLL using a LoadLibrary call. Failing to find this DLL in Wordpad home directory as well as in all Windows system folders, the "malicious" deskpan.dll is finally loaded from our special folder and executed.


Double-Click Attack 2: Applications on Windows 7

In contrast to Windows XP, a fresh installation of Windows 7 has no unsafely registered in-process COM servers. It does, however, have several safely registered COM servers whose DLLs make unsafe library loading calls. (XP and Vista have such DLLs too.)

One such case on Windows 7 is the COM server called "AnalogCable Class", registered with CLSID {2E095DD0-AF56-47E4-A099-EAC038DECC24} and having C:\Windows\System32\PsisDecd.dll as its DLL. When an application instantiates this COM server, the PsisDecd.dll is loaded from the System32 folder (which is okay), but this DLL quickly makes a call to LoadLibrary("ehTrace.dll"). Now it's not that ehTrace.dll doesn't exist on Windows 7: it does exist in folder C:\Windows\ehome - but applications launched outside this folder are unable to find it. This means that applications from folder C:\Windows\ehome, for instance ehshell.exe, can safely and successfully instantiate the said COM server, while other applications automatically become vulnerable if they try to do the same.

The video shows the following procedure:

1. create a "malicious" ehTrace.dll;
2. create a new Microsoft Word 2010 document;
3. create a new Microsoft PowerPoint 2010 document;
4. create a new text document;
5. create a new PDF document;
6. create a new folder and rename it to files.{2E095DD0-AF56-47E4-A099-EAC038DECC24} - note that Windows 7 also hide the folder extension, and that this special folder still behaves like an ordinary folder;
7. copy all four data files and the "malicious" DLL to the new folder;
8. open the folder;
9. double-click the Word document; (causing Word 2010 to execute the "malicious" ehTrace.dll)
10. double-click the PowerPoint document; (causing PowerPoint 2010 to execute the "malicious" ehTrace.dll)
11. double-click the PDF document; (causing Nitro PDF Reader to execute the "malicious" ehTrace.dll)
12. double-click the text document; (launching Notepad but not immediately executing the "malicious" DLL)
13. selecting "File -> Save As" from the menu in Notepad. (causing Notepad to execute the "malicious" ehTrace.dll)

The second trick is clickjacking. This old trick is simply used for hiding the actual attack inside a 1x1 iframe such that wherever the user clicks on the web page the first time (anywhere on the page, not only on links), he actually clicks inside this tiny iframe - precisely on the Wordpad document shown in a remote shared folder, thereby selecting this document. The iframe then repositions its remote content such that when the user clicks again, he actually clicks on the "Print this file" link in the same remote shared folder as before, thereby launching Wordpad and executing the malicious DLL inside it. Now, since most attackers want to hide their attacks as much as possible, we made the demo such that when the user clicks inside the tiny iframe, we detect that and simulate the click on the underlying web page as well, which is why the links apparently clicked on actually respond to the clicks.

For those of you preferring the schematic diagrams, here's how it works in the language of objects, arrows and annotations (taken from our Hack In The Box slides).

Again, the schematic diagram of the attack:

Lessons Learned

The main takeaway from our presentation was that binary planting, as a conceptual problem with loading binaries on Windows, is not at all a trivial problem if you really understand the numerous details and hidden processes that affect and enable it.

By shedding light on a few previously unknown attack vectors we only revealed a small portion of our advanced binary planting research, which is aimed at improving the exploitation of various binary planting vulnerabilities. If we want to convince developers to fix security defects, we need to show them that they're easy to exploit, and we hope to see some proactive effort as a result of our work. And this is by no means aimed towards Microsoft alone; it was simply easiest for us to use the components that come with Windows, but we found a large number of other vendors' product to be exploitable in the ways described above.


How To Protect Yourself?

Apart from our generic recommendations for administrators, a couple of additional temporary measures will protect you from the attacks described in this post (but unfortunately not from numerous similar attacks):

1. On Windows XP, delete the {42071714-76d4-11d1-8b24-00a0c9068ff3} registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.
2. On Windows 7, copy ehTrace.dll from C:\Windows\ehome to the System32 folder.

What's next?

We'll continue to raise awareness of this vulnerability class we call binary planting. There's a lot of misunderstanding about it among developers as well as security researchers, and we'll do our best to change that. Our first humble milestone is to stop seeing new product versions making unsafe LoadLibrary calls. Unfortunately, we don't seem to be anywhere close to that.


(Again, most of the above research has been done by Luka Treiber, security researcher at ACROS Security.)