Finding the same bugs in all the familiar places

(Migrated Post)

A while back, I had a patch of cases where I was regularly looking at samples leveraging DLL Side loading (also called Search Order Hijacking) as part of their setup phase. This vulnerability exists because of how Windows handles resolving libraries for applications and can be exploited to cause an application to inadvertently load (at the same privilege level) a malicious library. When a library is
loaded by an application (either delayed or at execution), Windows will check the following locations
in order for a copy of the library:

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

The above shows the locations checked when SafeDllSearchMode is disabled. When enabled, the current directory is checked fifth, instead of second.

This process can be exploited when a malicious library is added to one of these locations - before
the actual library natively resides. For example, if MyApp.exe is attempting to load TestLib.dll,
which is located in SYSTEM32 (location #3 above) and an attacker deploys a malicious copy to the current working directory
(#2 above) - the malicious copy will be loaded, instead of the native copy.

Exploitation of this technique in the wild has been commonly used by attackers for mainly:

  • Initial access deployment - In observed cases, a vulnerable legitimate and signed executable is bundled with a malicious
    library and obfuscated payload inside of a Self-Extracting (SFX) RAR Archive.
  • System persistence - Attackers install a malicious library to the same folder as a vulnerable application that is
    regularly executed or run as a system service

Some have argued that DLL Side loading is an Antivirus (AV) vulnerability - based on the
assumption / that detection engines only look at the parent process and make a determination
based on that. While that may be the case for some AV products (and of those from 2005), the
vulnerability can be exploited for tactical uses, beyond a detection bypass. In addition to being
usable for persistence, because the side loaded libraries are run at the same privilege level as
the associated process, if loaded by a system services, it would be possible to escalate to
SYSTEM level.

Calc.exe opened by maliciously library loaded by vulnerable application

Following are two interesting applications I found that were vulnerable to DLL Side loading that
have finished the notification process and some analytical assessments of each:

Dell Power Management Packages

While rebuilding a bare-metal sandbox, I ran the Dell Power Management Service Updater ( Dell-Power-Manager-Service_XJ50Y_WIN64_3.0.0_A00.EXE / SHA256 Hash
62dcd3ba9a005255a651dfb601405a6258312cbcd1bdf63489f65837b212601a) through
Siofra as a cursory check.

Following is the output from this check:

Output

From the output, six of the dependencies of this installer were flagged as vulnerable. Using
Process Monitor when the installer was executed (from C:\Users\User\Desktop\), the highlighted lines show the installer first attempting to open VERSION.dll from the same directory as the installer, before then moving on to SYSTEM32 - showing that the installer was highly-likely vulnerable.

Output

In order to confirm fully this vulnerability, a PoC malicious library was written in Visual Studio with
the same exports as VERSION.dll linked to the original library. The main components of this
are DllMain, which contains a switch statement with a WinExec call to open calc.exe
whenever the library is loaded (shown first), and the links to the original library exports
(shown second):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved )
{
 switch (ul_reason_for_call)
 {
  case DLL_PROCESS_ATTACH:
  {
   WinExec("c:\\windows\\system32\\calc.exe", SW_SHOW);
  }
  case DLL_THREAD_ATTACH:
  {
   WinExec("c:\\windows\\system32\\calc.exe", SW_SHOW);
  }
 }
 return TRUE;
}
1
#pragma comment(linker, "/export:GetFileVersionInfoA=C:/Windows/System32/version.GetFileVersionInfoA")

The result of this is a beautiful waterfall of calc when the installer is loaded:

Output

What makes this case interesting is that the vulnerable application is installed by default on some new Dell systems. For an attacker, this type of vulnerability could be trivially leveraged for persistence - given the large-installation base.

Notification Timeline:

Date Event
2018 May 9 Reported to Dell
2018 May 9 Dell acknowledge receipt
2018 May 15 Dell re-acknowledge receipt
2019 May 20 Dell provides update stating review is in final review and release coming soon
2019 June 3 Dell provides update that another researcher has submitted additional information related to original vulnerability
2019 September 1 I Requested status update
2019 September 4 Dell states the review is in final review and update coming next week
2019 September 12 Dell publishes Security Advisory (DSA-2019-065 / CVE-2019-3726)

Windows 10 OpenSSH Client

While preparing for the 2019 Northeast Collegiate Cyber Defense Competition (NECCDC) I
found that several of the executable files (listed below) for OpenSSH for Windows (version 7.6.0.0)
were also vulnerable to DLL Side loading, using the same method of identification with Siofra,
validation with ProcessMonitor and validation with a PoC.

1
2
3
4
5
6
7
C:\Windows\System32\OpenSSH\scp.exe
C:\Windows\System32\OpenSSH\sftp.exe
C:\Windows\System32\OpenSSH\ssh-add.exe
C:\Windows\System32\OpenSSH\ssh-agent.exe
C:\Windows\System32\OpenSSH\ssh-keygen.exe
C:\Windows\System32\OpenSSH\ssh-keyscan.exe
C:\Windows\System32\OpenSSH\ssh.exe

In each of the vulnerable executable files, the following libraries could be used for exploitation:

1
2
3
4
5
6
7
bcrypt.dll
logoncli.dll
netutils.dll
ntmarta.dll
samcli.dll
SspiCli.dll
wkscli.dll

Unlike the previous case, this vulnerability is inherently interesting because of the large base of potentially vulnerable systems. However, this vulnerability impacting OpenSSH allows for a number of theoretically possible attacks, that may not applicable to large-scale usage, but may be of high value in a targeted attack scenario.

Notification Timeline:

Date Event
2019 March 11 Reported to Microsoft MSRC
2019 March 11 Received automated acknowledgement
2019 March 20 Received acknowledgement report was being reviewed
2019 March 28 Microsoft verified the issue, however determined it does not meet their bar for servicing via a monthly security update.

Final Thoughts

As exploitation of these vulnerabilities require either existing system access or social engineering,
they are by no means the most critical out there. However, I feel @n0x00 described it best in a
GitHub thread: “it’s the XSS of thick client work”.