Best Practices to Prevent DLL Hijacking

Finjan TeamBlog, Cybersecurity

Finjan Best Practices to Prevent DLL Hijacking

Though we routinely use computer programs to perform our daily tasks, few of us actually know or tend to consider the implications of how this software is constructed, and any weaknesses it might be vulnerable to before it starts its work.

But hackers and the malicious tools employed by cyber-criminals don’t only target applications once they’re up and running. It’s quite possible to compromise a piece of software when it’s called up from a directory listing, or by clicking on an icon. And there may be loopholes and vulnerabilities that can be exploited while a program is assembling its tool-kit and getting its act together, before starting productive work.

This kind of attack represents a particular weakness of Microsoft Windows applications, which are often vulnerable to a technique known as DLL hijacking.

What’s a DLL?

A DLL or Dynamic Link Library is an archive of commands or information needed in running a portion of a larger application. This data may be called up on demand (i.e., dynamically), reducing the need to have it all coded into the body of the main program.

This mechanism reduces the loading time for an application (especially for larger pices of software), and improves the overall efficiency of the software.

DLLs are widely used throughout the Microsoft Windows operating system, and its associated software. These DLLs typically contain multiple procedures and codes which allow them to be used by a range of different programs, at the same time.

But Dynamic Link Libraries or their equivalent are also featured in other operating platforms. So the dangers associated with them may affect a significant proportion of computer users, worldwide.

What’s DLL Hijacking?

The paths for locating DLL files are set by the operating system – Windows, in most cases, so we’ll be discussing the phenomenon on that basis. These paths are established using what are known as Global Environmental Variables.

Under default conditions, when an application requests a DLL file, the operating system (OS) first looks for it in the same folder where the application is stored. If the required DLL can’t be located there, the OS searches through a sequence of other folders, as determined by the Global Environmental Variables.

Since DLLs may reside in a range of different folders across the hard drive of a typical system, this opens up the possibility of an attacker substituting their own (malicious) version of a named DLL into the directory path most likely to be followed by an application’s DLL searches.

This replacement of an original DLL with a fake malicious version and its strategic placement for easy loading by a targeted application is called DLL hijacking.

There are various forms of DLL hijacking, all of which are variations on that central theme of being able to inject a malicious or rogue DLL into the program loading process.

DLL Search Order Hijacking

Unless the path to the DLLs required by a specific application are hard-coded into the software, Windows searches for them in a particular order. This order has been well documented by Microsoft – and is therefore readily available to potential hijackers. Its default search setting is:

  1. The directory from which the application was loaded.
  2. The current working directory.
  3. The system directory. Usually, C:\Windows\System32, but the GetSystemDirectory function can be used to get the specific path.
  4. The 16-bit system directory. Typically, it’s C:\Windows\System, but this may be discovered by a manual search of the targeted hard drive.
  5. The Windows directory. Usually, C:\Windows, but again, the GetSystemDirectory function may be used to verify this.
  6. The directories listed in the PATH environment variable.

Since it would relatively easy for an attacker to introduce a rogue DLL into the current working directory (which is high on the search list), this type of DLL hijacking has a high chance of succeeding.

Known DLL Adjustment

Just like the list of trusted websites in a browser, when an application loader comes across a command to import a DLL, it first checks for a KnownDLL directory which contains the names of known system DLLs. If the DLL mentioned in the “import name” command matches with a KnownDLL, then this Dynamic Link Library will be mapped to the relevant process address space, in the system memory.

There’s a specific Windows registry key which specifies where the list of KnownDLLs is located – and hackers can modify a related registry key to exclude their own malicious DLLs from processing via the KnownDLL protocol.

DLL Side-Loading Attack

A DLL side-loading attack exploits the WinSxS directory, which is located in C:\Windows\WinSxS, holds multiple versions of DLLs, and is used by many applications to prevent problems associated with updated or duplicated versions of Dynamic Link Libraries.

An application wishing to use the WinSxS directory to retrieve a DLL must first consult a manifest which lists the DLLs that may be called upon at run-time by a particular application, and which is used in determining which version of a DLL to choose.

Attackers can insert a spoofed DLL into the WinSxS directory, as this manifest only validates the DLLs listed on it from the metadata that’s included with them – which is quite easy to manipulate.

Phantom DLL Hijacking

This method exploits the Windows operating system’s concession to legacy or rarely used DLLs which applications may contain instructions to load at start-up – even if they’re not essential to using the software.

To take advantage of this loophole, attackers simply need to name their malicious Dynamic Link Library as one of these “old-school” DLLs and place it in the relevant search path for the application to find.

The Effects of DLL Hijacking

The objective of DLL hijacking is for the attacker to place their bogus DLL higher in the operating system or application’s search path than any better alternatives, so that it loads successfully into the targeted program. Once this placement strategy has been accomplished, the damage they can cause is limited only by their skills in coding the malware that’s delivered by the malicious DLL.

There are several online resources detailing documented cases of the compromise of Samsung applications and anti-virus software by DLL side-loading attacks. Developer’s forums contain posts on how various DLL hijacking techniques may be used for both benevolent and malicious purposes. And there are YouTube videos demonstrating how DLLs can easily be introduced into Microsoft Office applications, or invoked from registered file types.

Strategies for Prevention

Ideally, the primary line of defense against DLL hijacking needs to originate from the software developers. If programmers use absolute paths to clearly define the expected location of Dynamic Link Libraries in the software code (rather than having the operating system do a default search), the vulnerability can be greatly reduced.

Of course, if a computer system is first infiltrated by hackers who then gain access to the registry and the exact paths of registered DLLs, even this safeguard can fail. But the effort required to get to such a stage would be considerable.

There are a number of (free and paid) third-party tools dedicated to detecting signs of DLL hijacking, or for testing whether your system and applications are vulnerable. For example, DLL_HIJACK_DETECT (available through the GitHub portal) works on 32-bit (x86) and 64-bit (x64) systems, and scans applications to check them for vulnerabilities.

In terms of prevention, good network practices such as having a strong firewall installed and using intrusion detection systems are a first line of defense. Blocking the TCP ports 445 and 139 (which are most commonly used for compromising computers) is another effective step. And making sure that your operating system and applications are up to date and regularly patched can ensure that you have the latest defenses.

Disabling DLL loading from remote network shares, the loading of DLL files from WebDAV, and disabling or manually controlling the WebClient service can set active blocks against hijackers.

Finally, Microsoft distributes a tool for blocking DLL hijacking attacks. It’s part of an ecosystem which also includes third-party tools, designed for the same purpose.

Share this Post

Summary
Finjan Best Practices to Prevent DLL Hijacking
Article Name
DLL Hijacking | Best Practices to Prevent a Known Weakness of MS-OS
Description
In a Windows OS environment, DLLs may reside in a range of different folders across the hard drive of a typical system. This opens up the possibility of an attacker substituting their own (malicious) version of a named DLL into the directory path most likely to be followed by an application's DLL searches.
Author
Publisher Name
Finjan
Publisher Logo