Nearly 300 vulnerabilities executable to Hijacking DLLs found in Windows 10

0

Nearly 300 vulnerabilities executable to Hijacking DLLs found in Windows 10

Many will be aware of the Hijacking DLLs and many not, so before going further let’s look at what Hijacking DLL actually means? DLL Hijacking is an attack that exploits the way some Windows applications search and load Dynamic Link Libraries. Most Windows applications will not use a fully qualified path to load any required DLLs. That means a threat actor can place a fake DLL for a known program in a location that is searched before the real DLL’s location and almost guarantee that the malicious DLL is loaded, resulting in whatever code the attacker wants to run running!

When programs are not written to specify the exact location of a required DLL, Windows will search for the DLL by name in a specific order. For instance, let’s say that the application, user.exe requires a DLL named learn.dll that is usually in the Windows system directory. If the application does not specify the exact path for learn.dll, Windows will search for the DLL in the directory from which the application has been loaded first.

In a report from security researcher Wietze Beukema, we got to know that nearly 300 Windows 10 executables are vulnerable to this DLL hijacking. “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 EXEs can be used to elevate such executions, bypassing UAC entirely?” the researcher explained.

To demonstrate relative path DLL hijacking in practice, Beukema focused on the libraries present in the “C:\Windows\System32” folder on a Windows 10 (v1909) machine. The researcher copied the legitimate winstat.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 EXE is looking for during execution.

Process monitor showing accessed DLLs

[Image Source: wietzebeukema.nl]

This allows us to identify all DLLs queried by each application, which will be all potential hijackable DLL candidates. But 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 make it write to a unique file upon successfully loading. If we then repeat the above approach for all target executables and DLLs, it will result in a collection of files that tells us which DLLs are confirmed vulnerable to DLL hijacking.

explained the researcher.

According to him, the actor finds difficulties in Compiling custom versions of existing DLLs as a lot of executables will not load such DLLs if procedures or entry points are missing. Tools such as DLL Export Viewer can be used to enumerate all external function names and ordinals of the legitimate DLLs. Ensuring that our compiled DLL follows the same format will maximize the chances of it being loaded successfully.

Flowchart of the taken approach.

[Image Source: wietzebeukema.nl]

The researcher has provided a comprehensive list of libraries that are good candidates for hijacking attacks. He said, “these are not mere theoretical targets, these are tested and confirmed to be working. The list comprises 287 executables and 263 unique DLLs.” A CSSV with a complete list of these libraries has been provided via GitHub.

“With this in mind, 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 executables, as can be seen in the previous section,” explained Beukema. If successfully exploited, executed malicious DLLs could be used to created elevated command prompts that give full access to the computer with administrative privileges.

How you can eliminate the flaws according to the researcher, A simple way to prevent DLL hijacking from happening would be for applications to always use absolute paths instead of relative ones. Although some applications (notably portable ones) will not always be able to do so, applications located in \system32\ and relying on DLLs in the same folder have no excuse for doing otherwise. The better option, which only very few Windows executables seem to do, is to verify all DLLs before loading them (e.g. by checking their signatures) – this would largely eliminate the problem.

However, attackers will still be able to bring older versions of legitimate/trusted applications that can be exploited. So even if every application starts checking their DLLs before loading them from now on, we would still have to deal with this problem.

For more news on tech and cybersecurity stay tuned at Android Rookies by subscribing to our newsletter from here

Share.

About Author

Be Ready for the challenge

Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments