OEM Software Puts More Than 100 Million Dell PCs/laptops (Running Windows) At Risk

Introduction

In the following article we will present a new vulnerability in Dell’s SupportAssist[1] software discovered by Safebreach Labs.

UPDATE: After we have sent the details to Dell, we found out that this vulnerability not only affects Dell SupportAssist but also more OEMs which are using a rebranded version of the PC-Doctor components. PC-Doctor didn’t want to share the list of these OEMs. Please read below to find if your laptop has the same vulnerable software installed.

Q1 hedge fund letters, conference, scoops etc

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 scenarios to which the vulnerability and the SupportAssist software can lead, such as reading physical memory (Proof-of-Concept is included) using Dell's signed driver (which is part of the SupportAssist software).

Dell SupportAssist

Dell SupportAssist[1] is a software which is preinstalled on most of Dell PCs. The purpose of the software is to proactively check the health of the system's hardware and software, which, as you probably guessed, sometimes requires high permissions. In order to run with high permissions, a signed driver is installed in addition to multiple services which are running as SYSTEM.

PC-Doctor

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

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

Vulnerability

Discovery

We targeted the "Dell Hardware Support" service, assuming it has some kind of access to the PC hardware (which requires high permissions) and that is what we wanted to achieve, in addition to privilege escalation.

Once the service is starting, it executes DSAPI.exe which 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 very interesting DLL libraries which have the ability to collect information from different sources (software and hardware). Once they were loaded we noticed the following in ProcMon (Note: We filtered the non-relevant events from the screenshot):

3 of the p5x executables are trying to find the following DLL files on the c:python27 directory (which is in my PATH environment variable):

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

Looks like a DLL hijacking vulnerability.

In my VM, the c:python27 (which is in my PATH environment variable) has an ACL which allows any authenticated user to write files to it, which makes the privilege escalation even easier and allows a regular user to write the missing DLL file and achieve code execution as SYSTEM.

In order to test that, 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 to the following names:

1. LenovoInfo.dll
2. atiadlxx.dll

Root Cause

The p5x modules (and most of the PC-Doctor code) are using a utility library named Common.dll, which provides a lot of 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 which allows defining the search order using certain flags, such as LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR which 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 without any hesitation.

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 regions.

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 interesting libraries which are loaded into the PC-Doctor .p5x executables we can find SysSpace.dll which provides us a great 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, so all we had to do is figure out which parameters we  need 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.

forfiles /M *.dll /C "cmd /c %userprofile%amd64dumpbin.exe /IMPORTS @file | findstr ?read@PhysicalMemory && echo @file"   153 ?read@PhysicalMemory@memory@libSysSpace@@QEBA_N_KPEAX0W4AccessUnit@123@@Z "NVMeInfo.dll" 153 ?read@PhysicalMemory@memory@libSysSpace@@QEBA_N_KPEAX0W4AccessUnit@123@@Z "Quip.dll"

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

All we had to do is load SysSpace.dll, define the constructor of PhysicalMemory and call to 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 Usage and Impact

According to Dell's website, SupportAssist is preinstalled on most of Dell devices running Windows, which means that as long as the software is not patched, this vulnerability probably affects many Dell users.

Below we show two examples of the potential malicious usages that an attacker can achieve with the vulnerability we found (some of it will use the SupportAssist's pcdsrvc_x64.pkms driver).

Signed Execution and Whitelisting Bypass

The vulnerability provides the ability to be loaded and executed 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 trying to be loaded.

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

In order to achieve 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).

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
• 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-

Article by Peleg Hadar, Security Researcher, SafeBreach Labs