Opening a Can of Binary Planting Worms

Binary Planting as Worm Propagation Method 

Unsurprisingly, worm authors find binary planting a great method for their digital monsters to propagate from infected systems to new ones. Symantec's analysis of Stuxnet provides a good insight into one of this worm's methods for propagating among users of a particular software product, in this case Siemens SIMATIC STEP 7. Like many other mission-critical and expensive software products, SIMATIC STEP 7 has a binary planting vulnerability that loads a DLL from a data folder; if the DLL is there, it gets executed. This is a typical binary planting attack vector, and in this case also reveals the user population the worm is targeting.

Using binary planting for malware propagation is not new: in 2001, the infamous Nimda worm was planting riched20.dll alongside various Microsoft Office documents in an attempt to get it executed by other users when they opened these documents.

At the time of this writing there are 102 published and unfixed binary planting issues available for all worm authors out there to use. Add to these the 500+ binary planting issues we've discovered during our research (only a handful are published) and extrapolate the ubiquity of these flaws to all Windows software, and you'll get a feeling of the threat we're facing today. Right now, a worm that simply sprays malicious dwmapi.dlls all over the place should be very successful in its propagation, let alone a slightly more intelligent one that can map DLLs to document extensions and update its knowledge as new binary planting holes are found.

So are we entering an era of binary planting worms? Who knows? There certainly is no shortage of binary planting bugs nor is there likely to be one soon, and it is unreasonable to expect most Windows computers to have any protection against binary planting in place. On the other hand, worms will probably prefer the "double-click-bang" binary planting bugs to maximize their success-to-detection ratio, and many of these happen to be the relatively easy to find (and therefore more likely to get fixed).

I say "many of these" because in contrast to the binary planting issues published these days where a vulnerable application always loads a malicious DLL upon startup, we found many cases where  DLLs get loaded depending on various triggers, predominantly the content of data files. Worm authors may therefore decide to focus on such "triggered" binary planting issues which are more difficult to find but have a longer life expectancy. Undoubtedly, vulnerability black markets will be happy to accommodate such vulnerabilities for those who wish to focus on writing malware and leave vulnerability research to others.

Then again, worms don't particularly care about the types of vulnerabilities they use for propagation, as long as they get the job done quietly and efficiently. Perhaps, therefore, it is most likely that tomorrow's worms will simply add unpublished binary planting issues to their arsenal, along with buffer overflows and other types of remote execution methods.

As always, it is again up to software vendors to decide how much ammunition they want to make available to the malware authors. As it is again up to users to tolerate it or not.

Binary Planting Attack Vectors

There's more than one way to skin a cat... or plant a binary, for that matter.

There seem to be differing views among IT professionals on how easy or difficult it is to actually mount a binary planting attack. Microsoft's Jerry Bryant, for instance, was quoted saying: "Due to the fact that customers need to click through a series of warnings and dialogs to open a malicious file, we rate most of these vulnerabilities as Important," possibly referring to this attack example. On the other hand, Aviv Raff prepared a demo page for exploiting the (now fixed) uTorrent binary planting bug via Google Chrome (see video), showing how users can be tricked into a binary planting trap without any warnings. Attacks using USB tokens and CD/DVD media were discussed (which are quite feasible), and many researchers are convinced that binary planting attacks are fairly easy to mount. Our own experience in penetration testing confirms binary planting to be currently one of the most efficient and reliable methods for obtaining remote access to workstations in target networks.

Our team has done an analysis of many different delivery methods for binary planting attacks, providing a hopefully more comprehensive view on the feasibility of such attacks. We looked at some of the most popular web browsers, most popular e-mail clients and most popular document readers, trying to use them as delivery mechanisms for binary planting attacks.

Both Microsoft's and Raff's scenarios are included in the analysis along with many others. We've also provided a couple of demonstrations that you can test for yourselves and see how/if they're working for you. (Combine these with our online binary planting test to demonstrate the issue to your customers and friends.)

Some interesting findings:

• Clicking a link to a remote shared folder on a web page will open this share in Windows Explorer without a warning for 67% of all Internet Explorer users.
• Clicking a link to a remote shared folder in an e-mail message will open this share in Windows Explorer without a warning for all Outlook, Windows Mail and Windows Live Mail users, regardless of their default web browser. (E-mail is the most likely vector for targeted attacks on corporate and government networks.) 
• In contrast to Internet Explorer, we found no way to launch Windows Explorer via a hyperlink from Firefox, Chrome or Opera, while Safari does open a remote shared folder when the web page containing the link comes from a local drive (e.g., attacker sends an HTML file to the user via e-mail.)
• The Protected View makes Word 2010 and Excel 2010 less suitable for binary planting attacks, as documents originating from Internet or received via Outlook require the user to confirm a security warning before hyperlinks are enabled. 

All in all, it appears that most  attack scenarios don't include any security warnings. Users should therefore be careful when opening any hyperlinks - not just on web pages, but also in e-mail, documents and IM messages.  

See the Binary Planting: Attack Vectors analysis and find out how you can be attacked.

Binary Planting Goes "EXE"

