---

Introduction

SafeBreach Labs discovered a new vulnerability in HP Touchpoint Analytics software.

In this post, we will demonstrate how this vulnerability can be used in order to achieve privilege escalation and persistence by loading an arbitrary unsigned DLL into a service that runs as SYSTEM.

Additionally, we will present some of the potential malicious actions that could be undertaken by exploiting this vulnerability in the HP Touchpoint Analytics software.

This post provides a proof-of-concept for reading physical memory using a 3rd party, signed driver named “WinRing0”, which is deployed with the Touchpoint Analytics software.

HP Touchpoint Analytics

HP Touchpoint Analytics is a service which is preinstalled on most HP PCs. The service anonymously collects diagnostic information about hardware performance.

The service is executed as “NT AUTHORITY\SYSTEM,” which provides it with very powerful permissions.

Open Hardware Monitor

The components which allow HP Touchpoint Analytics to access sensitive, low-level hardware (such as physical memory, MSRs and SMBios) are provided by an open source hardware monitoring library which is called “Open Hardware Monitor” [1].

The Open Hardware Monitor library provides a signed kernel driver named “WinRing0,” which is extracted and installed during runtime.

In this post, we describe the vulnerability we found in the HP Touchpoint Analytics and Open Hardware Monitor components. We then demonstrate how this vulnerability can be exploited to achieve privilege escalation, gaining access with SYSTEM level privileges.

Vulnerability Discovery

In our initial exploration, we targeted the HP Touchpoint Analytics service based on the assumption that 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 HP Touchpoint Analytics service started, it executed TouchpointAnalyticsClientService.exe as NT AUTHORITY\SYSTEM.

Once executed, the PerformanceMonitor class of the service loaded the signed OpenHardwareMonitor 3rd-party library (mentioned above), enabling three diagnostic checks: GPU, CPU and RAM:

Next, the service loaded the OpenHardwareMonitorLib.dll 3rd-party library.

This library has the ability to collect information from different hardware sources.

Once the library was loaded, we noticed the following activity in ProcMon:

Note: We filtered the irrelevant events from the above screenshot.

As you can see, the service was trying to load three missing DLL files, which eventually were loaded from the c:\python27 directory – our PATH environment variable:

1. atiadlxx.dll
2. atiadlxy.dll
3. Nvapi64.dll

Stay with us, we will analyze the root cause in the next section of the article.

Demonstrating a DLL hijacking vulnerability:

In our 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 NT AUTHORITY\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.

We were able to load three arbitrary DLLs and execute our code as NT AUTHORITY\SYSTEM.

Root Cause Analysis

Once the OpenHardwareMonitor library is loaded, it initializes GPU check classes, then it tries to load Nvidia and ATI DLL libraries in order to use their APIs.

The ATI Logic

Here you can see the system loading the ATI DLL libraries – atiadlxx.dll and atiadlxy.dll in order to use their APIs.

The Nvidia Logic

Here you can see the system loading the Nvidia DLL library – NVApi64.dll in order to use its APIs.

As we can see in the screenshots, there are two root causes for the vulnerability:

• Uncontrolled Search Path – The lack of safe unmanaged DLL loading.
  The library tried to load the mentioned unmanaged DLL files using DllImportAttribute. The problem is that it used only the filename of the DLL, instead of an absolute path. In this case, it’s necessary to use the DefaultDllImportSearchPathsAttribute class in order to control the paths from which the DLL can be loaded.
• No digital certificate validation is made against the binary. The program doesn’t validate whether the DLL that it is loading is signed. Therefore, it can load an arbitrary unsigned DLL.

Exploitation (R/W to Physical Memory)

Open Hardware Monitor Signed Driver

As mentioned above, HP deploys the Touchpoint Analytics software with the Open Hardware Monitor library for hardware diagnostic purposes, which uses a 3rd-party signed driver in order to perform some of the low-level operations.

