---

Introduction

SafeBreach Labs discovered a vulnerability in all of the editions of Avast Antivirus and AVG Antivirus.

In this post, we will demonstrate how this vulnerability could have been used in order to achieve self-defense bypass, defense evasion, persistence and privilege escalation. Particularly, we will show that it was possible to load an arbitrary unsigned DLL into multiple processes that run as NT AUTHORITY\SYSTEM, even using Protected Process Light (PPL).

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

AVG Antivirus / Avast Antivirus

AVG Antivirus and Avast Antivirus are both maintained by Avast Software.

In the following blog post we will talk about the AVG Antivirus, but it also affects the Avast Antivirus because the core code for all the editions of Avast Antivirus and AVG is shared so all of those products behave the same way.

Vulnerability

Discovery

In our exploration, we targeted AVGSvc.exe, which is an AM-PPL (Anti-Malware Protected Process Light), run as a signed process and as NT AUTHORITY\SYSTEM.

When started, AVGSvc.exe tries to load the wbemcomn.dll from C:\Windows\System32\wbem\wbemcomn.dll, which is not there. Instead it is in the System32 folder.)”

We tried to load an arbitrary DLL into this process using this behavior. This is interesting because of the following reasons:

1. The Antivirus has a self-defense mechanism which monitors its folders using a mini-filter driver, so even an Administrator couldn’t write and implant a DLL to the Antivirus’ folders:
   
   If we can implant an unsigned DLL in an unprotected folder, this can lead to self-defense bypass.
2. Loading unsigned code into an AM-PPL is generally not allowed, because of the code integrity mechanism. Any non-Windows DLLs that get loaded into the protected process must be signed with an appropriate certificate.

PoC Demonstration

In order to test this vulnerability, we compiled an unsigned proxy DLL out of the original wbemcomn.dll, which loads another unsigned DLL. This unsigned DLL 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 it in the following path and restarted the computer:
C:\Program Files\System32\wbemcomn.dll

We were able to load an arbitrary DLL and execute our code into AVGSvc.exe which is AM-PPL, signed by AVG Technologies and running as NT AUTHORITY\SYSTEM.

Root Cause Analysis

We will describe the root cause by using a specific DLL as an example, but it can be found in multiple places in the code.

Once the AVGSvc.exe process is started it loads the TuneupSmartScan.dll library.

In order to perform WMI operations, the TuneupSmartScan.dll library calls CoCreateInitialize to initialize an instance of the IWbemLocator COM interface:

A brief look at OleViewDotNet (or at the registry) will show us that this COM class is implemented within the “wbemprox.dll” library, which means that once the COM object is initialized, this library will be loaded and the exported “DllGetClassObject” function will be called:

Once the DllGetClassObject function of the wbemprox.dll library is called, the imported “CWin32DefaultArena::WbemMemAlloc” function is called:

We can see that this function is imported from wbemcomn.dll, which causes the process to try and load this DLL.

The reason it tries to load it from C:\Windows\System32\wbem instead of System32 is that this is the current working directory of the wbemprox.dll.

To summarize, there are two root causes for these vulnerabilities:

• The lack of safe DLL loading:
  Although the root cause was found within one of Microsoft’s DLLs, it might cause risk to the Antivirus users and might lead to self-defense bypass (as I mentioned before).Additional precautions must be taken in advance, for example: If there is a WMI usage in the code, the developer can use LoadLibraryExW when the program starts in order to load wbemcomn.dll from its absolute and real path. Once the WMI logic occurs, it won’t try to load wbemcomn.dll because it will already be loaded into the process.

• Code integrity is not enforced in the AM-PPL process: According to Avast, currently the PPL restriction regarding signed DLLs (code integrity) is disabled in their implementation. As we demonstrated, this might lead to self-defense bypass.

Potential Malicious Uses and Impact

Below we show three possible ways that an attacker can leverage these vulnerabilities, which we discovered and documented above.

Signed Execution, Whitelisting Bypass

The vulnerability gives attackers the ability to load and execute malicious payloads using multiple signed services, within the context of AVG / Avast signed processes. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.

Self-Defense Bypass

The Antivirus has a self-defense mechanism which prevents an attacker from tampering with its processes and files. Part of the mechanism is to use a mini-filter driver in order to monitor and prevent any changes to the directories of the Antivirus application, so an attacker could not implant an arbitrary DLL, for example.

The vulnerability allows an attacker to bypass this part of the mechanism and load an arbitrary DLL into the Antivirus process.

Persistence Mechanism

The vulnerability allows an attacker to load and execute malicious payloads in a persistent way, each time the services are loaded. That means that once the attacker drops a malicious DLL, the services will load the malicious code each time it is restarted.

Affected Versions

• All the editions of Avast Antivirus below version 19.8
• All the editions of AVG Antivirus below version 19.8.

Timeline

Aug 16th, 2019 – Vulnerability reported to Avast.

Aug 16th, 2019 – Initial response from Avast.

Sep 3rd, 2019 – Status update from Avast.

Sep 26th, 2019 – Avast confirmed the vulnerability and released version 19.8 for AVG and Avast.

Oct 2nd, 2019 – MITRE added the vulnerability to its list of CVEs with the following ID: CVE-2019-17093.

Oct 7th, 2019 – Avast requested two weeks notice before publishing the advisory.