DLL Hijacking Storm a Brewin'
10 September 2010
About three weeks ago a newly re-minted vulnerability class was announced on the Full Disclosure mailing list (http://seclists.org/fulldisclosure/2010/Aug/324). The class of vulnerability has actually been known to reverse engineers for a long time, but they used it to gain access to program flow to inspect existing code rather than for malicious purposes. In a nutshell the vulnerability hinges on the fact that some Windows programs will look for dynamic link libraries (DLL's) in their current working directory first before searching program and system directories.
DLL's are code libraries full of common functionality that could be useful to different executables. The idea is that you pull the common functions out of a piece of code so that it can be used by other programs. These libraries are then loaded into the executable at runtime. So a user clicks on a file, the executable program starts, and the first thing the program does is marshal resources (DLL's) that it needs. This becomes a problem if the program looks in dynamic locations for DLL's.
Some programs will check their current working directory for DLL's first before searching through other variable paths. If a program changes directories to the directory of the file it is attempting to execute, this could mean changing out of a system directory and into a user controlled directory. This could happen if you have a word.doc file and you click on it and Microsoft Word starts automatically to parse up the file for display (Microsoft Office was one of the first programs targeted by this class of vulnerability). Word might look for the DLL named msoffice.dll to link in the library for execution. If the word.doc file happened to be on a USB thumb drive along with a file called msoffice.dll, Word might accidentally load up this DLL instead of the C:\Program Files\Office11\lib\msoffice.dll that it is actually looking for. A clever attacker could embed some malicious code into the DLL on the thumb drive then cause it to load up the legitimate file. This would result in a user having the malicious code execute silently with the privileges of the application they were running.
There are four common attack vectors that have been discussed with respect to this vulnerability. These include a malicious DLL on a shared network drive, on a webdav drive, on removable media such as a thumb drive, or in an archive attached to an e-mail. Any of these would effectively delivery the DLL hijacking attack. The network drive and webdav drive are probably the most insidious and could be used by a worm to infect large numbers of users quickly, but these two vectors can actually be mitigated using a Microsoft registry tweak (http://blogs.technet.com/b/msrc/archive/2010/08/31/update-on-security-advisory-2269673.aspx). The e-mail archive and USB drive attack vector are pretty much impossible to protect against.
At this time there are a HUGE number of programs affected by this bug (http://www.exploit-db.com/dll-hijacking-vulnerable-applications/). New program vulnerabilities are being discovered almost daily. Metasploit has released tools to easily test (and exploit) vulnerable applications (http://blog.metasploit.com/2010/08/exploiting-dll-hijacking-flaws.html). Although there aren't any known viruses or worms exploiting this vulnerability it is only a matter of time.
The bad new is there's not much you can do to protect yourself if you're using Windows. Don't click on any file in any directory that contains any untrusted DLL's. This is pretty useless advice for most computer users though. It may actually be easier for network admins to monitor traffic looking for DLL's floating over the wire as indicators of infection and then launching a post-compromise investigation than attempting any sort of proactive mitigation.
It will definitely be interesting watching the fall out from this particular development. Let's all just hope that whoever wrote Nimbda or Code Red isn't devising an evil way to spread malware through this particular vector...