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.nl published 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.
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:
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:
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:
Windows Registry Editor Version 5.00
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 =-