Analysis of DLL hijacking attacks

Copyright (c) 2010 Czy Invicta <Hack01 @ Live! Cn>
All rights reserved.

 

In this article, I will talk about the possibility of some defects becoming DLL hijacking. We hope to determine whether the application is vulnerable in the future and take measures to ensure that you are not the target of this attack.

Working mechanism
~~~~~~~~~~~
DLL hijacking is possible because almost all Windows applications use dynamic link libraries as part of core functions. DLL contains modular code that developers can call and execute various functions based on their application needs.

With the built-in DLL to Windows, application developers often create applications that contain their own DLL functions. After these steps are completed, the developer will package and install the DLL and the application. The problem occurs when the application loads the DLL. By default, when an application does not have a static definition path, it needs a DLL to discover its dynamics through a process. In such an application, first search for the current directory executed, then search for the system directory, 16-bit system directory, Windows directory, and then list the operating system directory in the PATH environment variable. The application uses the DLL to find these paths.

Given the knowledge, let's take a look at where an application has been executed, and we must dynamically find the time when the DLL was loaded. Search for and find a matching DLL from the execution path. Unfortunately, the real DLL associated with the application is located in the Windows System directory. If the DLL in the application directory has been modified by an attacker and the remote command Shell is allowed to access the system, the application will never get the real DLL, because it has found the matching and obtained the requirement. That's what attackers do.

Identify vulnerable applications
~~~~~~~~~~~~~~~~~~~~
The biggest problem with DLL hijacking attacks is that Microsoft cannot release solutions for all vulnerable applications, because doing so only causes some applications to not work properly (or all ). Under such circumstances, a fixed problem occurs in the hands of both parties. First, the company and the developer who created this fragile application must fix their code and provide updates to users. Second, users (that is, system administrators) must determine that their network-running applications are vulnerable to attacks and seek vendors to provide patches and install them.

There are several methods to determine whether a running application has a vulnerability. The simplest way is to check the security information of public resources. You can also access the ingress.

The second method requires more work, but pay attention to it in a highly secure environment. Now, you may think that this kind of thing is highly technical and is usually reserved by high-level security researchers. However, we need an audit toolkit to find Vulnerable applications on the system.

The package is called “dllhijackauditkitv2.pdf and you can click here to download dllhijackauditkit.zip. Make sure that you log on as a system administrator. decompress the ZIP file and run 01_StartAudit.bat. This script downloads the Sysinternals Process Monitor and starts to detect vulnerable applications in the system. I have realized that downloading the monitor often fails. If the same happens after you run the script, you can manually download this http://technet.microsoft.com/en-us/sysinternals/bb896645.aspxtool. Make sure to download to the same directory as the audit script. It will take some time to run the preliminary audit. It may take 15 minutes to an hour for different applications in the system.

Figure 1: auditing application-specific file extensions

 

After the audit is complete, the script will generate and save the report it generates. Make sure that you are saved in the audit toolkit directory named Logfile. CSV.

Next, run the 02_Analyze.bat script. This script parses the CSV file and identifies potential vulnerabilities. If a vulnerability is discovered, the application generates a conceptual verification attack code to demonstrate the vulnerability.

Figure 2: The second script checks for potential vulnerabilities and attempts to exploit them

 

Once completed, the command prompt lists which applications are successfully used. For each application that can be used, this script creates an Exploits subdirectory. In addition, if you find Vulnerable applications, you should check whether the application provider has patches. If not, we recommend that you contact your suppliers and provide them with proof-of-concept code so that they can promptly provide an update Patch.

Deploy CWDIllegalInDllSearch
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Microsoft initially provided a Registry Modification to this vulnerability to help mitigate dynamic DLL loading attacks. This deployment should be very careful because it may damage the functions of the application, but if you pay attention to this attack medium, it is worth testing. You can read more information from http://support.microsoft.com/kb/2?#/cn.

Uninstall Vulnerable Software
~~~~~~~~~~~~~~~~~~~~
It sounds like a joke, because it may not always work. But if you are running a vulnerable application, consider the consequences.

Deploy Intrusion Detection System
~~~~~~~~~~~~~~~~~~~
In some cases, you cannot mitigate the attack. Therefore, the best thing is that you can get ahead of the attacker's intrusion (for details about this part, I have already described it in many times ), use something like Snort.

Conclusion
~~~~~~
The emergence of so many DLL hijacking vulnerabilities shows an interesting thing because it will not be easily solved by operating system patches. Be sure to understand how the vulnerability works, how to test applications running on your network, and how to fix it. This is part of our security vulnerability researcher's work and we hope you can do well. If you have any questions, please write an Email to me (Hack01 [at] Live.cn.

 

# Hacker netspy [C.Z. Y]