Tuesday, August 31, 2010

Online Binary Planting Exposure Test

ACROS Security has prepared a free public Online Binary Planting Exposure Test for all corporate and home Windows users who wish to test their exposure to binary planting attacks originating from the Internet. We'll try to keep a working demo of at least one unpatched, publicly disclosed vulnerability here for as long as there are any available.

This test is not an attack demonstration but rather a way for users to determine whether they could be successfully attacked from the Internet. While this test's failure to get the remote code executed on your computer does not constitute a proof of your security, its successful execution certainly proves your exposure and should prompt you to implement some countermeasures.

In particular, this online test can be useful for testing your binary planting countermeasures: Try the test with and without your firewall, test the effectiveness of your settings provided by Microsoft's CWDIllegalInDllSearch hotfix, or see if your anti-virus product protects you from the threat.

It is our goal to raise awareness of the binary planting problem among users, network administrators and developers. We hope this online test will help them understand the problem, test their exposure and fix their applications sooner rather than too late.

Test your computer now: Online Binary Planting Exposure Test

Click to see if you're exposed to remote Binary Planting attacks

Monday, August 30, 2010

Clearing up Some Misconceptions About Binary Planting

As much is being asked, reported and experimented about the binary planting bugs in all corners of the Net, we're noticing some misconceptions and misunderstandings flying around. In hope to set some of these straight, here are some explanations:

Misconception #1: CWD-Addiction Implies Vulnerability
If an application exhibits problems because of Microsoft's CWDIllegalInDllSearch hotfix, it doesn't mean that it is vulnerable to binary planting attacks. This most likely means that the application is relying on the CWD (current working directory) being in the search path - which is a Microsoft-documented "feature" -, and is setting the CWD to the location where the needed DLL actually exists (often some folder in the application's home directory) before calling LoadLibrary. Since the CWD is not set to an attacker-controlled location, this provides no attack potential. An example of such false positive is this Google Chrome report; Chrome sets the CWD to one of its own application directories before calling LoadLibrary

Misconception #2: Application Loading a DLL From Home Directory Is Vulnerable
An application's running a malicious DLL from its home directory (i.e., where the application's main executable resides), is not an indication of vulnerability to binary planting. The search path for loading DLLs starts with the application's home directory and it is normal (and desired) that the application loads DLLs from there. Unless the application's home directory has bad access permissions that allow a low-privileged user to plant such DLL there in order to get it executed later by another user who launches the application, there is no valid attack potential here. (After all, a local administrator can always replace any executable or DLL.) An example of such false positive seems to be this AutoCad report. (Disclaimer: we haven't tested this AutoCad report.

Misconception #3: The Power Of SafeDllSearchMode
We've seen claims that in order for an application to be vulnerable to binary planting, it must first disable the SafeDllSearchMode, thereby upgrading the CWD to the 2nd place in the search path. This is incorrect. While disabling the SafeDllSearchMode would certainly render even more applications vulnerable, the hundreds of applications we found to be vulnerable to binary planting - as well as those being publicly disclosed daily in various exploit lists - are loading their DLLs in the "safe search mode." Since most of the binary planting vulnerabilities seem to be due to applications loading non-existing DLLs, it really doesn't matter whether CWD is in 2nd or in 5th place in the search path.

Misconception #4: The Power Of SetDllDirectory 
Simply calling SetDllDirectory at the beginning of an application is not a magical solution that completely does away with the problem. Even assuming that this call causes no functional problems in the application or any external code it loads and executes, there are many cases of binary planting that this setting doesn't affect.

Misconception #5: The Power Of CWDIllegalInDllSearch Hotfix
Similarly, Microsoft's CWDIllegalInDllSearch hotfix only addresses a subset of all binary planting issues our research has uncovered. We're planning on publishing further details on this next week. [Update: read this for further information.]

Thursday, August 26, 2010

Releasing SHA-256 Hashes of Binary Planting Vulnerabilities

We're releasing SHA-256 hashes of 396 DLL planting and 127 EXE planting vulnerabilities we found during our extensive binary planting research. After a long internal discussion we decided that - considering the public availability of detection tools and instructions that make it possible for everyone to search for (a subset of) binary planting issues - it would not be appropriate to publish such information. We feel that doing so might encourage attacks against the identified vulnerable applications, which could negatively impact the security of end-users.

Hashes are available here: http://www.acrossecurity.com/files/binary_planting_sha256.txt

Tuesday, August 24, 2010

Binary Planting Update, Day 7

Yesterday, Microsoft officially responded to the Binary Planting issues discussed all over the web in the past few days. They published a number of documents (Advisory, SRD blog, MSRC blog and MSDN article on Dynamic-Link Library Security) and issued an update which introduces new functionality to Windows for mitigating Binary Planting attacks.

Now that these are out, let me present our story of collaboration with Microsoft. Perhaps you can learn something about the way things work in the background and draw your own conclusions.

First off, those of you looking for the typical vendor critique and Microsoft bashing: sorry, not this time. And for the record, Microsoft is not our customer, at least not in the paying sort of way.

Our research on Binary Planting came to a conclusion early this year by passing the 512-bugs target we've set at some point. During the research, we've been privately notifying our customers about bugs in their products and made it possible for them to fix them before the research would get published. At some point, though, it became clear that a publication of such a heavily populated class of remotely exploited vulnerabilities could easily cause a serious global security problem if billions of Windows users and organizations had no way to protect themselves - not just from the bugs we've found, but also from other bugs that some less law-abiding netizens would start discovering and exploiting.

On March 24, therefore, we contacted Microsoft and offered to present our research to them and start working on some solution or workaround that they could issue in a response to our planned publication. We included fully detailed bug reports for two of the 121 binary planting issues we'd thus far found in 41 Microsoft's applications.

Katie Moussouris and Maarten Van Horenbeeck, Microsoft's main security researcher coordinators, were quick to respond and a few days later, we had the first out of many long conference calls, walking through our slides and discussing both our findings and their options. It was obvious that Microsoft was not unaware of this problem (after all, they've been warning developers in many web articles for years) but they were genuinely surprised at its ubiquity and remote exploitability. It was immediately clear to them that something needs to be done and they asked us to give them time to prepare some solution not just for their vulnerable products, but for all applications running on Windows.

