---

Introduction

In the following article we will present a new vulnerability in PC-Doctor’s Dell Hardware Support Service software discovered by SafeBreach Labs.

UPDATE: After SafeBreach Labs sent the details to Dell, we discovered that this vulnerability affects additional OEMs which use a rebranded version of the PC-Doctor Toolbox for Windows software components.

In this post, we will demonstrate how to exploit this vulnerability in order to load an arbitrary unsigned DLL into a service that runs as SYSTEM, achieving privilege escalation and persistence.

Additionally, we will present some of the potential malicious actions that could be undertaken by exploiting the vulnerability in the SupportAssist software. These exploits include a Proof-of-Concept of how to read physical memory using Dell’s Microsoft-signed driver (which is part of the SupportAssist software).

PC-Doctor

The components which allow SupportAssist to access sensitive low-level hardware (such as physical memory, PCI and SMBios) was written by the PC-Doctor[2] company. The company develops hardware-diagnostic software.

In this article we will focus on PC-Doctor’s components in order to describe the vulnerability and then exploit the vulnerability to get low-level access (e.g. to the physical memory).

Dell SupportAssist

Dell SupportAssist[1] is a software which is preinstalled on most Dell PCs. The software proactively checks the health of the system’s hardware and software. These health checks may require permissions at a high-permission level. In order to run with actions requiring high permissions, a signed driver is installed in addition to multiple services running as SYSTEM.

Vulnerability

Discovery

In our initial exploration, we targeted the “Dell Hardware Support” service based on the assumption such a critical service would have high permission level access to the PC hardware as well as the capability to induce privilege escalation.

After the Dell Hardware Support service starts, it executes DSAPI.exe which in turn executes pcdrwi.exe Both run as SYSTEM;

Next, the service executes numerous PC-Doctor executables which collect information about the OS and the hardware of the computer. These executables are actually regular PE files, but have a different extension – “p5x”.

All of these executables load DLL libraries which have the ability to collect information from different sources (software and hardware). Once the libraries were loaded we noticed the following in ProcMon (Note: We filtered the non-relevant events from the screenshot):

As you can see from the screenshot, three of the p5x executables are trying to find the following DLL files on the c:\python27 directory (my PATH environment variable):

1. LenovoInfo.dll
2. AlienFX.dll
3. atiadlxx.dll
4. atiadlxy.dll

Demonstrating a DLL hijacking vulnerability.

In my VM, the c:\python27 has an ACL which allows any authenticated user to write files onto the ACL. This makes the privilege escalation simple and allows a regular user to write the missing DLL file and achieve code execution as SYSTEM. It is important to note that an administrative user or process must (1) set the directory ACLs to allow access to non-admin user accounts, and (2) modify the system’s PATH variable to include that directory.

In order to test this privilege escalation vulnerability, we compiled a DLL (unsigned) which writes the following to the filename of a txt file:

1. The username which executed it.
2. The name of the DLL file.

The DLL was loaded and executed as SYSTEM when we renamed it following:

1. LenovoInfo.dll
2. atiadlxx.dll

Root Cause Analysis

The p5x modules (and most of the PC-Doctor code) are using a utility library named Common.dll, which provides significant functionality including the option to load a DLL file:

As you can see in the screenshot, there are two root causes for the vulnerability:

1. The lack of safe DLL loading. The code is using LoadLibraryW, instead of using LoadLibraryExW; this allows an unauthorized user to define the search order using certain flags, such as LOADLIBRARYSEARCHDLLLOAD_DIR. This, in turn, searches the DLL only in its own folder, avoiding the scenario of searching the DLL in the PATH variable.
2. No digital certificate validation is made against the binary. The program doesn’t validate whether the DLL that it will load is signed. Therefore, it will load an arbitrary unsigned DLL.

Exploitation (R/W to Physical Memory)

PC-Doctor Signed Driver

As mentioned above, SupportAssist is using a signed driver by PC-Doctor (which is named pcdsrvc_x64.pkms) in order to access low-level memory and hardware.

Note: Recently, a security researcher named Bryan Alexander found a vulnerability [3] in it which allowed a non-admin user to send an IOCTL and access to the hardware. Most of the driver’s logic is described in his blog post.

