[How to] DLL Hijacking + tool + Attack example

DLL Hijacking is really a simple concept.

Applications load external code via DLLs (Dynamic Link Libraries). DLL Highjacking is a process by which malicious code is injected into an application via a malicious DLL with the same name as a DLL used by the application.

An application is vulnerable to DLL hijacking depending on how they reference their DLLs. One example is using relative paths instead of the absolute path to the DLL. Another is loading DLLs using environment variables that may not be set properly in which case the directory defaults to a relative path of the executing application.

So, let's pretend your system's DLL search path looks something like this:

If SafeDllSearchMode is enabled, the search order is as follows:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If SafeDllSearchMode is disabled, the search order is as follows:

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

More details about this, you can read here - msdn

Here you can see a simple attack using Metasploit :)

KB: We can't fix this one - Microsoft DLL Hijacking Exploit from Offensive Security on Vimeo.

DllHijackAuditor - checking application to this vulnerability can be found here

What about protection?

In older version of Windows (2000 - Xp is disabled by default) you can active SafeDllSearchMode in registry: 

          HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

From msdn.microsoft.com: Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2). 

I have Windows 7 Pro with all updates installed and I don't have this feature activated :(

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.

Source - StackOverflow

Source 2 - MSDN
Source 3 - WindowSecurity