Windows 10 Executables are Vulnerable to DLL Hijacking

Windows 10 Executables are Vulnerable to DLL Hijacking

A simple VBScript may be enough to allow users to gain admin privileges and bypass UAC entirely on Windows 10. Wietze Beukema (security researcher at PwC UK) said in a report that almost 300 Windows 10 executables are vulnerable to DLL hijacking. Wietze Beukema explained that It turns out nearly 300 executables in your System32 folder are vulnerable to relative path DLL Hijacking. Did you know that with a simple VBScript some of these Executables can be used to elevate such executions, bypassing UAC entirely.

The flaw referred to here is relative path DLL hijacking, which is when an attacker can cause a legitimate Windows EXEs to load an arbitrary DLL of the attacker’s choice, most likely with malicious intent. DLL hijacking attacks can be useful to a skilled attacker as they grant capabilities such as arbitrary code execution, privilege escalation, and persistence on the target system. Beukema covered various techniques of DLL hijacking in their blog post include DLL replacement, DLL Proxying, DLL search order hijacking, Phantom DLL hijacking, DLL redirection, WinSxS DLL replacement, and relative path DLL Hijacking.

Demonstrative Example

To demonstrate relative path DLL hijacking in practice, Wietze Beukema focused on the libraries present in the C:\Windows\System32 folder on a Windows 10 (v1909) machine. Beukema copied the legitimate winsat.exe process into the downloads folder on his system. He then ran process monitoring tool, procmon, to get a better understanding of what DLLs the executables is looking for during execution.

Windows 10 Executables are Vulnerable to DLL Hijacking
Source: wietzebeukema.nl (Process monitor showing accessed DLLs)

Beukema explained that this allows us to identify all DLLs queried by each application, which will be all potential hijackable DLL candidates. Also it does not automatically follow that all of these are also loaded and therefore executed. The most reliable way to find out which DLLs are properly loaded, is to compile our own version of the DLL, and also make it write to a unique file upon successfully loading. After that If we repeat the above approach for all target EXEs and DLLs, it will result in a collection of files that tells us which DLLs are confirmed vulnerable to DLL hijacking.

What poses a challenge for the threat actors, though, is compiling a custom version of DLL that can be launched by the executable, without any issues. To get a reliable understanding of a legitimate DLL structure, Wietze Beukema recommends using tools like DLL Export Viewer for analysis.

DLL Export Viewer provides insight into the DLL structure we are trying to recompile by enumerating all external functions names that would then be duplicated in a DLL Hijacking exploit.

Windows 10 Executables are Vulnerable to DLL Hijacking
Source: wietzebeukema.nl (Approach to finding vulnerable executables)

The security researcher has provided a comprehensive list of libraries that are good candidates for hijacking attacks. He added that these are not mere theoretical targets, these are tested and confirmed to be working. The list comprises 287 EXEs and 263 unique DLLs. A CSV with a complete list of these libraries has been provided on GitHub.

Some limitations

Some caveats, as explained by the security researcher for this example attack include:
  • Only running EXEs that do not require any arguments.
  • Avoiding Apps that come with advanced GUI and error-reporting capabilities.
  • Avoid DLLs written in C++.
The security researcher had tested this on Windows 10 64bit  (OS build 18362.476) but says, Some of the DLLs will not work on 32-bit Windows. You can compile C file with 32bit GCC then it will work well. This attack may not work with all Windows builds, as highlighted in a Twitter thread.

Bypassing UAC

Windows User Account Control is a security feature added in Windows Vista and above, which asks the user if they intended to run a high-risk application before it is executed. As users repeatedly asked to authorize legitimate processes, which can get annoying fast,  starting with Windows 7, Microsoft introduced inbuilt exceptions within the UAC framework. This allows trusted system DLLs to elevate privileges automatically without having to bother users with UAC prompts.

Beukema explained that with this you could try running arbitrary code with elevated privileges by using an executable that is marked for auto elevation that is also vulnerable to DLL hijacking. There are about 35 of such EXEs, as can be seen in the previous section. In case of successful exploitation, executed malicious DLLs could be used to created elevated command prompts that give full access to the computer with administrative privileges.

Windows 10 Executables are Vulnerable to DLL Hijacking
Source: Wietze Beukema (DLL Hijacking launching an elevated command prompt)

There comes a roadblock here that before auto elevating privileges of any DLL, the OS expects those DLLs to be present in a trusted directory, which is not user-writable. The problem to overcome is that of the trusted directory: both the auto-elevate EXEs and the custom DLLs need to be located in a trusted directory, but none of these are user writeable.

Some imitation techniques comes here such as creating a mock C:\windows \system32 directory (with a trailing space right after windows). This unusually named folder may trick an EXE into treating the attacker-created directory as a trusted location.

Security Researcher said that it is debatable whether this is a proper security vulnerability - Microsoft argue it is not, but it is at least a bug, given that most non-enterprise Windows PCs are using administrator accounts by default. So, this provides us with an excellent means through which DLL hijacking can be made much more powerful.

But why, VBScript?

One of the reasons the researcher suggests using VBScript is because creating Windows directories whose names contain a trailing space is not something that can be achieved via traditional means.

You could compile some lines of codes written in C to do this, as is done by the original researcher, but it turns out VBScript can actually do this for us too. The following proof-of-concept shows that with only a few lines of code you can get this to work:

Windows 10 Executables are Vulnerable to DLL Hijacking
Source: Wietze Beukema (A PoC written in VBScript that creates mock trusted directories)

Wietze Beukema explained that why he picked VBScript when exploiting executables vulnerable to DLL hijacking. He says he knows it's just because PowerShell won't let you do it, whereas VBScript will. And also because it's VBScript, you won't need to bring your own compiled binaries to use this trick, meaning that apart from your custom DLL you can do everything with Living of the Land + scripts.

Detection and prevention techniques

Wietze Beukema presents a few prevention methods that can be used to stay protected from such kind of attacks, such as looking for activity in the mock windows \ folder, should one be present on your machine. Also, adjusting UAC settings to always notify could help prevent from these attacks and the end-user should be savvy enough to understand what is about to be executed.

Another strategy to prevent is monitoring instances of DLL creation and loading from unexpected file paths. Always hunt for the creation or loading of any of the DLLs mentioned before from unexpected paths, particularly in temp locations such as %appdata%. After all, the name of the legetimate apps loading the DLLs can be changed, but the filenames of DLLs are always fixed.

Beukema suggests that when building applications, developers should enforce using absolute and not relative paths for loading DLLs among several other techniques. Preventative measures such as those explained by the Beukema can deter DLL hijacking attacks by a long shot.

Does this article being helpful to you? Let us know your thoughts in the comments section and share it with us on Facebook, Twitter, or our LinkedIn Group.

0/Comments

Previous Post Next Post