Background:

Welcome to the part 7 of Practical Thick Client Application Penetration Testing using Damn Vulnerable Thick Client App (DVTA). In the previous article, we have discussed how to perform .NET application patching using ildasm and ilasm utilities to modify the functionality of a .NET assembly. In this article, we will discuss DLL Hijacking in thick client applications using DVTA.

Introduction to DLL Hijacking:

DLL (Dynamic Link Library) files usually hold executable code that can be used by other applications. When an application needs to use this DLL file, it has to search for it if the absolute path is not provided. If an attacker replaces his own DLL file with the name that the application is searching for, then the application loads the attacker’s DLL and executes the malicious code. This is popularly known as DLL Hijacking.

To better understand DLL Hijacking, we must understand how Windows applications find their DLL files when the full path is not provided (This order might slightly change in some special conditions such as SafeDllSearchMode).

  1. The directory from which the application is loaded
  2. The current directory
  3. The system directory (C:\\Windows\\System32\\)
  4. The 16-bit system directory
  5. The Windows directory.
  6. The directories that are listed in the PATH environment variable.

Now, assume that the application needs to load the test.dll file to execute some functionality and the absolute path to the DLL is not provided. Let us also assume that this file is located in the system directory. If an attacker places his own DLL file (test.dll) in the directory from which the application is loaded, this directory will be accessed by the application before the system directory is accessed thus loading the attacker’s malicious DLL file rather than loading the original test.dll.

Finding DLL Hijacking in DVTA:

Finding DLL Hijacking vulnerabilities is easy with a tool like Process Monitor. There are several automated tools available online for identifying DLL Hijacking but still Process Monitor is the all-time best. Process Monitor comes with Sysinternals suite of tools.

Launch Process Monitor and apply some filters to shorten the output. We can apply a filter by navigating to the Filter window and choosing the desired options as shown in the figure below.


Similarly, add two more filters and your filter list should look as shown in the figure below.


We have applied the above filters, because:

We want to see the results associated only with DVTA.exe process

We want to see if the result column contains name not found

We want to see if the application accesses any path containing the word DVTA.

Now, let us launch DVTA application and log in as Rebecca using the following credentials.

Username: rebecca

Password: rebecca


After logging in, switch back to Process Monitor and you should see the following results as per the filters we applied.


If you closely observe the output, you should see the following entries.


This means the application tried to access the DLLs shown above from the location where DVTA.exe is loaded, and the DLLs were not found in that directory.

This means that we can place a malicious DLL in this directory with the same name, and it will be loaded by the application. You can write your own DLL or create one using msfpayload as shown in the figure below.


Ethical Hacking Training – Resources (InfoSec)

I have created a DLL file named poc.dll, which pops up a calculator when it is loaded. Let us rename it as credssp.dll and place it in DVTA.exe’s directory. This looks as shown in the figure below.


Everything is set. Close DVTA.exe & Process Monitor and re-launch DVTA.exe once again and log in as Rebecca as we did earlier. A calculator should pop up as shown below.


You may use other payloads such as meterpreter reverse shell rather than a calculator.

Conclusion:

In this article, we have discussed the basics of DLL Hijacking vulnerabilities and how one can find and exploit DLL Hijacking vulnerabilities in DVTA application. In the next article, we will discuss some miscellaneous test cases that can be used against Thick Client Applications.