Lazy Privilege Escalation: Abusing Dell’s DUP Framework, CVE-2019-3726

This blog is part two of a continuing series describing research I performed between April and July 2019.

A few weeks ago, we published the first entry in a blog series highlighting research I conducted with the aim of finding as many logical bugs in Windows and third-party vendors as possible. The first blog covered an exploitation method that focuses on abusing Object Manager symlinks for EoP vulnerabilities. Today we are going to focus on a second type of exploitation method: DLL Hijacking – which is used to hijack installers in order to provide admin access for a regular user.

We will walk through CVE-2019-3726, a privilege escalation vulnerability that was patched in September. We will show how easy it is to abuse the DUP installation framework and how anyone – attackers, defenders or any other people who test software from a security perspective – can take the concepts and implementations presented and apply them to a wide range of products. Finally, we’ll present a full attack scenario from the attacker’s perspective along with general mitigation techniques from a defensive or vendor view.

Introduction

Let’s cut to the chase. Dell’s installers – programs that are responsible for installing drivers and services – are classified in categories. One of them is called the “DUP” framework, which, according to Dell “is comprised of numerous DLLs that are packaged within the same framework to provide our customers with a single unified installation experience.” From an attacker’s perspective, it means every installer behaves similarly and an exploit for one of them can possibly be used to exploit every installer in the framework.

Here are some examples of the products that can be exploited to gain admin rights:

1. Chipset_Driver
2. Communications_Driver
3. Broadcom Netlink Driver
4. DPMS

Attack Layout

Every installer in the DUP framework unpacks its files into a sub-directory inside Dell’s directory in %ProgramData%\Dell\GUID. This directory is used as the installation folder and has no other use besides being a temporary location that stores installation related files. Unfortunately, it is not admin protected – making it relatively simple to hijack a DLL in this directory.

This particular vulnerability occurs because of a design failure – one that appears in many installers over multiple vendors. The installer is supposed to load its DLLs from C:\Windows\SysWow64, which is a well-known directory in Windows used for storing digitally signed DLLs. Instead, it looks for DLLs in %ProgramData%\Dell\GUID first (which shouldn’t be there) before going to C:\Windows\SysWow64. unprotected directories and then loads them if they have the same name. There are only a few installers that bother checking their DLLs for a digital signature and, as you probably guessed, this is not one of them.

In most cases, an admin needs to run the installer to trigger the vulnerability. This can happen when running a group policy that installs the product or when directly installing the software. However, the DUP installers can also be started by Dell’s Support Assist program, which is responsible for updating drivers and services and can be activated by a regular user. The Dell Support Assist runs these installers when an update is due and could allow a malicious user to opportunity to escalate his or her privileges.

Here is a breakdown of how this might work:

1. Create a file system watcher on the directory %ProgramData%\Dell\GUID. so that, when the installer creates the directory, it pops an event.
2. Upon triggering the event, write a malicious crafted DLL named msi.dll (or any other DLL mentioned below) in %ProgramData%\Dell\GUID.
3. Wait for installers to start or play with Dell’s updates.

Hijacked DLLs

1. Zlibwapi.dll
2. msi.dll
3. Cabint.dll
4. WINNET.dll
5. VSSAPI.DLL
6. VSSTrace.DLL
7. MSIMG32.dll

Mitigation

There are several simple steps to preventing DLL Hijacking in installers. Vendors can do any one of these steps to mitigate this problem, although it’s safest to do all of them:

1. Change the installation directory so that it is admin-protected, which will prevent planting issues.

2. When trying to load Microsoft signed DLLs that have well-known paths, don’t try to load them from the current directory first. Additionally, call the LoadLibraryExfunction with dwFlags=0x800 instead of LoadLibrary, which guarantees that the DLL will be loaded from the System32

3. If you run in a privileged context, then only load digitally signed DLLs. This is crucial and the performance overhead is negligible.

Closing Words

As we’ve just shown, escalating from a regular user to an admin is an easy feat for attackers to accomplish if they know their targets’ environments. Having this information, malware writers and blue\red teamers can plan an ambush for when installers are launched on their targets.

The DLL Hijacking vulnerability is all too common across installers. Almost every tested vendor had at least one product that is vulnerable to this type of attack, including all tested PC manufacturers.

Stay tuned for more details on how we found this vulnerability along with some other interesting cases.

Disclosure Timeline

May 22h, 2019: Vulnerability identified and reported to Dell.

May 23th, 2019: Dell received the report and decided to open a psrc-5835.

June 6th, 2019: Dell reproduced the issue and decided to fix the vulnerability.

September 13th, 2019: Dell released a patch and issued CVE-2019-3726.