PoC – Reading Physical Memory

Among the notable libraries which are loaded into the PC-Doctor .p5x executables is SysSpace.dll. This library provides a strong wrapper function to the physical memory reading functionality, called PhysicalMemory::read.

The function opens a handle to the driver and sends the relevant IOCTL to the driver. The only remaining step was to figure out which parameters we needed to send to the function.

We searched for a DLL which imports the PhysicalMemory::read function and uses it, so we could quickly understand how to use this function. We used dumpbin for that purpose.

So we opened Quip.dll using IDA and extracted the implementation which calls the function:

Then we loaded SysSpace.dll, defined the constructor of PhysicalMemory and called the PhysicalMemory::read function.

Let’s read some arbitrary address from the physical memory.

First of all, let’s check the content of this physical address with WinDbg Kernel Debugger:

Now let’s load our unsigned DLL using the vulnerability, and write the output to a txt file:

As you can see, we were able to print the content of an arbitrary physical memory address easily, using the vulnerability.

Potential Malicious Uses and Impact

According to Dell’s website, SupportAssist is preinstalled on most of Dell devices running Windows. This means that as long as the software is not patched, the vulnerability affects millions of Dell PC users.

Below we show two possible ways that an attacker can leverage the vulnerability we discovered and documented above. (some of it will use the SupportAssist’s pcdsrvc_x64.pkms driver).

Signed Execution and Whitelisting Bypass

The vulnerability gives attackers the ability to loaded and execute malicious payloads by a signed service. This ability might be abused by an attacker for different purposes such as execution and evasion, for example:

1. Application Whitelisting Bypass
2. Signature Validation Bypassing

DSE Bypass

In order to load a kernel-mode driver into Windows 10 it must be digitally signed[4] by a vendor which is authorized by Microsoft. In order to enforce that, Microsoft implemented a mechanism called Driver Signature Enforcement (DSE) which crashes the OS if an unsigned kernel-mode driver is being loaded.

An attacker can get R/W primitives, provided by the pcdsrvc_x64.pkms driver which is an already loaded kernel-mode driver. In fact, the attacker might not need to load a driver because the previously loaded driver already gives them considerable control.

In order to access and manipulate the R/W primitives, the attacker can:

1. Exploit the vulnerability in order to get privilege escalation and run as SYSTEM
2. Use the pcdsrvc_x64.pkms driver which is signed and loaded
3. Send the relevant IOCTLs (or using the wrapper functions Dell provides in the DLL as we did above) in order to read / write directly the physical memory.
4. The attacker will now have a full R/W primitive, within the context of a kernel-mode driver (no need to load an additional driver, we already have one loaded, so DSE is not relevant).

Other Affected Products:

PC-Doctor Toolbox for Windows

Also re-branded as:

CORSAIR ONE Diagnostics

CORSAIR Diagnostics

Staples EasyTech Diagnostics

Tobii I-Series Diagnostic Tool

Tobii Dynavox Diagnostic Tool

Timeline

04/29/19 – Vulnerability reported

04/29/19 – Initial Response from Dell scheduled by May 7th, 2019

05/08/19 – Dell has confirmed the vulnerability

05/21/19 – Dell sent the issue to PC-Doctor

05/21/19 – PC-Doctor scheduled a fix to be released in mid-June as it affects not only Dell but multiple OEMs.

05/22/19 – CVE-2019-12280 Assigned by PC-Doctor

05/28/19 – Dell released fixes provided by PC-Doctor for affected SupportAssist versions: Dell SupportAssist for Business PCs version 2.0, and Dell SupportAssist for Home PCs version 3.2.1 and all prior versions

06/12/19 – Disclosure date extended to June 19th

06/19/2019 – Vulnerability disclosed.

References

[1] http://www.dell.com/support/contents/us/en/04/article/product-support/self-support-knowledgebase/software-and-downloads/supportassist

[2] http://www.pc-doctor.com/

[3] https://hatriot.github.io/blog/2018/05/17/dell-supportassist-local-privilege-escalation

[4] https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy–windows-vista-and-later-