DLL Hijack Vulnerability

Courtesy: ZDNet

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.

From ThreatPost,

According to the advisory, all a remote attacker has to do is plant a malicious DLL with a specific name on a network share and get the user to open a media file from this network location in iTunes – which should require minimal social engineering.

Since Windows systems by default have the Web Client service running – which makes remote network shares accessible via WebDAV -, the malicious DLL can also be deployed from an Internet-based network share as long as the intermediate firewalls allow outbound HTTP traffic to the Internet.

From Rapid7 Security Blog

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.

More on the SMB Client from Technet:

Attack vectors

Unlike server-side vulnerabilities, an attacker cannot simply scan for vulnerable systems and then open connections to attack targets. For an attacker to exploit any of these issues they would have to force a SMB client to make a connection to a malicious server. In general this kind of attack is done in several ways:

  • E-mail containing links to external web or file servers. (The attacker lures the target into clicking a link and visiting the malicious server.)
  • Similar to above, but with messages sent via instant-messenger or social-networking services.
  • HTML e-mail or web-pages containing embedded links to malicious file serves. With some applications, these links may be automatically visited without user interaction.

In all cases, for an attacker on the Internet to be able to exploit these vulnerabilities, the target client machine must be able to make an outbound SMB connection to the malicious server. Firewall best practices recommend blocking outbound (and inbound) SMB traffic (TCP ports 139 and 445) at the perimeter firewall, preventing this attack from succeeding.

That leaves attacks originating from inside the local network (a.k.a. the intranet) – either from a malicious user on the network, or from a compromised machine that is being used as a pivot to reach other targets. In some cases, it may be possible for an attacker on the intranet to hijack legitimate SMB client connections for the purpose of carrying out attacks.  As mentioned above, an attacker may cause the Browser service on target computers to make a connection to a malicious SMB server on the local network, potentially without any user interaction.