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)

Similarly to the Wordpad exploit on Windows XP, the above exploits are based on the curious and heavily undocumented nature of special folders, which makes otherwise innocent applications instantiate chosen COM servers. Thus Word, PowerPoint and Nitro PDF Reader (and many other applications) all try to instantiate the "AnalogCable Class" COM server while having their current working directory set to our special folder. This results in a search for ehTrace.dll, and in the loading of "malicious" ehTrace.dll from our special folder. The final target, Notepad, does not get hacked simply by opening a file - but does execute the "malicious" DLL when the "Save As" dialog is opened. Apparently Notepad does not automatically trigger the COM server instantiation when a document is loaded, but opening the "Save As" dialog causes the code behind this dialog to interact with the special folder, thus instantiating the appropriate COM server.

Leveraging COM Server Exploits Through Web Browsers

Skeptics among you may say that, okay, this opens up new attack vectors for various binary planting vulnerabilities, but the user would still have to double-click a document on a remote share. And users wouldn't do that, would they? (Of course they would but let's pretend they wouldn't.) So in order to satisfy the most demanding among you, we leveraged the above exploits through web browsers, resulting in some pretty user-friendly scenarios, in a manner of speaking. Let's start with Windows XP and Internet Explorer 8.

Web Attack 1: Internet Explorer 8 on Windows XP

The following video shows how a user would experience the attack. Visiting a malicious web site, clicking once on one link, and again on another, is enough to get a remote binary executed on his computer.

Two tricks are employed in the background of this attack. The first is aimed at launching applications without double-clicking. One of the methods we found for this makes use of the default Windows XP Task View, i.e., the task list shown in Windows Explorer on the left of each folder view. When a printable document is selected in the folder, this task list includes the "Print this file" link which, when (single-) clicked upon, launches the application associated with the file type of the selected file and instructs it to initiate the printing process. The procedure is thus: 1) click the file in a remote special folder to select it, and 2) click "Print to file" to launch the application which then loads a malicious 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).

Web Attack 2: Internet Explorer 9 on Windows 7 With Protected Mode


We've already seen that applications can be made vulnerable through unsafe COM servers on Windows 7 just like on Windows XP. But there are two additional challenges here. First, Windows 7 don't have the task view like Windows XP do, so another way to avoid double-clicking had to be found. And second, you can't just launch any application from IE when in protected mode without popping up the yellow security warning.

For the first challenge we chose to reveal a "right-click, send to compressed (zipped) folder" trick. IE allows the user to right-click a folder inside a remote shared folder (without a warning), and then select "send to" and "compressed (zipped) folder" from the context menu. This triggers a process of compression, which sets the current working directory of IE to the remote shared folder - and completes the first part of the attack.

The second challenge was overcome with the help of verclsid.exe. This curious little executable, mostly unknown to users, gets frequently launched in the background and quickly terminates without any visible effect. Verclsid.exe is, ironically, a security measure introduced by a Windows security update associated with bulletin MS06-015, but to us it is interesting because it is "whitelisted" for the IE protected mode: when IE launches a new verclsid.exe process, the user doesn't have to okay a security warning. Furthermore, verclsid.exe instantiates the COM server associated with the extension of a chosen special folder, providing just the binary planting opportunity we need. In our attack, we trigger the launching of verclsid.exe by loading a number of different special folders in an additional 1x1 iframe while IE has its current working directory set to our remote shared folder. Since verclsid.exe is launched by IE, it also inherits IE's current working directory (which hosts our "malicious" DLL) and eventually loads our DLL. The attack is again hidden with clickjacking.

Let's see how the user experiences this attack. Visiting a malicious web site, right-clicking anywhere on the page and selecting  "send to" and "compressed (zipped) folder" from the context menu is enough to get a remote binary executed on his computer.





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.)