---

Introduction

SafeBreach Labs discovered a new vulnerability in Symantec Endpoint Protection software.

In this post, we will demonstrate how this vulnerability could have been used in order to bypass Symantec’s Self-Defense mechanism and achieve defense evasion, persistence and privilege escalation by loading an arbitrary unsigned DLL into a process which is signed by Symantec and that runs as NT AUTHORITY\SYSTEM.

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

Symantec Endpoint Protection

Symantec Endpoint Protection is a security software suite, consisting of anti-malware, intrusion prevention and firewall features for server and desktop computers. It was developed by Symantec and has the largest market-share of any product for endpoint security.

Multiple parts of the software run as a Windows service executed as “NT AUTHORITY\SYSTEM,” which provides it with very powerful permissions.

In this post, we describe the vulnerability we found in the Symantec Endpoint Protection software. We then demonstrate how this vulnerability can be exploited to achieve arbitrary code execution within the context of a Symantec service, gaining access with NT AUTHORITY\SYSTEM level privileges.

Vulnerability Discovery

In our exploration, we found a service (SepMasterService) of the Symantec Endpoint Protection which is running as signed process and as NT AUTHORITY\SYSTEM, which is trying to load the following DLL which doesn’t exist:

c:\Windows\SysWOW64\wbem\DSPARSE.dll

If we can prove that we can actually be loaded into this process, we will be able to bypass the self-defense mechanism of the antivirus software, mainly because the folders of the Symantec Endpoint Protection software are protected by a mini-filter filesystem driver, which restricts writing operations even by an Administrator.

That means that even if we are running as an Administrator and we will want to implant a DLL which doesn’t exist in order to load it into Symantec’s processes, we won’t be able to do that.

PoC Demonstration

In order to test this vulnerability, we compiled a 32-bit Proxy DLL (unsigned) out of the original dsparse.dll DLL file (which is actually located in SysWow64 and not in the SysWow64\Wbem folder) 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 implanted it in C:\Windows\SysWow64\Wbem, and restarted the computer:

We were able to load an arbitrary Proxy DLL (which loaded another arbitrary DLL) and execute our code within a service’s process which is signed by Symantec Corporation as NT AUTHORITY\SYSTEM, resulting in bypassing the self-defense mechanism of the program.

Root Cause Analysis

There are multiple components in multiple files which cause this issue, we will analyze one of it because the root cause is always very similar.

Once the “Symantec Endpoint Protection” service’s process (ccSvcHst.exe) is started, it tries to execute a WMI query using a function of the IWbemServices COM interface (IWbemServices::ExecNotificationQueryAsync)

A brief look at OleViewDotNet will show us that this COM interface (and its functions) is implemented using the COM Proxy DLL “C:\Windows\SysWow64\wbem\fastprox.dll” library (in our case it’s a WOW64 process):

After the ExecNotificationQueryAsync function of the fastprox.dll library is called, the DsCrackSpnW function will be called:

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

There are two root causes for this vulnerability:

• No digital signature validation is made against the binary. The program does not validate whether the DLL that it is loading is signed (for example, using the WinVerifyTrust function). Therefore, it can load an arbitrary unsigned DLL.

• The fastprox.dll library is trying to import the dsparse.dll from it’s current working directory (CWD), which is C:\Windows\SysWow64\Wbem, while the file is actually located in the SysWow64 folder.

Potential Malicious Uses and Impact

Below we show three possible ways that an attacker can leverage the vulnerability we discovered and documented above.

Defense Evasion, Signed Execution, Whitelisting Bypass

The vulnerability gives attackers the ability to load and execute malicious payloads within the context of a Symantec’s signed process. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass. The Antivirus might not detect the attacker’s binary, because it tries to load it without any verification against it.

Persistence Mechanism

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

Privilege Escalation

The services provides him with the ability to operate as NT AUTHORITY\SYSTEM.

Affected Versions

All versions prior to Symantec Endpoint Protection 14.2 RU2

Timeline

Aug 5th, 2019 – Vulnerability reported to Symantec

Aug 6th, 2019 – Symantec confirmed the vulnerability

Aug 22nd, 2019 – Symantec provided a timeline for a fix.

Sep 16th, 2019 – Symantec said they will follow-up in Mid-October with finalized timeline and will also assign a CVE.

Oct 15th, 2019 – Status Update from Symantec

Oct 19th, 2019 – Symantec provided a finalized timeframe (an advisory will be published on November 11th).

Oct 21st, 2019 – Symantec provided affected products and versions.

Oct 31st, 2019 – Symantec issued CVE-2019-12758