Yesterday, Apple issued new versions of the Safari browser that fix a binary planting vulnerability our company has reported to them in March this year under our then-effective disclosure policy. (See Apple's and our own advisory.)

In the last 20 days since the binary planting monster escaped to the wilderness, eager bug-hunters were focused on unsafe loading of libraries, and understandably so: free tools were made available, and instructions were published on how to use monitoring software like Sysinternals' Process Monitor for detecting unsafe library loadings. As it turned out, tools + instructions + 20 days = 117 remotely exploitable vulnerabilities (at the time of this writing). The list is growing and will likely surpass our own list of 396 DLL planting and 127 EXE planting vulnerabilities at some time.

As we've already hinted, the search path problem does not only affect DLLs, or more accurately, LoadLibrary* functions. Indeed, this problem also affects the way Windows processes are launched via various functions such as CreateProcess*, ShellExecute*, WinExec, LoadModule, _spawn*p* and _exec*p*. (Asterisks denote various characters to avoid listing too many function names.) And if you thought the library-loading search path was dangerous, you'll probably be surprised about the (less documented) search paths for loading executables.

Let's revise the library-loading search path, as used by the LoadLibrary* functions.

LoadLibrary* search path

1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable

It is obvious from this search path that a binary planting vulnerability can only occur when the requested library - specified without a path - is not found in the first four locations. This means, and our research confirms it, that most DLL planting issues will result from trying to load a library that doesn't even exist on the system (with a few exceptions). This nicely explains what we dubbed the "dwmapi.dll phenomenon": many Windows applications written for both XP and Vista/7 execute LoadLibrary("dwmapi.dll") to see if Vista Desktop Window Manager API is available. While on Vista/7 this DLL is found in system directories, it isn't on XP, leading to dwmapi.dll being loaded from the current working directory. Interestingly, our research has also found opposite cases where an application is only vulnerable on Vista or 7, but not on XP or older Windows systems.

Now let's look at the various search paths Windows are using for launching executables. In contrast to the LoadLibrary* search path, many of these aren't officially documented but can easily be observed with a file/process monitor.


CreateProcess*, WinExec and LoadModule search paths

1. The directory from which the application loaded
2. Current working directory
3. 32-bit System directory (Windows\System32)
4. 16-bit System directory (Windows\System)
5. Windows directory (Windows)
6. Directories in the PATH environment variable

This search path is identical to the old search path used by LoadLibrary* functions before the "safe search order" was introduced years ago. Apparently the current working directory is in the second place, which means that when an application tries to launch the Windows Calculator by calling something like CreateProcess(NULL,"calc.exe",...), a malicious calc.exe lurking in the current working directory will get launched instead. And remotely, too, if the current working directory happens to point to a remote network share in a local network or on Internet. And no, launching remote executables using these functions will never issue any security warnings to the user, in contrast to ShellExecute*. As far as we know, introducing ShellExecute-like security warnings to these functions would cause serious problems with various batch jobs and server back-end operations running without humans present.

ShellExecute* search path

1. Current working directory
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Directories in the PATH environment variable
6. Directories specified in the App Paths registry key

Now this search path could not be friendlier to your binary planting attacker: the current working directory, possibly under attacker's control, is the first location consulted for the executable launched via a ShellExecute(NULL,"open","cmd.exe", ...) call. Fortunately though, Windows will issue a security warning when launching an executable from the Internet zone (but not from Local Intranet and My Computer zones). So for those of you who believe that users won't okay such warning the second time around after seeing that canceling it the first time failed to get them where they wanted to go, feel free to consider the ShellExecute binary planting vector intranet- and local-only.

_spawn*p* and _exec*p* search paths

1. Current working directory
2. 32-bit System directory (Windows\System32)
3. Windows directory (Windows)
4. Directories in the PATH environment variable

These functions, while probably used less frequently than CreateProcess* or ShellExecute*, provide a powerful binary planting potential: Trying to launch Notepad by calling _execlp("notepad.exe","r") will result in executing a malicious notepad.exe waiting in the current working directory, without a security warning under any circumstances.

There are many other ways to launch new processes in Windows, but most are likely to be wrappers for CreateProcess* or ShellExecute* functions, making their binary planting potential equal to that of their "wrapees".

So what have we learned today? First, binary planting is as much a problem with EXEs as it is with DLLs. Second, while DLL planting usually requires the DLL to be absent from the system, EXE planting works nicely with existing executables in system directories. And third, an application can be vulnerable depending on the version of Windows it is running on. Now make sure to test your applications on different Windows systems and update your Process Monitor filters to look for executables being loaded from the current working directory.

Are there any systemic countermeasures you can apply against EXE planting? Unfortunately not as many as for DLL planting:

• Microsoft's CWDIllegalInDllSearch hotfix only blocks the current working directory in LoadLibrary* calls, so it can't protect you or your applications from EXE planting attacks. According to this guidance, "Microsoft recommends that developers be careful when loading binaries and specify the fully qualified path name. This should pose less complexity when loading a binary as opposed to a library."
• The SetDllDirectory function also only affects LoadLibrary* calls. There is no SetExeDirectory function available at this time to change the search path of CreateProcess, ShellExecute and other process-launching functions.
• Changing the current working directory to some safe location either at the beginning of the application's execution or before loading libraries and launching processes can limit the exploitability of both DLL and EXE planting vulnerabilities. (However, applications tend to change their current working directory even if the developer had no intention for them to do so; but more about this in another blog post.)

P.S.: And don't forget to test your computer for exposure to binary planting attacks with our Online Binary Planting Exposure Test.