We will demonstrate how after we used this vulnerability to gain NT AUTHORITY\SYSTEM privileges. We also managed to read data from the physical memory using the signed driver.

PoC – Reading Physical Memory

The Open Hardware Monitor library is fully open-source, which means that its driver is also open-source.

Among the functionality which is exposed by the driver, there’s an option to read/write to/from the physical memory by sending a specific IOCTL. We used the code snippet that implements the appropriate structs, sends an IOCTL to the driver, and returns the content of a physical memory address.

Afterwards, we compiled it into a DLL and loaded it as SYSTEM using the vulnerability.

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

For this particular example, we used address 0xC00F0. The driver allows access to read between 0xC0000 and 0xFFFFF.

First of all, let’s check the content of this physical address with WinDbg, the kernel-mode 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

HP Touchpoint Analytics is preinstalled on most HP devices running Windows.

Below we show two possible ways that an attacker can leverage the vulnerability we discovered and documented above, some using the OpenHardwareMonitor’s signed driver.

Signed Execution and Whitelisting Bypass

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

• Application Whitelisting Bypass
• Signature Validation Bypassing

Driver Signature Enforcement (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 loaded.

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

Affected Products

• HP Touchpoint Analytics Client – All versions below 4.1.4.2827

Timeline

July 4th, 2019 – Vulnerability reported to [email protected]

July 11th, 2019 – Initial response from HP PSRT: Assigned case number PSR-2019-0143.

July 25th, 2019 – We asked for a status update

Aug 2nd, 2019 – HP PSRT confirmed the vulnerability and wanted to thank us by “assigning a CVE-ID and stating your name in the security bulletin”.

Aug 2nd, 2019 – We asked for the CVE ID, date of fix and patched version to include in our public advisory.

Aug 2nd, 2019 – HP PSRT said they will respond with the requested information on August 6th, and asked for a draft copy of the blog post.

Aug 3rd, 2019 – We asked if HP is going to release the security bulletin on August 6th, and asked for details of the patch again.

Aug 7th – HP deployed a patch to customers.

Aug 8th, 2019 – We mentioned our disclosure policy to HP PSRT: “Our responsible disclosure policy is inspired by Google Project Zero: Bugs found by the SafeBreach Lab team are reported to the manufacturer and only made publicly visible once a patch has been released or if 90 days have passed without a patch being released.”

Sep 4th, 2019 – We sent a 60 days (out of 90 days) alert to HP PSRT, saying that we prefer to work together with the PSRT team in order to release our public advisory after the problem will be fixed.

Sep 5th, 2019 – HP PSRT said that:

1. They are working with the product team on the details of the security bulletin, and that they will provide an update.
2. They mentioned that their intention is to do a coordinated disclosure with us.
3. They appreciate our 90 days policy and would like to stick to that.

Sep 14th, 2019 – HP PSRT provided us with CVE ID: CVE-2019-6333, and asked for a copy of the blog post.

Sep 14th, 2019 – We sent an encrypted copy of the blog post. We asked again for the remaining details for our public advisory (date of fix, affected products and versions).

Sep 21th, 2019 – We sent a 77 days (out of 90 days) alert to HP PSRT, asked for the details again, and mentioned that we would like to work in good coordination but the lack of communication makes it very difficult for us.

Sep 26th, 2019 – We sent a 83 days alert to HP PSRT, and mentioned that:

1. We haven’t heard you back for 12 days.
2. We are going to publish our public advisory in 7 days, sticking to the 90-days disclosure policy.
3. We would like to work in good coordination with you, but the lack of communication makes it very difficult for us.

Sep 26th, 2019 – HP PSRT said that they are still finalizing the bulletin details and that their plan is to publish the security bulletin on Oct. 4th, 2019.

Sep 26th, 2019 – I asked for the details once they are finalized so we can use them in our advisory.

Oct 04th, 2019 – HP has published a security advisory [2]

References

[1] https://github.com/openhardwaremonitor/openhardwaremonitor

[2] https://support.hp.com/us-en/document/c06463166