Details emerge on new DLL load hijacking Windows attack vector

Details emerge on new DLL load hijacking Windows attack vector

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

SHARE:
TOPICS: Security, Windows
34

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.

follow Ryan Naraine on twitterEssentially, 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.

Topics: Security, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

34 comments
Log in or register to join the discussion
  • RE: Details emerge on new DLL load hijacking Windows attack vector

    Just too darn hard to exploit this.
    Loverock Davidson
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Loverock Davidson

      Yes, it will include a little social engineering, but it seems that a lot of apps are behaving poorly. This seems to be a legitimate systemic problem.
      honeymonster
      • RE: Details emerge on new DLL load hijacking Windows attack vector

        @honeymonster
        Sounds like it will take a lot of social engineering. Just getting someone to click on a network share or remote link will be quite challenging.
        Loverock Davidson
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Loverock Davidson

      Perhaps you should learn how to use Windows, just the basic stuff... it would be educational for you.
      B.O.F.H.
      • RE: Details emerge on new DLL load hijacking Windows attack vector

        @B.O.F.H.
        Done. Next?
        Loverock Davidson
      • RE: Details emerge on new DLL load hijacking Windows attack vector

        @Loverock Davidson

        And yet you find clicking on a network share or remote link will be quite challenging. Perhaps you should go and review the basic stuff again.
        B.O.F.H.
  • Poor decision on MSs part

    Including "current directory" in the library search path was a poor design decision, one I cannot see the reasoning behind (except for a stupid attempt at allowing side-by-side versioning).<br><br>MS should just drop "current directory" searching. Yes, some legacy apps may break (poorly designed ones). They could then be fixed simply by modifying the PATH variable to include ".". Of course, this would bring us back to this situation, then those who do that should then know how to block against these attacks at the perimeter.<br><br>That some applications will try to load DLLs from the same location they opened a media file (or something else) is just plain stupid.<br><br>Really, Windows should refuse to load DLL's across the network (even LANs) <i>unless</i> the original executable (i.e. <u>not</u> document or file) was <i>also</i> loaded from that same location.
    honeymonster
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @honeymonster

      "A new CWDIllegalInDllSearch registry entry is available to control the DLL search path algorithm":

      http://support.microsoft.com/kb/2264107.
      Earthling2
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @honeymonster

      Completely agree that this should be the default behaviour in that Dll's should expressly be denied loading from a remote location.

      A design decision equally stupid as allowing autoexec from portable media.

      Next MS will be touting no locks on your car when you park it in the Bronx as a great usability feature just in case you forget your keys.
      Alan Smithie
  • A Windows-ONLY Problem!

    This is obviously a Windows-Only problem. As anyone with sufficient technical education knows, DLLs run only on Microsoft Windows. In fact, a typical MAC OS X workstation will contain NO DLL files. Here is command-line proof if you doubt me (for whatever reason...):<br><br>mac:~ $ find / -name "*.dll" -print<br>mac:~ $<br><br>Since OS X doesn't use DLLs or anything resembling them, such a problem never could possibly apply to MAC. Once again, Apple users never have any reason to worry about computer security. Never. Never will, either.
    Trolleur
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur Bien, ?videmment vous ?tes un gar?on tr?s amer et jaloux de ventilateur de M$.
      I12BPhil
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur - you a silly boy...
      to alter your example... i wouldn't expect to find a Ford starter in a Chevy. your attempted point is exceedingly dull - as in pointless.
      BitBanger_USA
      • RE: Details emerge on new DLL load hijacking Windows attack vector

        @BitBanger_USA <br><br>He is called "Trolleur" for a reason. I bet he gets off reading people's replys to his flamebait. <br><br>The classic MO of a narcissist.
        betelgeuse68
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur
      Interesting Apple don't agree with you,
      "Security Advice
      The Mac is designed with built-in technologies that provide protection against malicious software and security threats right out of the box. However, since no system can be 100 percent immune from every threat, antivirus software may offer additional protection."
      http://www.apple.com/macosx/security/
      dvm
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur,

      Mac has the same concept of dynamically linked libraries using Objective-C. The idea that any computer operating system is immuned to security vulnerabilities is delusional.
      bmonsterman
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur

      find / -name "*.dylib" -print
      rpmyers1
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur

      Do shut up, you arrogant fool.
      Hallowed are the Ori
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Trolleur <br><br>Not really. Here is a link to apple documentation. Pay special attention to the section titled "The Library Search Process" and the words "process working directory".<br><br><a href="http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW10" target="_blank" rel="nofollow">http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW10</a><br><br><i>When the library name is a filename (that is, when it doesnt include directory names), the dynamic loader searches for the library in several locations until it finds it, in the following order:<br><br>1. $LD_LIBRARY_PATH<br>2. $DYLD_LIBRARY_PATH<br>3. <b>The processs working directory</b><br>4. $DYLD_FALLBACK_LIBRARY_PATH<br></i>
      Earthling2
  • OK Windows Folks. What now? Are you getting tired of this?

    You've been bitten this time by a much bigger exploit which spans across multiple apps.<br><br>I've made the case on multiple occassions that Windows' security model is defective in that the kernel does not police itself, or these DLL injections would never be happening with impunity.<br><br>The key difference between Linux and Windows is that keen insight went into the decision making process and design to include LSM, which is a way to have cross-checks on each granular activity taken by an 'App' and, this is important, the 'kernel'.<br><br>That's right, the kernel is inspected and if anything departs from predefined profile permissions, then LSM will step in with a deny for the action taken.<br><br>There are several LSM modules, one of which is called AppArmor and is installed by default with Ubuntu Lucid Lynx 10.04 LTS. Included in the default profiles found in /etc/apparmor.d/ can be found usr.bin.firefox.<br><br>While this profile is not enabled by default, one can enable it with this short command:<br><br>$sudo aa-enforce /etc/apparmor.d/usr.bin.firefox<br><br>and from that point forward Firefox will be sandboxed by AA and guarantee that no exploit can ever compromise your system.<br><br>You can of course compromise any system, including Linux, if you 'willy nilly' go onto the internet and install that special 'game' you like so much (with a nice trojan payload). There is no excuse for downloading any executable without first certifying it against an SHA checksum provided by the vendor who developed the software. Caveat Emptor.<br><br>So Folks, I'll say it here again, you cannot be guaranteed of your safety using Microsoft Windows 7. The Zero-Day exploits just keep flowing into ZDnet and there is no end in sight.<br><br>You can however take control of your own destiny by making a personal decision to put a replacement operating system in place that will assure that your Internet access will be safe and worry-free.<br><br>Make a decision today. Switch to Ubuntu Linux.<br>Ubuntu Linux is the safest operating system on the Planet.<br><br>I stake my reputation on it.

    [b][Edit] P.S. You don't need to throw away the baby with the bath water--simply make Ubuntu Linux your base system and run Windows from either KVM or VirtualBox (the former being preferable as it is a Type 1 hypervisor).[/b]
    Dietrich T. Schmitz, ~ Your Linux Advocate
    • RE: Details emerge on new DLL load hijacking Windows attack vector

      @Dietrich T. Schmitz, Your Linux Advocate <br>So do you want us to move to that ugly Uglybuntu? Linux is crap, keep that with you. And I know you can't afford to buy Windows so stay with Linux and those who can afford will stick with Windows and enjoy office too; uggh now don't remind me of ugly openoffice crap
      shellcodes_coder