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:
- the path to the COM server DLL is a relative path instead of an absolute one; and
- 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:
- how to get some Windows process on user's computer to try to initialize a chosen vulnerable COM server; and
- 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.)
(Credit for the above research goes mostly to Luka Treiber, security researcher at ACROS Security.)
Posts
