DLL Search Order Hijacking
Adversaries may execute their own malicious payloads by hijacking the search order used to load DLLs. Windows systems use a common method to look for required DLLs to load into a program, Hijacking DLL loads may be for the purpose of establishing persistence as well as elevating privileges and/or evading restrictions on file execution.
There are many ways an adversary can hijack DLL loads. Adversaries may plant trojan dynamic-link library files (DLLs) in a directory that will be searched before the location of a legitimate library that will be requested by a program, causing Windows to load their malicious library when it is called for by the victim program. Adversaries may also perform DLL preloading, also called binary planting attacks, by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL. Often this location is the current working directory of the program. Remote DLL preloading attacks occur when a program sets its current directory to a remote location such as a Web share before loading a DLL.
Adversaries may also directly modify the way a program loads DLLs by replacing an existing DLL or modifying a .manifest or .local redirection file, directory, or junction to cause the program to load a different DLL.
If a search order-vulnerable program is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation from user to administrator or SYSTEM or from administrator to SYSTEM, depending on the program. Programs that fall victim to path hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace.
Let us see some examples:
In Windows Environments when an application or a service is starting it looks for a number of DLL's in order to function properly. If these DLL's doesn't exist or are implemented in an insecure way (DLL's are called without using a fully qualified path) then it is possible to escalate privileges by forcing the application to load and execute a malicious DLL File.
It should be noted that when an application needs to load a DLL it will go through the following order:
· The directory which the application is loaded.
· C:\Windows\System32
· C:\Windows\System
· C:\Windows
· The current working directory
· Directories in the system PATH environment variable
· Directories in the user PATH environment variable
A fast way to Hijack and Find any DLL Hijacking is using PowerSploits, Find-PathDLLHijack, Find-ProcessDLLHijack, Invoke-AllChecks. We can check that powersploit will tell us where the hijack is located and what command to use next to hijack the process immediately.
We will work with Administrator Privileges in this example, not completely necessary if you can find a user with misconfiguration permission where they are allowed to WRITE, crazy right!!?, who would do that!!?
Procmon
For this technique I will use Procmon, as this is a great toll to view what a program is loading at run time, there are also other great tools from PowerSploit that will verify this Vulnerability, other tools such as SharpUp from GhostPack it is a tool written in C#.
Our Process in this sample is Winamp.
Winamp is a media player for Microsoft Windows it was a very popular and widely used media player back in the early 2000's, in the version we are currently working on it contains a DLL Hijack vulnerability as it is trying to load many different DLL files inexistent in its current directory, we can verify this with Procmon.
Wow, many potential hijacks, so our next step is to choose a DLL we wish to hijack, I will use the DLL . I will use a DLL this time to receive a reverse shell. My focus will be on vcruntime140d.dll
What happens when the program cannot find the DLL, it start following an order to locate the DLL
Let us take a look and see what happens if I rename it, how will the order continue.
Now I will add this DLL to any of the other paths that are seen above see if it loads it and gives me a shell.
Once added:
We can simply start the process and check the results
And this time it did find it.
References:
Last updated
Was this helpful?
