Monday, September 26, 2011

More Misconceptions About Binary Planting

Last year, soon after revealing our binary planting research project, we published a blog post clearing up five frequently-appearing misconceptions at that time. Over a year (and about a hundred publicly fixed binary planting bugs in all sorts of software products) later, we're noticing a different set of misconceptions in public forums and on mailing lists. While we made our best effort to present binary planting in as comprehensible and clear way as we could, we accept responsibility for our undoubtedly imperfect rendition and hope this post will help interested readers to better understand our arguments.

Misconception #6: "This is a local attack."

We still occasionally come across this misconception that in a binary planting attack, the user has to willfully download a DLL or EXE and place it in some particular location on his computer, from where it will subsequently be launched. If this were true, binary planting would certainly be a ridiculous concept.

Actually though, in a typical binary planting attack the user doesn't have to download anything to his computer. He opens a file from a remote (attacker-controlled) shared folder and the vulnerable application on his computer automatically, silently executes a DLL or EXE from that same remote folder. Moreover, advanced attacks don't even require the user to do anything more than, for example, visiting a web page and clicking on two links - now who isn't doing that on a daily basis?

Misconception #7: "It doesn't work remotely on a default Windows machine."

We've heard objections that perimeter firewalls in typical networks won't allow internal Windows computers to access shared folders on an Internet-based server due to their default blocking of outbound SMB connections.

Windows 2003 Server introduced a Web Client service, which is an automatic WebDAV redirector for Windows networking connections. In short, this service makes it possible for Windows users to connect to remote network shared folders via the HTTP protocol, and this happens automatically when such connections via the SMB protocol fail. This means that even if a perimeter firewall blocks SMB network traffic towards the Internet, Windows will automatically try to connect to a remote shared folder via WebDAV (which is an extension of HTTP). We believe very few perimeter firewalls block outbound HTTP traffic as this would mean that internal users wouldn't be able to use their web browsers. WebDAV-only outbound blocking can be done by various firewalls, but this doesn't seem to be their default behavior in general *.

Anyone wishing to test whether their firewall allows outbound WebDAV connections can try to visit \\\demo with Windows Explorer on a reasonably default non-server Windows machine (with the Web Client service running or at least not disabled on a Windows 7 system).

Misconception #8: "Attacker could just as well get the user to open an executable."

We've heard this objection more than once and it goes like this: If in a typical binary planting attack scenario, the attacker has to trick the user to double-click a data file from a remote shared folder (which results in a vulnerable application loading a malicious DLL from the same folder), why couldn't the attacker simply get the user to double-click a malicious EXE with an icon of a data file?

It is entirely true that one can give an EXE an arbitrary icon and make it look exactly like any chosen data file such as Microsoft Word DOC or Adobe Reader PDF document. Furthermore, one can even disguise the way the file extension is displayed to the user using the UNICODE "right to left" trick. This makes it impossible for a user to visually distinguish an executable from a document file without manually inspecting their properties.

However, the difference comes after double-clicking the file, as long as this file is on a network share (as opposed to on a local drive): in case of a data file, the application associated with this file type gets launched and opens the data file; but in case of an executable, Windows display a security warning to the user saying that he is about to launch an executable from a network location and asking the user's permission to do so (see image below). While we have no field data on how effective such warning would be in stopping a "disguised executable" remote attack, it enables organizations to educate their users and increase their odds.

