Details emerge on new DLL load hijacking Windows attack vector

Metasploit's HD Moore has released technical details on a severe application DLL load hijacking problem that haunts more than 40 Windows software programs.

Moore (right), who stumbled on the issue while researching the recent LNK zero-day flaw, has released an audit kit that can be used to identify affected applications on a particular system.

"The audit kit should make it easier for other folks to identify vulnerable applications and hopefully have them addressed by the vendor," Moore said in a blog post.

Essentially, if you open a file type associated with [a vulnerable app] from a remote network share, the application will also try to load one more DLLs from the share, Moore explained. Even if the file that the user opened is completely safe, a malicious DLL can be supplied that will lead to code execution.

Interestingly, a variant of this problem has been known for a very long time and had been discussed publicly by academic researchers [.pdf] and hackers Thierry Zoller and Aviv Raff.

Moore has been in touch with Microsoft to discuss his findings and the company said it will offer some public information and guidance about the vulnerability later today.

[SEE: HD Moore: Critical bug in 40 different Windows apps ]

Here are some quick facts about this class of vulnerabilities:

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.

This isn't a problem that can simply be fixed with a security update from Microsoft.  According to Moore, every affected vendor will need to release a product update to completely patch this issue.

However, he offers some temporary workarounds that can help to blocking attacks:

• Block outbound SMB at the perimeter. Every organization should be doing this already, as this also prevents SMB Relay attacks and NTLM hash harvesting.
• Block outbound WebDAV at the perimeter. This is tricky to do unless you force your users to go through a HTTP proxy. Blocking the PROPFIND HTTP method should be enough to prevent this exploit and ones similar to it from working.
• Disable the “Web Client” server on all of your desktops through group policy. This is a prudent decision for most enterprises and removes the need to put a PROPFIND filter in place for outbound WebDAV traffic.