Last updated at Wed, 26 Jul 2017 15:45:30 GMT
This post discusses the DLL loading vulnerabilities covered in the news last week. For technical information about the flaw and how to test for it, please see the Metasploit Blog.
Last Thursday, Acros, a Slovenian security firm, published an advisory that identified what they call a "binary planting" flaw in iTunes. Essentially, if you open a file type associated with iTunes from a remote network share, iTunes will also try to load one more DLLs from the share. Even if the file that the user opened is completely safe, a malicious DLL can be supplied that will lead to code execution.
While working on the Windows Shortcut exploit, I stumbled on this class of bugs and identified a couple dozen applications that seemed to be affected by this problem. iTunes was one of these applications and the details in the Acros advisory made it clear that this was indeed the same flaw. I was planning to finish the advisories and start contacting vendors on August 20th (last Friday). The Acros advisory on the 18th threw a wrench into this process.
I contacted Acros and asked whether they were aware that this problem affected other applications and whether they would like to coordinate the disclosure process. The reply is quoted below.
"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."
The reply from Acros made it clear that they were not working with the vendors nor did they have any intention of doing so. Acros is also claiming to have applied for a patent on methods for discovering these vulnerabilities. In the same post, they also claim to have been sitting on these issues since November of 2008. I contacted the folks at Microsoft to give them a heads up about the issues that I found and asked what their plans were to address them. Microsoft indicated that they were aware of the flaws, but were still working on a KB article and guidance information for affected vendors. At least four of Microsoft's own applications have been confirmed as exploitable through this vector, two of which were already being addressed by the time I contacted them.
Rapid7 is committed to a Vulnerability Disclosure Policy that is fair to both vendors and customers seeking to use their technology securely. However, at this point, I feel that the cat is firmly out of the bag. I wasn't the only person to know about these flaws before the Acros advisory was made public. Earlier this year, Taeho Kwon and Zhendong Su published a paper titled Automatic Detection of Vulnerable Dynamic Component Loadings. This paper covers this exact issue and enumerates a large number of affected applications. While this paper focuses on archive files and Carpet Bombing attacks, the same methodology also applies to remote network shares. Over the weekend, Thierry Zoller published a blog entry that describes the underlying issue and indicates that Photoshop is one of the vulnerable applications. As Thierry notes, a variation of this bug was originally published in 2000 by Georgi Guninski. The biggest difference is that the new issues mostly apply to applications where the hijacked DLL does not exist in the system directory (application-specific libraries).
As a compromise between releasing the full list of affected products and not saying anything at all, I decided to push a generic exploit module to the Metasploit Framework and release an audit kit that can be used to identify affected applications on a particular system. At this time, the exploit will not work unless you manually specify a vulnerable file type. The audit kit should make it easier for other folks to identify vulnerable applications and hopefully have them addressed by the vendor. Metasploit Express will receive an update on Wednesday with support for this generic exploit module. More information about the audit kit and the exploit module can be found in this Metasploit blog entry.
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.
Every affected vendor will need to release a product update to completely patch this issue. There are some workarounds that can be put in place in the short-term and these will have a side effect of blocking similar exploits in the future.
a) Block outbound SMB at the perimeter. Every organization should be doing this already, as this also prevents SMB Relay attacks and NTLM hash harvesting.
b) 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.
c) 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.
We expect to see additional guidance from Microsoft today and will update this post when that information becomes available.
Update. Microsoft has released a security advisory that discusses the flaw and possible workarounds. The MSRC blog has additional information about the advisory and the SRD blog has a link to the KB article and a tool that administrators can use to mitigate the problem today. The KB article is not quite up yet, but will be at this URL. For more information on dynamic link library security, please see this MSDN page.
