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 http://www.binaryplanting.com/demo/XP_2-click/test.html. 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://\\www.binaryplanting.com\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.

However...

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.

Conclusion

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.