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

"Binary Planting" vs. "DLL Hijacking" vs. "Insecure Library Loading"

Binary Planting's Multiple Identities

When a new thing occurs or is invented, or when a previously obscure thing becomes popular, a need emerges to give it a name so we can talk and write about it. It was no different with binary planting, DLL hijacking, DLL preloading, insecure library loading, DLL load hijacking and DLL spoofing. Except that, unfortunately, these different names all describe essentially the same thing - an attack* against a Windows application where this application loads a malicious executable instead of some intended legitimate one. We get asked a lot why we choose to use the term binary planting, so here's our reasoning.

One major reason for us to dislike words "DLL" or "library" in the name is that this problem affects not only dynamic-link libraries but also other types of executables. Furthermore, "DLL" sounds as if the insecurely loaded library always has a ".dll" extension - which is not the case, as our research has found applications trying to load libraries with extensions ".ocx", ".nls", ".tbp" and many other funny extensions. We chose to use the noun binary, which covers all types of executables involved in these vulnerabilities. So why not simply use executable? Executable is too long a word and would probably quickly be shortened to "EXE," causing a similar misunderstanding we already have with "DLL."

As for other shortcomings of the alternative terms:

• DLL hijacking implies that either a DLL gets hijacked or something gets hijacked using a DLL. But in large majority of binary planting vulnerabilities the binary (for instance, a DLL) in question does not exist - that is, until the attacker plants it. You can't hijack something that doesn't exist. One could say that a vulnerable application gets hijacked through a malicious DLL but then every vulnerability could be called hijacking of some sort. Note, however, that before Windows XP SP2, the dynamic-link libraries search order had the current working directory in the 2nd place, which produced a lot of possibilities to actually hijack an existing DLL (e.g., one from the Windows system folder) by placing a malicious copy with the same name in the current working directory. Back then, hijacking would have sounded more suitable.   
• DLL preloading implies that some presumably malicious DLL gets loaded in advance (of something). We find no such advance-loading process taking place in the context of this vulnerability.
• Insecure (library) loading sounds accurate as long as it's only libraries one considers. When other executables (EXEs or COMs, for example) join the party, loading is not a very suitable term any more. While technically, these also get loaded before they're executed, it's more common - and more understandable - to say they get ran, started, executed or launched.
• DLL load hijacking is a little better than DLL hijacking as it implies that it is the process of loading that gets hijacked (and used for malicious purposes). However, this term contains an unfortunate hard-to-pronounce triple-L, and is likely to quickly (d)evolve into DLL hijacking. And again - just like with insecure library loading -, loading is not a very suitable term for non-library executables (EXEs, COMs, etc.).   
• DLL spoofing is actually a nice term, short and accurate, but has long been widely used for another similar but conceptually very different activity, namely manually replacing an existing DLL on one's own computer in order to change the behavior of an application or operating system. This activity has nothing to do with security, at least not in terms of one person (attacker) doing something bad to another person (user), since the user does it to himself, so to speak.   

We chose the verb planting because, in our opinion, it accurately describes what the attacker needs to do in order to carry out the attack: planting a malicious binary somewhere where a vulnerable application will pick it up and execute it.

So these are our reasons for preferring the term binary planting to other alternatives for describing the entire scope of the problem. As it currently seems, DLL hijacking (for describing an attack) and insecure library loading (for describing a vulnerability) are here to stay as well, at least for libraries. This will certainly continue to cause unneeded confusion but perhaps a vulnerability class that has been overlooked for such a long time deserves more than one name.


(* Strictly speaking, the term insecure library loading does not describe an attack, but a vulnerability.)

Silently Pwning Protected-Mode IE9 and Innocent Windows Applications

Binary Planting Through COM Servers

This blog post sets up the stage for our Hack in the box presentation in Amsterdam on May 19.

[Update: Find the continuation of this blog post here.]

Those familiar with Windows COM servers know that they come in two types, in-process and out-of-process. For this post, the former type is of interest: an in-process COM server is a dynamic link library (DLL) that a COM client instantiates when needed, usually by calling the CoCreateInstance function with the class identifier (CLSID) of the said COM server. What happens then is the COM server initialization code looks up the provided CLSID in local registry under key HKEY_CLASSES_ROOT\CLSID, and finds the path to the DLL under the InProcServer32 subkey. It then expands eventual environment strings in the obtained DLL path and calls LoadLibrary with the resulting path. Whatever happens afterwards is of no interest to us here.

