DLL hijacking - what are you doing ?
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
×
Diary Archives
Comments
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
thewizard75
Aug 29th 2010
1 decade ago
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
Anonymous
Aug 30th 2010
1 decade ago
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
Joe
Aug 30th 2010
1 decade ago
Anonymous
Aug 30th 2010
1 decade ago
I have not personally tested this, however.
thewizard75
Aug 30th 2010
1 decade ago
Ottmar Freudenberger
Sep 1st 2010
1 decade ago
Joe
Sep 2nd 2010
1 decade ago