A Hacker's approach to DLL hijacking via DLL Proxying

by Kaisar Reagan

It’s been a while since we have posted about dll hijacking, yet it still exists in the wild. Today we will discuss another method by exploiting another real life application which is vulnerable to dll hijacking. Exploiting this vulnerability is a bit complex in nature than simple dll hijacking.

First, let us discuss a bit about dll hijacking. A big, long and complicated story in short -- a bad guy or “Dushtu lok” simply puts a malicious DLL into your browser’s download folder or in the higher path of any known vulnerable application’s search path and waits for installing or loading a vulnerable application. In both case, it loads the evil/malicious DLL with the privilege level of the application running.

Out target application contains a DLL hijacking vulnerability that could allow an authenticated attacker to execute arbitrary code on the targeted system. The Target-application installer just extract itself to "%userprofile%\AppData\Local\Programs\target-client", the folder is unprotected and writable. The vulnerability exists due to Target-application application loading DLL files from the PATH environment (In this case installation folder) variable without verification.

The DLL is loaded by the Target-application application as the current user.

Identifying the Vulnerability:

We have used Process Monitor from the Sysinternals suite to identify the dll's that are being called by the application but not found in the loading path. The filter we used are as below image.

Figure: Procmon Filter that we have used to identify the vulnerability

Now we fire up the Process Monitor and found 164 dll’s it is calling that are unavailable. First sign of probable dll hijack vulnerability.

Figure: Process Monitor result

Weaponizing:

Now it is time to try to exploit the vulnerability. We have built a sample dll to which will pop up a calculator, we place the dll in the vulnerable folder ie, "%userprofile%\AppData\Local\Programs\target-client" folder and execute the target application. In this trial and error process we have found not all dll’s are vulnerable, but in two instances the dll loaded and executed with an error that tells it has failed to locate the entry point, and the application fails to start.

Figure: Dll loaded by the Target-application app with an error

We found that the two dll’s that are loaded in this process are dbghelp.dll and UIAutomationCore.dll. As the application fails to start shows that any dll naming dbghelp.dll or UIAutomationCore.dll will DOS the application. But we don’t want to DOS the application, but to execute commands which will have more impact than just deny the app to start.

We know an application loads a DLL because it needs to use one or more functions it exports. But, if this requirement isn’t satisfied, the DLL won’t be properly loaded and our payload will never be executed like it did in this case which just popped an error massage. To work around this issue, our DLL must export the required functions, but we don’t want to actually implement them. So, we have decided to implement a proxy dll to forward the export functions to the original dll while execute its own payload. So, we have chosen the 64bit version of dbghelp.dll located in “C:\Windows\System32”.

Now we need to list the exported functions. We’ll use DLL Export Viewer to list all the functions that are exported by the DLL. We have opened the target DLL file (C:\Windows\System32\dbghelp.dll) in the Export Viewer.

Figure: All export functions from dbghelp.dll

Now we have exported the report as an html page to parse the export directives for the linker. We have used this python code block to generate the export directives.

Figure: Export directive generator

Figure: Generated export directives


So as we have got all ingredients we need, now we write a dll wrapper. We have used below code snippet to build the proxy dll which will pop a calculator once executed.

Figure: Sample dll payload

We compile the code and name this custom DLL to dbghelp.dll and rename the original DLL to dbghelp_orig.dll and put both dll into vulnerable folder.

Figure: We dropped both dll into vulnerable folder

Now we run the Target-application and it opens along with a calculator popped.

Figure: Target-application opens with a calculator

Closure:

This blog post encapsulate a meticulous journey through the intricate maze of system dependencies, where a feature can be turned into a weapon to be exploited by malicious "Dushtu lok". This is not a conclusion but rather a waypoint on our ongoing quest to bolster our defenses. Hand in hand, we embrace the future with the understanding that cybersecurity is not a destination but an everlasting journey.