A working exampleTo 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. He 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. “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),” explained the researcher. “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.” What poses a challenge for the attacker, 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, Beukema recommends using tools like DLL Export Viewer for analysis.
This tool 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.The researcher has provided a comprehensive list of libraries that are good candidates for hijacking attacks. He added, “these are not mere theoretical targets, these are tested and confirmed to be working. The list comprises 287 executables and 263 unique DLLs.” A CSV with a complete list of these libraries has been provided via GitHub.
Some limitationsSome caveats, as explained by the researcher for this example attack include:
- Only running executables that do not require any arguments
- Avoiding applications that come with advanced GUI and error-reporting capabilities
- Avoid DLLs written in C++.
Bypassing UACWindows User Account Control (UAC) 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 are repeatedly asked to authorize legitimate processes, which can get annoying fast, starting with Windows 7, Microsoft introduced inbuilt “exceptions” within the UAC framework. Effectively, this allows trusted system DLLs to “auto elevate” privileges without having to bother users with UAC prompts. “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. There comes a roadblock here, though. 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 executable and the custom DLL need to be located in a trusted directory, but none of these are user writeable.”
Some imitation techniques come in handy here, such as creating a mock “C:\windows \system32” directory (with a trailing space right after windows). This unusually named folder may trick an executable into treating the attacker-created directory as a “trusted location.”There is some debate if being able to create such directories should be treated as a security vulnerability as it provides a pathway for an attacker to exploit DLL hijacking vulnerabilities. “It is debatable whether this is a proper security vulnerability – Microsoft argue it is not, but it is at least a flaw, given that most (non-enterprise) Windows computers are using ‘administrator accounts’ by default. Either way, this provides us with an excellent means through which DLL hijacking can be made much more powerful,” said the researcher.