---

Introduction

SafeBreach Labs discovered a new vulnerability in the Realtek HD Audio Driver Package, which is deployed on PCs containing Realtek sound cards.

In this post, we will demonstrate how the CVE-2019-19705 vulnerability could have been used in order to achieve defense evasion and persistence by loading an arbitrary unsigned DLL into a signed process that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability the attacker needs to have Administrator privileges.

Realtek HD Audio Driver Package

The Realtek HD Audio Driver Package is deployed with PCs which have Realtek based Audio Cards.

Vulnerability Discovery

In our exploration, we targeted the RAVBg64.exe process.

In addition to the fact that it is a signed process that runs as NT AUTHORITY\SYSTEM, this service is interesting because it is deployed with PCs which have Realtek Audio Cards . A vulnerability in such a service would have a big impact and would be interesting to many people.

After the “HD Audio Background Process” (RAVBg64.exe) starts, it executes as NT AUTHORITY\SYSTEM.

Once executed, the process tries to load RAVBg64ENU.dll and RAVBg64LOC.dll (which are not located in) its own directory:

PoC Demonstration

In order to test this vulnerability, we compiled an arbitrary DLL which writes the following to the filename of a txt file:

1. The name of the process which loaded it
2. The username which executed it

3. The name of the DLL file

   We then placed the DLL in the following paths and restarted the service:

   1. C:\Program Files\Realtek\Audio\HDA\RAVBg64ENU.dll

1. C:\Program Files\Realtek\Audio\HDA\RAVBg64LOC.dll

We were able to load an arbitrary DLL and execute our code within RAVBg64.exe which was signed by “Realtek Semiconductor” and run as NT AUTHORITY\SYSTEM.

Root Cause Analysis

RAVBg64.exe is an MFC application. MFC provides developers with an option to load localized DLLs (satellite DLLs), which only contain data (resource-only DLLs, which do not contain any code).

These are the missing DLL files which the program tried to load. You can recognize them by the suffix ENU and LOC (e.g. RAVBg64LOC.dll).

Despite the fact these are resource-only DLLs, the program loaded our DLL and executed it as a regular DLL, but why? Let’s find out.

First, let’s disassemble the program:

The program uses LoadLibraryExW without flags (dwFlags=0). It behaves exactly like LoadLibraryW.

This is the root cause of the vulnerability, and that is the reason we managed to execute our code: the program tries to load the DLL like a regular DLL, instead of calling LoadLibraryExW with the LOADLIBRARYASIMAGERESOURCE flag, which won’t execute the DLL.

But it still doesn’t make any sense, as MSDN stated that it is supposed to be loaded as a resource-only DLL.

So I kept looking for another reason.

It turns out that this specific behavior of MFC is implemented by Visual Studio (unless stated otherwise).

I tried to compile an empty MFC application using Visual Studio 2017 and test it:

As you can see in the stack trace, I couldn’t reproduce this issue in VS2017 as LoadLibraryExW calls BasepLoadLibraryAsDataFileInternal, which means that the code indeed tries to load the DLL as a data-file only (as mentioned in MSDN).

I used Detect It Easy (“DIE”) to understand which kind of compiler Realtek used in order to compile the binary, and this is what I found out:

Realtek used Visual Studio 2005 in order to compile the binary and that is the actual root cause for this vulnerability.

It appears that back in 2005, Visual Studio MFC’s implementation was trying to load the satellite-DLL as a regular library with code.

There are actually two root causes for this vulnerability:

• No digital signature validation was done on this specific binary. The program did validate whether different DLL files which it loads are signed, but when it imported the Wintrust.dll library, it didn’t validate it (because it relied on the WinVerifyTrust function which is inside the DLL and hadn’t been loaded yet). Therefore, it was able to load an arbitrary unsigned DLL.
• The usage of outdated software

In order to compile their MFC application, Realtek used Visual Studio 2005, which contains old and risky behavior such as loading a satellite DLL as an executable.

Potential Malicious Uses and Impact

Below we show three possible ways that an attacker could have leveraged the CVE-2019-19705 vulnerability which we discovered and documented above.

Signed Execution, Whitelisting Bypass

The vulnerability gave attackers the ability to load and execute malicious payloads within the context of a Realtek-Semiconductor signed process. This ability might have been abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability gave attackers the ability to load and execute malicious payloads in a persistent way, each time the services were loaded. That means that once the attacker dropped a malicious DLL, the services would load the malicious code each time it was restarted.

Affected Products and Versions

According to Realtek:

Realtek HD Audio driver package ver.8857 or newer version has fixed the issue.

The driver version earlier than 8855 was using the old version of the Microsoft development tool (VS2015).

Timeline

July 10th, 2019 – SafeBreach sent an email to Realtek’s support email.

July 18th, 2019 – SafeBreach tried to contact an email which was provided by MITRE but it was inactive.

Aug 8th, 2019 – SafeBreach asked for a Realtek Point-of-Contact on Twitter

Aug 14th, 2019 – Sent an email to another email which was provided by MITRE as well.

Aug 14th, 2019 – In their initial response, Realtek asked for some clarifications.

Aug 14th, 2019 – SafeBreach sent clarifications.

Sep 10th, 2019 – SafeBreach mentioned our 90-day disclosure policy.

Sep 11th, 2019 – Realtek asked how can they solve the issue.

Sep 11th, 2019 – SafeBreach suggested a few options to fix the issue.

Sep 27th, 2019 – Realtek asked for clarifications.

Oct 2nd, 2019 – SafeBreach sent clarifications, with a suggestion for a final solution.

Oct 2nd, 2019 – Realtek said they will try to use this solution.

Oct 7th, 2019 – Realtek provided a status update.

Oct 22nd, 2019 – SafeBreach said that 90 days have passed since SafeBreach provided an initial report and asked if there is progress on Realtek’s side.

Oct 23rd, 2019 – Realtek asked SafeBreach to wait until mid-December.

Oct 23rd, 2019 – SafeBreach agreed to wait until mid-December.

Nov 14th, 2019 – SafeBreach asked for an update.

Nov 24th, 2019 – SafeBreach said that 102 days have gone by since the initial report and that we are willing to cooperate but we need collaboration and answers.

Dec 4th, 2019 – SafeBreach asked for updates, as we didn’t want to publish our advisory before Realtek confirmed that they fixed the driver.

Dec 4th, 2019 – Realtek said that the modification is still in-progress, and not as smooth as expected. If there isno delay, they will be able to deliver the trial version by the end of the next week.

Dec 9th, 2019 – Realtek said they will provide SafeBreach with a beta driver by Friday (December 13th).

Dec 11th, 2019 – Realtek issued CVE-2019-19705 and provided the affected product and versions.

Dec 11th, 2019 – SafeBreach asked for a final date for Realtek’s public disclosure.

Jan 30th, 2020 – Realtek published a security advisory [1]

SafeBreach would like to thank MITRE’s CVE Assignment Team for providing help with the initiation of the coordination process.