Moreover, double-clicking a file is not the only way to successfully trigger binary planting. The role of double-clicking in the attack is to set the current working directory to the location of the data file, so that the vulnerable application subsequently loads the malicious DLL from there. But the current working directory can also be set by opening the same data file by first launching the application and then using the File Open dialog to browse to the file and open it. (Very few applications don't change the current working directory this way.) Now, the file browse dialog will not show the disguised executable as it has an unsupported extension not matching the file type filter, and will not launch the disguised executable even if the user selects the "All files" filter, selects the executable and presses the "Open" button.

We hope this adequately describes the significant difference between a remote data file and a remote disguised executable in the context of a binary planting attack.


We'd like to end this post by thanking everyone contributing in public or private debates about binary planting vulnerabilities. We may not always all agree on everything, but such exchange of views, opinions and facts is exactly where new and better knowledge comes from. Thank you!

(* The amount of successfully received WebDAV requests from large and small organizations to our testing WebDAV server confirms that many perimeter firewalls are not blocking outbound WebDAV.)

Thursday, September 15, 2011

Microsoft's Binary Planting Clean-Up Mission

Slow, But Moving In The Right Direction

Since our presentation of COM server-based binary planting exploits at the Hack in the Box conference in May this year, Microsoft has introduced a number of relevant changes to Windows and Internet Explorer. To refresh our memory: in Windows, so-called "special folders" (e.g., Control Panel or My Computer) are implemented as in-process COM servers associated with unique CLSIDs and our researchers found that opening a file from an ordinary folder with name extension equal to some of these CLSIDs results in various DLLs being loaded and executed from this same folder. This has obvious security implications (details here and here) and our advanced binary planting research leveraged it to the point where it was possible to attack a user through Internet Explorer on both Windows XP and Windows 7.

Change #1: No "file://" Inside "http://"

The proof of concept we prepared was a web page that included a tiny (1 by 1 pixel) iframe hosting the content of a remote shared folder; when the user clicked anywhere on that page, he actually clicked inside the shared folder where the first click selected a file there, and the second one initiated the printing which triggered the binary planting bug.

Microsoft changed the behavior of Internet Explorer such that a web page (served via http://) can't display the content of a shared folder (served via file://) in a frame/iframe. This is good: there are probably very few cases where such mixture would be legitimately needed. And if you have a case like that, you can always put your web page in the "Trusted sites" zone.

Naturally this broke our proof of concept as we delivered it via http:// from However it is not difficult to circumvent this limitation: if the main web page is loaded via file:// as well, it will be allowed to display a remote share in a frame/iframe, at least if it's coming from the same server. Therefore our proof of concept could be brought back to life simply by having it loaded via file:// from file://\\\demo\XP_2-click\test.html.

Change #2: No "file://" From "http://"

If you're reading this in Internet Explorer and try to click on the file:// link at the end of the last paragraph, you will probably notice that it doesn't work. This was the second change introduced to Internet Explorer, and again a good one. An obvious attack vector for the typical double-click binary planting attacks is a link on a web page that opens up Windows Explorer with attacker's remote shared folder. Since most users would not be able to distinguish between the displayed "malicious" folder and a shared folder in their internal network, they could easily open a document in it - and get their computer owned.
Not allowing a web page loaded via http:// to open a file:// URL blocks this attack vector and this is good. Since other leading web browsers don't launch file:// URLs in Windows Explorer, the attacker is now left with secondary attack vectors such as e-mail, various documents and instant messages. (Unless he finds a way to circumvent this new IE barrier.)

Change #3: Away With deskpan.dll On Windows XP

The September Windows update MS11-071 introduced a number of changes, but the one most relevant to this post is the removal of a non-functional COM server on Windows XP registered with a non-existing DLL called deskpan.dll, which was used in our proof of concept. Esteemed paranoid readers of our blog have manually removed this COM server 100+ days earlier when we recommended it in May (see "How to protect yourself" section). We welcome Microsoft's move to fix this exploitable configuration error as part of a security update.


As we already hinted before, 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.

For instance, an attacker - having had the deskpan.dll COM server taken away from him - can migrate  his Windows XP exploit to the COM server with CLSID {32714800-2E5F-11d0-8B85-00AA0044F941}. This COM server loads C:\Program Files\Outlook Express\wabfind.dll (which exists) but then this DLL tries to load wab32res.dll without a full path. While wab32res.dll does exist in C:\Program Files\Common Files\System\, this folder comes after the current working directory in the search order - allowing a fake wab32res.dll to be loaded and executed from the attacker's "special" folder.

Furthermore, our research found that there are at least ten additional vulnerable COM servers on a default Windows XP installation.

Finally, the COM server-based binary planting vulnerability we described on Windows 7 has not been fixed yet. The "AnalogCable Class" COM server, registered with CLSID {2E095DD0-AF56-47E4-A099-EAC038DECC24}, still loads and executes ehTrace.dll from attacker's folder.


Microsoft is clearly putting an effort into removing binary planting bugs from their code and introducing mitigations that help block various binary planting attack vectors. While we know there's still a lot of cleaning up to do in their binary planting closet, our research-oriented minds remain challenged to find new ways of exploiting these critical bugs and bypassing new and old countermeasures. In the end, it was our research that got the ball rolling and it would be a missed opportunity for everyone's security if we didn't leverage the current momentum and keep researching.

Stay tuned - follow our research on Twitter.