From the binary planting perspective the above process would be vulnerable if both of the following conditions were met:

1. the path to the COM server DLL is a relative path instead of an absolute one; and
2. the DLL doesn't exist in the LoadLibrary search path prior to the current working directory (i.e., in COM client's home directory or any one of the Windows system folders).  

Condition #1 is at the discretion of whoever registers the COM server. While most COM servers are registered with full absolute paths to their DLLs, some merely specify the name of the DLL without the path. This may not be due to a developer's oversight or laziness: the so-called side-by-side COM components (see here and here) require the DLL to be specified with a relative path.

Condition #2 is a bit more tricky as it seems unlikely, at the first glance, that someone - or some application - would register a COM server that doesn't exist on the system. But for reasons beyond our willingness to investigate, some software products do just that. Furthermore, some other software products fail to unregister their COM servers upon removal, leaving the user's computer with exploitable remnants of a removed COM server DLL. And finally, in the case of side-by-side COM components, these DLLs are successfully found and loaded when the COM server is invoked by the original application (the DLL is in the same folder as the COM client executable), but if another applications tries to invoke the same COM server, it won't find the DLL and will finally try to find it in the current working directory - to attacker's great satisfaction.

If you're now asking yourself whether such cases where both conditions are met actually exist: we did a quick search on our testing systems and found a few, one of them being preinstalled, so to speak, on every Windows XP machine, and others being introduced by various software products. Let's take a look at the "preinstalled" XP case.


The "preinstalled" XP binary planting vulnerability

On every Windows XP machine, there exists an in-process COM server named "Display Panning CPL Extension" with CLSID {42071714-76d4-11d1-8b24-00a0c9068ff3}. Truth be told, we don't know what its purpose is, and neither does the searchable Internet, but the DLL it specifies under the InProcServer32 subkey is "deskpan.dll". This is a relative path to a DLL that doesn't seem to exist on any XP system, and thus meets both of the above conditions.

Therefore, if any Windows process tries to create an instance of this COM server for whatever reason, and the current working directory of that process is set to an attacker-controlled location (possibly on a remote share), the attacker can plant a malicious deskpan.dll and have the said process load and execute it on user's computer.

Windows 7, Vista, and well-registered COM servers

Naturally, such attack also works on Windows 7 and Windows Vista as well as older Windows systems, as long as some registered COM server fulfills the above conditions. But it does, as usually, get even worse: we found that many well-registered COM servers on all Windows versions, having specified their DLL with an absolute path, load additional DLLs with a relative path, and many of these DLLs do not exist. This provides extensive binary planting potential to a great number of flawed LoadLibrary calls that could previously be considered non-exploitable. Yes, on all fully up-to-date Windows versions without any additional software installed.

The questions that now remain unanswered are:

1. how to get some Windows process on user's computer to try to initialize a chosen vulnerable COM server; and
2. how to get the current working directory of that process to point to the attacker's remote share?  

At the Hack in the box conference in Amsterdam on May 19, we will answer these questions by demonstrating two of our previously unpublished hacks:


Demo #1: Exploiting innocent Windows applications

First we will demonstrate how various applications on your Windows 7, Vista or XP can be forced to initialize any vulnerable COM server, and load a malicious DLL in the process. We'll show how Microsoft Word 2010 and PowerPoint 2010 execute a malicious DLL upon opening a document on Windows 7 (something that doesn't occur under normal circumstances), even in "protected view."  


Demo #2: Pwning protected-mode IE9 without warnings

And as if that weren't enough, we will show how this technique can be leveraged to launch a binary planting attack against Internet Explorers 8 on Windows XP as well as against Internet Explorer 9 in protected mode on Windows 7 - without any suspicious double-clicks or security warnings. (For the impatient: it's not through ActiveX controls.)

We look forward to seeing you in the audience and sharing our research with you. Of course we will also tell you how to avoid introducing described vulnerabilities in your own software creations and how to protect your web browsing experience from the perils of binary planting. In the mean time, we've updated our Binary Planting Guidelines For Developers accordingly.

(Credit for the above research goes mostly to Luka Treiber, security researcher at ACROS Security.)