Crash Course In DLL Hijacking

[Nytro]

Crash Course In DLL Hijacking

by Tien Phan | December 10, 2015

Overview

This week, we heard a lot about a DLL hijacking vulnerability from the security community. It began with a 0-day DLL hijacking in Microsoft Office which was discovered by an independent security researcher named Parvez Anwar.

Shortly after, the website securify.nlpublished an article detailing this kind of attack and discussing the vast potential attack surface associated with DLLs and OLE.

A dynamic link library (DLL) is a basic component in the Windows operating system. Certain DLLs will be loaded into Windows applications when they start if they are needed. DLLs provide software applications with resources such as Application Programming Interfaces (APIs) and additional procedures. If an attacker can control which DLL a program loads, then the attacker can insert a malicious DLL into the DLL loading process. In fact, this method is not new. Quite a few articles regarding this technique are available on the Internet, especially from Microsoft.

In a nutshell, the vulnerability in this latest Microsoft 0-day lay in the way Microsoft Office searches for DLL components that are not present in the system, consequently allowing DLL hijacking attacks. But as we will detail below, that kind of vulnerability is not exclusive to Microsoft Office.

Attack Details

DLL search order is well documented by Microsoft. To recap, depending on the configuration of the system, a program can decide the order of the directories to be searched for a DLL to load. By default, the order of this search is as follows:

1. The directory from which the application is loaded
   
2. The current directory
   
3. The system directory, usually C:\Windows\System32\ (The GetSystemDirectory function is called to obtain this directory.)
   
4. The 16-bit system directory - There is no dedicated function to retrieve the path of this directory, but it is searched as well.
   
5. The Windows directory. The GetWindowsDirector function is called to obtain this directory.
   
6. The directories that are listed in the PATH environment variable.
   

In this case, the current directory is the problem. When a program makes a decision to load a DLL from the current directory, it can lead to the DLL hijacking.

For example, if the user is opening a Microsoft Word document, Microsoft Office will try to load its DLL component from the location of that document file. An attacker can then place a malicious DLL in the location of the document and as a result, Microsoft Office inadvertently loads the malicious code.

Another practical scenario is sharing a Microsoft Document file using Windows sharing with a malicious DLL.

If SafeDllSearchMode is enabled, it is more difficult for an attacker to use this technique. In such a case, the DLL search order is as follows:

1. The directory specified by lpFileName function
   
2. The System directory (The GetSystemDirectory function is called to obtain this directory.)
   
3. The 16-bit system directory - There is no dedicated function to retrieve the path of this directory, but it is searched as well.
   
4. The Windows directory (The GetWindowsDirector y function is called to obtain 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.
   

Nonetheless, the current directory is still in the list of directories to be searched. The difference here is that the program searches system directories for a DLL component first and, if not found, will then try the current directory.

How do I protect myself from DLL hijacking?

The following is some guidance to prevent you from becoming a victim of DLL-hijacking attacks.

For end users, the best way to prevent this attack is to apply the latest patch from the vendor. You can also harden your system using the following steps:

1. Open Notepad
   
2. Copy and paste the following text:
   

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSe ssion Manager]

"SafeDllSearchMode"=dword:00000001

[HKEY_LOCAL_MACHINESystemCurrentControlSetControlSe ssion Manager]

"CWDIllegalInDllSearch"=dword:ffffffff

1. Save as “patch.reg” on your system.
   
2. Double click patch.reg and click Yes on the Windows prompt.
   

The above script will enable SafeDllSearchMode and disable loading of DLLs from the current directory.

For developers, you can follow the suggestions from Microsoft.

We also developed a small tool for learning and demonstration purposes. This tool will track new processes created. It will then apply a hook into any new process to force a call to the SetDLLDirectory API with a blank argument. This means that any new process will be protected from loading DLLs located in the current directory. You can get the source code of the tool here.

The following is a quick demo of the tool:

-= FortiGuard Lion Team =-

by Tien Phan | December 10, 2015

Sursa: http://blog.fortinet.com/post/a-crash-course-in-dll-hijacking