40 to 220 Windows EXE's Vulnerable to Remote Code Execution (So Far)

Security researchers estimate that between 40 and 220 applications are vulnerable to a remote code-execution attack on Microsoft Windows that exploits a bug in the way that programs load binary files, in a move that is trivial to pull off.

H D Moore, the Chief Architect and CSO of Metasploit has said that the flaw is in the way that Windows loads “safe” file types from remote network locations, but however said that he was not authorised to provide any more details at this stage.

This vulnerability is nearly identical to one discovered in iTunes last week, and although iTunes for Windows and VMWare Tools have been patched, many more applications could be waiting for some time for a patch, as each piece of software does have to be individually taken care of.

ACROS Security notified Microsoft of this bug four months ago, and have been working with Microsoft and various vendors ever since, in an effort to patch it.

This so-called “binary planting bug” allows attackers to run remote code on Windows machines by getting iTunes to open a file located in the same network share as a custom-coded malicious DLL file. According to ACROS Security, the firm who tested 220 applications to be vulnerable so far, all that has to occur is that a DLL has to have a specific name, and be in the same network share as the media file, which the end-user is then convinced to play.

The reason remote attacks over the internet are possible is due to the fact that Windows Systems by default have the Web Client service running, which enables Network Shares to be accessible via WebDAV, and provided the firewall allows outbound HTTP traffic, remote network shares can be accessed.

For Internet-based attacks, H D Moore has suggested a fairly obvious fix: block it. Simply block outbound SMB on 445 and 139, as well as WebDAV, and you should be safe from Internet based attacks. It’s possible though that you may still be susceptible to LAN based attacks.

UPDATE:

H D Moore painted a slightly different picture about Acros Security's response on the Rapid7 blog. He received this reply from them via email when he asked if they would like to co-ordinate on vulnerability disclosure:

I don’t know if you saw the draft of our new commercial disclosure policy, but we essentialy gave up on alerting vendors for free. We’ve been providing free research to them for over 10 years and it hasn’t paid out well. What you’re seeing on Bugtraq now are the “remains of the old days,” so to speak :-) We’ve found better markets for this kind of information. To answer your specific question: no, we have not reported any issues in the products you mentioned – and have no intention to, should we come across one. So if your goal is to get credited for alerting them, you have nothing to worry about. I hope it pays off for you. As for the public status of this class of problems, it has been public for at least 10 years now (see the “ancient” NSA Windows NT security guide) and some developers were obviously not aware of it.

Moore also had the following "factlets" of information about the vulnerability:

1. To exploit this vulnerability, an attacker must convince their victim to open a file from a directory they control. This can be an extracted archive, a USB key, or a network share using SMB or WebDAV. The file the user opens is not malicious nor does it have to have specific content to trigger the vulnerability. The audit kit  uses a local directory to test for the issue and the generated proof-of-concept files can load from a local or remote directory.

2. In most cases, the user must first browse to the directory, then double-click the specific file for this exploit to trigger. Embedding this link into an OLE document or direct linking to the UNC path of the affected file type will not change the working directory to the share prior to opening it. For example, a link to \\server\documents would lead to code execution if the user opened a file from this directory, but a direct link to \\server\documents\somedocument.ext would not trigger this issue. There are some exceptions, but these tend to be application-specific problems and the  general rule still applies.

3. In the case of a network share, a  DLL  does not be visible within the directory listing for this to be  exploitable. The Metasploit module will list the affected file type but the DLL itself is not shown,  since it is generated on the fly when requested by the vulnerable application. This  can lead the user to believe that a safe document type in an otherwise empty network share is safe to open.

4. If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will  be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from  within this sub-directory.

5. Detecting a vulnerable application requires more validation than just watching for an attempt to access a DLL in the current directory. Many applications will call rundll32 to load the DLL in question and this will result in a file access in the working directory, even though the DLL may not actually be loaded. Some applications load executables and configuration files from the current directory, so any audit needs to account for non-DLL file access as well.