Introduction
At the end of August 2010 security researchers began releasing details of a class of vulnerabilities that has had some pretty wide spreading affects. The vulnerability discussed by the Slovenian security company Acros gained a significant amount of notoriety when security researcher and Metasploit creator HD Moore discovered hundreds of applications that were vulnerable to the attack vector. The attack that exploits these vulnerabilities has been dubbed DLL Hijacking. In this article I’m going to talk about the architectural flaws that make DLL hijacking a possibility, how to determine if applications you use are vulnerable, and steps you can take to ensure you aren’t a target of this attack.
How it Works
DLL hijacking is made possible because just about all Windows applications rely upon Dynamic Link Libraries (DLLs) as a part of their core functionality. DLL’s contain modular pieces of code that developers can call upon within their applications to perform various functions. Windows itself relies upon the same type of architecture and contains a plethora of DLLs that perform various functions.
Along with the DLL’s built into Windows, application developers will often create their own DLLs that contain the functions used by the program. When this is done, the developer created DLLs are packaged and installed with the application. The problem occurs in how applications load DLLs. By default, when an application doesn’t have a statically defined path to a DLL it requires it goes through a process to find it dynamically. In doing this the application first searches the directory it was executed from, and then searches the system directory, the 16-bit system directory, the windows directory, the current directory, and then the directories listed in the operating system PATH environment variable. In searching these paths, the application will use the DLL it finds first.
Given that knowledge, let’s imagine a scenario where we’ve executed an application that must dynamically search for a required DLL upon loading. The application immediately searches the path it was executed from and finds a DLL that matches. Unfortunately for the end user, the real DLL associated with the application is located in the Windows system directory. The DLL that’s been placed in the directory with the application is one that has been modified by an attacker to allow remote command shell access into the system. Of course, the application will never get to the real DLL because it’s already found the match it needs. Checkmate, attacker.
Identifying Vulnerable Applications
The biggest problem with DLL hijacking attacks is that Microsoft can’t just issue a catch all fix that addresses the problem in all vulnerable applications. This is because doing so would simply cause some applications not to function correctly (or at all). That being the case, fixing the issue is in the hands of two parties. First, the companies and developers who have created the vulnerable applications have to fix their code and provide updates to the users. Second, users (namely sysadmins) have to determine if their networks are running applications that are vulnerable, and seek out and install the vendor provided patches.
There are a couple of ways to determine if you are running s vulnerable application. The easiest method is to check public resources posted by security researchers who have already done the leg work and see if your application exists there. You can find one such great resource here which contains a fairly sizable list.
Figure 1: The Exploit DB listing of vulnerable applications
The second method requires a bit more work but is what has to be done in highly secure environments. Now, you might think this kind of thing is highly technical and is normally reserved for high-level security researchers, and typically you would be right. However, in his infinite wisdom, HD Moore was quite aware of the magnitude of this attack vector and developed an auditing kit that can be used to find the vulnerable applications on a system.
The kit is called DllHijackAuditKitv2 and is available here. Once downloaded, you will want to ensure you are logged in as a system administrator, extract the contents of the ZIP file, and execute 01_StartAudit.bat. This script will download Sysinternals Process Monitor and begin examining the system for vulnerable applications. In running the application myself several times I’ve noticed that the download of Process Monitor fails more often than not, so if this occurs when you run the script you can manually download Process Monitor from here. Once downloaded just ensure Process Monitor is in the same directory as the audit scripts. The initial audit script will take some time to run. Depending on the number of applications on the system it could take anywhere from 15 minutes to an hour.
Figure 2: The audit examining applications associated with particular file extensions
After the audit script as completed its execution you must switch over to the process monitor application that was spawned by the script and save the report it has generated. Click File and Save to do this. Ensure that you save the file in CSV format with the name Logfile.CSV in the audit kit directory.
Next, run the script 02_Analyze.bat. This script parses the CSV file and identifies potential vulnerabilities. If a vulnerability is found then the application automatically generates proof of concept exploit code that can be used to demonstrate the vulnerability.
Figure 3: The second script actually attempts to exploit the potential vulnerabilities found
Once finished, the command prompt left open by the script should list what applications were successfully exploited. For each exploitable application, the script will create a subdirectory under the exploits directory. These subdirectories actually contain working exploits for the affected applications. In the trenches these exploits would do nasty things like launching command shells and back door listeners. These are just proof of concept exploits so they launch calc.exe in order to demonstrate that the vulnerability exists.
With this information in hand you should be able to determine if you are running any vulnerable applications. At this early point in the game if you are running Windows then you WILL find vulnerabilities as several are still not patched. Aside from that, if you find any vulnerable applications then you should check to see if a patch exists from the application vendor. If not, then it is recommended that you get in touch with the vendor and provide them the proof of concept code so that they can work on a patch. Even if they are already aware of the vulnerability the reminder certainly doesn’t hurt and might expedite the process.
Preventing the Attack
While you are waiting for software patches there are a couple of things you can do to limit your exposure to DLL hijacking attacks.
Deploy the CWDIllegalInDllSearch Fix
The initial response by Microsoft to this class of vulnerabilities was to provide a registry modification that helps mitigate the attack by changing how dynamic DLL loading works. The fix should be deployed very carefully as it has the potential break the functionality of installed applications, but it’s worth testing if you are concerned about this attack vector. You can read up on the fix here.
Block Outbound SMB at the Perimeter
Most organizations should be doing this already, but if you aren’t then now is a good time to start. This will also help prevent against a few other types of attacks.
Uninstall the Vulnerable Software
This may not always be feasible, but if you are running a vulnerable application that is easily replaceable then the secure thing to do is make the switch.
Deploy Intrusion Detection Software
In some cases you simply won’t be able to mitigate the attack properly. As a result, the best thing you can hope to do is catch the attacker during post-exploitation. Using something like Snort is free (less the cost of the hardware) and does a really good job of detecting signatures of post exploitation activity that might occur after someone has exploit a vulnerable machine.
Conclusion
The advent of so many DLL hijacking vulnerabilities presents an interesting scenario because it’s not easily fixable by an operating system patch and it affects so many widely used applications. The best you can really do is to be sure you are educated and aware of how the vulnerability works, how to test if it exists on applications running in your network, and how to get the right information to the people who can issue a patch to fix it. This time, we all get to play the part of security vulnerability researcher.