Since then, we've had countless late-afternoon/early-morning phone calls with Maarten and Katie, who really put their best effort, and a lot of it, into coordinating some of the brightest Microsoft security minds, including David LeBlanc, with our own knowledge in search of an optimal fix. It turned out there was no magical solution that Microsoft could dispatch to do away with binary planting in general, so the focus shifted to the best possible workaround. This meant, and still means today, that each vendor will have to fix their own products to completely eliminate the problem.

By mid July, Microsoft had prepared the mitigation which you can now get in their update and decided to delay its release until our research becomes public. Don't hold this against them though: it was in their customers' best interest to delay the delivery of the update because it would surely get reverse-engineered within hours, which would be roughly equivalent to disclosing the problem only to the bad guys. We, on the other hand, were planning on releasing our paper late August - but then our iTunes advisory let the "cat out of the bug", as HD Moore cutely mistyped on Twitter.

In parallel to the above, there was also a question of our providing the details of all 121 bugs in Microsoft's products to the Redmond giant. While we did give them a list of their vulnerable products (with versions), we declined to provide the details for free (this is our core business after all). However, there was no bad blood about it - Microsoft respects our desire to get compensated for providing such valuable data, and we respect their policy of not paying for vulnerability information. Also, Microsoft certainly has internal resources for doing their own bug-hunting once they know what to look for and where. So at the end of the day, this was a mere incompatibility of business interests, but the important thing is that it did not affect our fruitful collaboration on the more important issue - that of finding a cure for all users and all applications (not just Microsoft's).

In conclusion, we'd like to acknowledge Microsoft's Maarten and Katie for their really high-intensity involvement in this collaboration, but also the unnamed Microsoft engineers sweating in the background to provide the update available to users today. It isn't a perfect solution, but it should provide some protection until software vendors fix their products.

Monday, August 23, 2010

Binary Planting Update, Day 6

As some of you may have noticed, the world of Windows applications is looking at some bumpy times. Six days ago, our company ACROS Security has published an iTunes security advisory, describing what we called a remote "Binary Planting" vulnerability. This vulnerability allows a remote attacker to place a (preferably hidden) malicious DLL on a network shared folder alongside a media file, and when users open this media file, the DLL will get silently loaded and executed by iTunes. We also published two similar vulnerabilities in VMware Tools in April. Which is all nice in and of itself, speaking as a researcher.

However, there's more jewelery stored in this particular chest. Our company has been conducting an in-depth research on this type of vulnerabilities since November 2008. We first developed a tool for detecting these bugs and then, time permitting, subjected about 220 widely-used applications to the powers of our tool. Initially expecting only a few bugs here and there, we were surprised to find about 90% of the applications vulnerable. And when I say "vulnerable", I mean vulnerable to remote execution in a real-world scenario, without having any privileges on the user's computer. In December 2009, we applied for a patent on many different methods for detecting this type of vulnerability.

Earlier this year, we informed Microsoft about our research, which allowed them to prepare for the publication and possibly provide some solutions for the affected users. And judging from our research results, there will be quite many affected users - we can safely say that all Windows users can at this moment be attacked via at least one remote binary planting vulnerability.

Now, unsurprisingly, we were not the only ones researching this area. Hours after our publication of the iTunes advisory, our respected peer HD Moore disclosed the existence of about 40 so vulnerable apps that he found. While we weren't planning on releasing our research until the end of August, HD accurately Tweeted that "the cat was out of the bag", so it was time for us to disclose some information as well. Which produced news articles here, here and here, among others.

Today, academic researcher Taeho Kwon also joined the party with the research paper he and Zhendong Su have published earlier this year. Their paper mentioned a couple of vulnerabilities of the "remote binary planting" type, i.e., where the malicious binary is loaded from the current working directory, allowing for a remote, even Internet-based attack. In the above article, Kwon claimed to be in possession of 19 remotely exploitable vulnerabilities, and there's no reason not to believe it because they have proven their ability to find them. However, it would be wrong to think that over 1,700 "unsafe DLL loadings" mentioned in their paper allow for remote exploitation - in fact, most of them seem to require local administrative privileges for exploitation. That said, Kwon and Su have done a great job and a very thorough research, and can prove to be an important source of concrete Binary Planting vulnerability information in the weeks (months) to come.

Finally, why do we call it "Binary Planting" if it's an old bug that's already been named "DLL preloading", "Unsafe library path", "DLL spoofing" or, to some extent, "Vulnerable dynamic component loading"? The main shortcoming of these names is the fact that the same problem affects not only the libraries but also executables such as .EXE and .COM files. Our upcoming research paper will provide more details and will hopefully justify the new name.