October 10th, 2019
Security Researcher, SafeBreach Labs
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 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.
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” .
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.
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:
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:
We were able to load three arbitrary DLLs and execute our code as NT AUTHORITY\SYSTEM.
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.
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:
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.
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.
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.
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:
In order to load a kernel-mode driver into Windows 10, it must be digitally signed 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.
July 4th, 2019 - Vulnerability reported to email@example.com
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:
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:
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 
November 30, 2020