DLL hijacking - what are you doing ?

Published: 2010-08-29. Last Updated: 2010-08-29 22:38:28 UTC
by Swa Frantzen (Version: 1)
10 comment(s)

In response to the heavy publication in the press about the DLL hijacking vulnerabilities, Microsoft released a number of publications and even a tool of their own.

Judging from the comments on the article by Bojan and the difficulty in reading the instructions and the lack of a clear recommended value that stops the current ongoing attacks without breaking commonly used software packages, it's clear there is still some work ahead of us.

Not only do we need to understand it in detail and understand what we can block, but we need to test it all as well.

So, in a spirit of sharing how to make it work:

  • What are you using as mitigation against the DLL hijacking vulnerabilities ?
  • What did your tests with the different values and commonly used software packages (such as Microsoft Office) yield with the different values the tool supports ?

--
Swa Frantzen -- Section 66

Keywords: msft patches
10 comment(s)

Comments

Not as much as I should be doing. I did some initial tests and determine that 0xFFFFFFFF was a deal breaker. When the first app I tested (Outlook 2003) broke, I realized that deploying 0xFFFFFFFF was going to take a huge amount of work in terms of coming up with app-by-app patches (i.e. AppPath, adjusting the value per-app, etc.), and given the amount of work involved in validating, coming up with the workarounds, packaging, testing, and deploying, I threw up my hands (since I'm the only one here who can do any of that, and there are probably at least 200+ apps that would require testing).

My comments about the inability to simultaneously block SMB and WebDAV without blocking local hard drive access don't seem to have gone anywhere (at least, I don't know of anyway to tell Microsoft that the absence of a 0x00000003 option for the registry value is a serious misstep). I've been sort of hoping that Microsoft would recognize that and release an updated variant of 2264107.

At this point, I'm in the position of either facing a monumental undertaking to figure out how to implement 0xFFFFFFFF or of deciding which is the most likely attack vector, SMB or WebDAV. I can't turn of the Web Client service because of SharePoint, so I can't block attacks via WebDAV that way. So I have to pick which gate to guard, and I have a less than 50% chance of guessing right (since the attacks to come might exploit both).

I'm leaning towards defending against SMB since I figure it will be harder for a worm to spread against WebDAV sites since it won't have the easy trail of mounted drive letters to follow to find shared WebDAV sites to infect. But since attackers have the benefit of my analysis, I clearly can't choose the wine in front of them (obligatory reference to The Princess Bride - see http://www.imdb.com/title/tt0093779/quotes and scroll down to the part about poison)!

With that in mind, my plan (as soon as I have some time) is to do a reasonable amount of regression testing on our machine build procedures with the SMB defense in place (since our machine build procedures do software installation over SMB and there may be some setup.exe programs that have issues) and then flip the switch on SMB defense. But I really wish I could defend against both the SMB and WebDAV vectors without breaking apps that rely on Cwd for local DLLs (hint, hint, hint, Microsoft).

Anonymous

Aug 29th 2010
1 decade ago

According to the updated Microsoft KB article ( http://support.microsoft.com/kb/2264107 ), setting 0x00000002 blocks remote sources (WebDAV and UNC (including SMB)). Has your testing indicated otherwise?

thewizard75

Aug 29th 2010
1 decade ago

Installed KB22641107 on all the systems on the internal network, used GPO security entry to kill the WebClient service and PolicyEditor extension to set the CWDIllegalInDllSearch registry entry to 0x00000002 as 0xffffffff will break some vital stuff. We block SMB traffic egress anyway.

Hopefully, this locks down any remote web based attacks.

The ones that worry me are zip files coming in and bringing in a DLL to be loaded through whatever subterfuge would be used to get a user to load them. Archives get quarantined as a matter of course as the initial attack with them gets through Postini's virus scan and to a much, much lesser extent, our internal virus scan.

Sean

Aug 30th 2010
1 decade ago

Missed that revision! Hallelujah! Will carry forward with 0x00000002. I've only tested SMB (a three line Perl script to load a copy of user32.dll renamed foo.dll as a demonstration).

Anonymous

Aug 30th 2010
1 decade ago

I'm using Software Restriction Policies and AppLocker for protection against this, like with the shortcut vulnerability last month. Haven't tested, but it ought to work against this DLL issue as well, provided that the policies are set to apply to all executable files including libraries. My SRP/AppLocker policies only allow execution from Program Files and Windows folders, everything else is denied, including network shares. That should prevent any malicious DLLs from being loaded from network shares. As a further precaution, WebClient service is disabled because no one here needs it for anything, and disabling it should prevent exploits via WebDAV even if SRP couldn't stop that. I haven't actually applied the patch to change the search path, because required software like Chrome and Outlook break if the current directory is removed from the search path.

BTW, if anyone has tested SRP/AppLocker against a WebDAV exploit of this DLL hijacking / binary planting issue, let us know what happened. I'm not sure if WebDAV is covered by SRP.

Erno

Aug 30th 2010
1 decade ago

The way that I understood http://support.microsoft.com/kb/2264107 "0x2" will not provide any protection if a vulnerable app is called from a WebDAV folder (like Metasploit does). Is this correct?

Joe

Aug 30th 2010
1 decade ago

I am confused about why this is presented as a new issue that occurs when an app is started via a file association and the app uses LoadLibrary. Wouldn't this happen anyway, is a dll is planted? And wouldn't it happen anyway if the dll was loaded implicitly via linking to an import library?

Anonymous

Aug 30th 2010
1 decade ago

Joe: The original version of kb2264107 did seem to indicate that 0x2 did not provide any protection from the WebDAV vector. However, the KB was updated. The scenario is now more complicated,but if the program is installed in a local folder, then 0x2: Blocks a DLL Load from the current working directory if the current working directory is set to a remote folder (such as a WebDAV or UNC location).

I have not personally tested this, however.

thewizard75

Aug 30th 2010
1 decade ago

In the meantime MS released a "Fix it" -ehm- solution for setting CWDIllegalInDllSearch to "0x2". See also http://blogs.technet.com/b/msrc/archive/2010/08/31/update-on-security-advisory-2269673.aspx

Ottmar Freudenberger

Sep 1st 2010
1 decade ago

Thanks thewizard75 for the info. In my tests I was so far not able to get a custom dll loaded via metasploit via a proxy. So, it seems like vanilla XP SP3 clients will always try to connect to a WebDAV share on the internet directly via Port 80, ignoring the IE proxy settings. Even when I connected the metasploit WebDAV folder as a lokal drive with the NetDrive tool that allows me to specify a proxy, the dlls did not load.

Joe

Sep 2nd 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives