Tuesday, August 24, 2010

It's those darned DLLs again...

There's been a lot (and I mean a LOT) of traffic on the interwebs lately regarding a vulnerability associated with how DLLs are loaded on Windows systems. In short, the idea is that due to how applications look for DLLs that aren't explicitly defined by their path, and how the current working directory can be defined (includes how an application is launched), the application can end up loading a malicious DLL that is in a non-traditional directory.

First, some background/references:
DLL Search Order Vuln (circa 2000)
MSDN DLL Search Order article
ACROS Security's recent announcement
Recent Mandiant blog post (author: Nick Harbour)
SANS ISC blog post (author: Bojan Zdrnja)
ComputerWorld article
Register article (UK)
Rapid7 blog post (author: HD Moore)
Metasploit blog post (author: HD Moore)
SecDev blog post (author: Thierry Zoller)
MS Research and Defense blog
MS Security Advisory 2269637
MS KB Article 2264107 (includes a Registry change)

This was originally something that was pointed out 10 years ago...the new twist is that it has been found to work on remote resources. MS has issued instructions and guidance on how to properly use the appropriate APIs to ensure the safe loading of libraries/DLLs. However, this, combined with the findings from ACROS and others (see the paper referenced in HD's Rapid7 blog post), pretty much tells us that we have a problem, Houston.

The DLL search order vulnerability is a class of vulnerability that can be implemented/exploited through several avenues. Basically, some mechanism needs to tell an application that it needs to load a DLL (import table, Registry entry, etc.) through an implicit (i.e., not explicitly defined) path. The application will then start looking for the DLL in the current working directory...depending on how this exploit is implemented, this may be the directory where the application resides, or it may be a remote folder accessible via SMB or WebDAV. Therefore, the application starts looking for the DLL, and as there is no validation, the first DLL with the specified name is loaded. One thing to keep in mind is that the DLL cannot break required functionality needed by the application, or else the application itself may cease to work properly.

Okay, so what does all of this mean to forensic analysts? So some user clicks on a link that they aren't supposed to and accesses a specific file, and at the same time a malicious DLL gets loaded, and the system becomes infected. Most often, forensic analysts end up addressing the aftermath of that initial infection, finding indications of secondary or perhaps tertiary downloads. But what question do customers and regulatory bodies all ask?

How was the system originally infected?

What they're asking us to do is, to do a root cause analysis and determine the initial infection vector (IIV).

Some folks may feel that the method by which the DLL is designated to load (import table, file extension association, etc.) is irrelevant and inconsequential, and when it comes to a successful exploit, they'd be right. However, when attempting to determine the root cause, it's very important. Take Nick's post on the Mandiant blog, for example...we (me, and the team I work with) had seen this same issue, where Explorer.exe loaded ntshrui.dll, but not the one in the C:\Windows\system32 directory. Rather, the timeline I put together for the system showed the user logging in and several DLLs being loaded from the system32 directory, then C:\Windows\ntshrui.dll was loaded. The question then became, why was Explorer.exe loading this DLL? It turned out that when Explorer.exe loads, it checks the Registry for approved shell extensions, and then starts loading those DLLs. A good number of these approved shell extensions are listed in the Registry with explicit paths, pointing directly to the DLL (in most cases, in the system32 directory). However, for some reason, some of the DLLs are listed with implicit paths...just the name of the DLL is provided and Explorer.exe is left to its own devices to go find that DLL. Ntshrui.dll is one such DLL, and it turns out that in a domain environment, that particular DLL provides functionality to the shell that most folks aren't likely to miss; therefore, there are no overt changes to the Explorer shell that a user would report on.

Yes, I have written a plugin that parses the Registry for approved shell extensions. It's not something that runs quickly, because the process requires that the GUIDs that are listed as the approved shell extensions then be mapped to the CLSID entries...but it works great. This isn't as nifty as the tools that Nick and HD mention in their blog posts, but it's another avenue to look to...list all of the approved shell extensions listed with implicit paths, and then see if any of those DLLs are resident in the C:\Windows directory.

Again, there's a lot of great information out there and a lot to digest with respect to this issue, but the overarching issue that I'm most interested in now is, what does this mean to a forensic analyst, and how can we incorporate a thorough examination for this issue into our processes? Things that forensic analysts would want to look for during an exam would be the MRU lists for various applications...were any files recently accessed or opened from remote resources (thumb drives, remote folders, etc.)? If there's a memory dump available (or the output of handles.exe or listdlls.exe) check to see if there are any DLLs loaded by an application that have unusual paths.

Some of the issues you're going to run into is that you may not have access to the remote resource, and while you may see indications of a file being accessed, you won't have any direct indication that a DLL was in the same folder. Or, if the vulnerability was exploited using a local resource, AV applications most likely are not going to flag on the malicious DLL. In some cases, a timeline may provide you with a sequence of events...user launched an application, remote file was accessed, system became infected...but won't show you explicitly that the malicious DLL was loaded. This is why it is so important for forensic analysts and incident responders to be aware of the mechanisms that can cause an application to load a DLL.

One final note...if you're reading MS KB article 2264107, you'll see that at one point, "CWDIllegalInDllSearch" is referred to as a Registry key, then later as a value. Apparently, it's a value. Kind of important, guys. I'm just sayin'...

I've written a plugin that checks for the mentioned value, and updated another plugin that already checks the Image File Execution Options keys for Debugger values to include checking for this new value, as well.


Macaroni said...


Great post and what a wealth of information on the dll search order subject with the other various links you posted.

I agree that we are asked to quite often comment on initial infection vector (IIV) but one thing I wanted to note here is the malicious dll in question had to get placed on the system in the first place some way. This dll search order is most likely the way the malicious dll get lauched, but not necessarily the way it got on the system. The dll search order could be a method of persistence or a way for the attacker to get the user to launch the malware.

Again great post on the subject.

Corey Harrell said...

So far I have been unable to find this information...

Does an application get cached locally if it is opened from a remote location? I am curious if the application and possibly the DLL would be cached in the temporary files folders if the user opens an application on a network share which uses this attack vector.

H. Carvey said...


With respect to ntshrui.dll, you're correct. However, particularly with remote resources accessible via SMB and WebDAV, this could provide the IIV, particularly if the malicious DLL provides a downloader capability.

Something to keep in mind...thanks for your comment!

H. Carvey said...


I'm not 100% sure I see how your question applies, but I'd think that it would depend on how that application is accessed.

Corey Harrell said...

After reading your blog post I was trying to think about what artifacts could possibly be left on a system. For the attack to be successful it requires an application to load a malicious DLL and as you stated the new twist to this attack is it can be done remotely. When a DLL gets loaded remotely on system through SMB or WebDav does it just run in memory without touching the hard drive or does it get downloaded to the local system in order to be executed? This is why I was asking if it gets cached on the local system.

I apologize that my initial question was not clear. Thank you for the post and taking the time to answer my question.

H. Carvey said...


What threw me was, "Does an application get cached locally..."; in the examples discussed in some of the resources, the applications appear to be installed locally on targeted system.

To answer your question, the DLL would likely get loaded in memory, hence the vulnerability. However, as to caching, I'd think that you'd have to look at the method used...I'm not aware that accessing a file via an SMB share caches that file locally. If memory serves, opening a Word doc from a remote share will cause the temp files created during the editing process to be created on the share (as opposed to locally; please correct me if I'm wrong on this). As to web-based access, I know that WinInet/UrlMon APIs perform caching...but I'm not clear on how WebDAV operates, to that level.

Good questions!

echo6 said...

Nice article Harlan, not exactly a new exploit. It has been known for sometime although as you say it is now getting a lot of attention.

Incident responders need to be aware also that the tools they are using may be vulnerable!

I must admit I'm dismayed by Acros' response when reading hdm's post http://blog.rapid7.com/?p=5325 Hopefully this is not a trend that security firms are going to follow, I think hdm has it right though " the cat is out of the bag".

H. Carvey said...

Incident responders need to be aware also that the tools they are using may be vulnerable!

Jon, apply that to the situation at hand...I have a sense of what you mean, but elaborate on that a bit, and how it affects incident responders.


Anonymous said...

Does anyone have a screenshot of CWDIllegalInDllSearch setup that works?

echo6 said...

Harlan, simply put. IR tools will often utilise DLLs/APIs to enumerate running system state. We discussed static binaries in another post some time ago. Difficult in the Windows environment, perhaps including a trusted DLL in your IR tool kit is a good idea. Now seemed like a good time to remind investigators :)

H. Carvey said...


I don't see how that applies here. Are you suggesting that bad guys are now going to hack responder's IR CDs?

echo6 said...

No, they don't have to, just the DLLs on the Operating System being subject of examination! Although not forgetting some people deploy their tools from USB! e.g. look what has happened to COFFEE, but I digress.

Say for example you use fport.exe as one of your IR tools.

Using something like dependency walker, http://www.dependencywalker.com/, I can see that fport requires functions from various system DLLs.

Probably a bad example because most of those DLLs would be replaced by the Windows File Protection system (you would hope!) and the search order may be such that it can't be subject to tampering.

On the other hand, depending on the search order of the IR tool, I could include a trusted DLL with my IR tool on the CD :)

Sorry perhaps I didn't make myself clearer earlier. Does this make sense?

H. Carvey said...


I'm still not following...

I deploy my IR tool kit on a CD or USB thumb drive...I connect it to the system, and run my tools. If the required DLLs aren't in memory, then the DLL search order kicks in. If I don't include the required DLLs on the CD or thumb drive, then the OS looks in the system32 dir.

Now, it's relatively trivial to replace DLLs protected by WFP...however, if that's the case, it's game over anyway, and the output from your tools may reflect that (missing data from netstat, for example).

However, the overall issue related in the post is systems being compromised via this vector; as in the ACROS Sercurity post, a file of interest is located on a remote resource accessible via SMB or WebDAV, and the user clicks on it...as the application (iTunes, etc) loads, it looks in the remote resource for specific DLLs.

In this sense, I'm still not seeing how your comment regarding responders knowing how their tools operate applies. Yes, I do see how it applies in the general sense, particularly regarding the DLL search issue, but my post was directed more at (a) the exploit and (b) how analysts would determine the IIV.