---

Introduction

SafeBreach Labs discovered a new vulnerability in Check Point Endpoint Security Initial Client software for Windows.

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

Check Point Endpoint Security

Check Point Endpoint Security includes data security, network security, advanced threat prevention, forensics, and remote access VPN solutions.

Some 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 Check Point Endpoint Security Initial Client software for Windows.

We then demonstrate how this vulnerability can be exploited to achieve privilege escalation, gaining access with NT AUTHORITY\SYSTEM level privileges.

Discovery

In our initial exploration of the software, we targeted the following Check Point services:

1. “Check Point Endpoint Agent” (CPDA.exe)
2. “Check Point Device Auxiliary Framework” (IDAFServerHostService.exe)

because of the following reasons:

• It runs as NT AUTHORITY\SYSTEM – the most privileged user account. This kind of service might be exposed to a user-to-SYSTEM privilege escalation, which is very useful and powerful to an attacker.
• The executable of the service is signed by Check Point and if the hacker finds a way to execute code within this process, it can be used as an application whitelisting bypass which can lead to security product evasion.
• This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.

In our exploration, we found that once the Check Point Device Auxiliary Framework Service (IDAFServerHostService.exe) was started, the IDAFServerHostService.exe signed process was executed as NT AUTHORITY\SYSTEM.

Once executed, the service tries to load the atl110.dll Library (“ATL Module for Windows”) library and we noticed an interesting behavior:

As you can see, the service was trying to load a missing DLL file from different directories within the PATH environment variable.

Stay with us, we will analyze the root cause for trying to load the missing DLL file in the next section of the article.

PoC Demonstration

In our VM, Python 2.7 is installed. The c:\python27 has an ACL which allows any authenticated user to write files onto the ACL. This makes privilege escalation simple, allowing 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. This can be done by different applications.

In order to test this privilege escalation vulnerability, we

1. Compiled an unsigned Proxy DLL out of the original Microsoft atl110.dll (we will explain why in the Root Cause Analysis paragraph),

2. Added a custom functionality which loads an arbitrary unsigned DLL and writes the following to the filename of a txt file once the DLL is loaded:

• The name of the process which loaded it
• The username which executed it
• The name of the DLL file

Root Cause Analysis

Once the “Check Point Device Auxiliary Framework” service (IDAFServerHostService.exe) is started, it loads the iDAFServer.dll library.

Using CoCreateInstance, the iDAFServer.dll library initializes a logger COM object of the following CLSID: 465DB11A-B20F-4C84-84B6-1EA5213D583A:

A brief look at OleViewDotNet (or at the registry) will show us that this logger COM class is implemented within the “daf_logger.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 daf_logger.dll library is called, the imported AtlComModuleGetClassObject function is called:

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

The atl110.dll library is deployed with Microsoft Visual Studio Redistributable 2012 package, which wasn’t installed with the Check Point software, therefore, the DLL is missing.

There are two root causes for this vulnerability:

• The lack of safe DLL loading due to having an uncontrolled search path – In this case, it is necessary to use the SetDefaultDllDirectories function in order to control the paths from which a DLL can be loaded within the scope of the executable.
• No digital certificate 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.

Potential Malicious Uses and Impact

Below we show three possible ways that an attacker can leverage the Check Point Device Auxiliary Framework Service vulnerability we discovered and documented above.

Signed Execution and Whitelisting Bypass

The vulnerability gives attackers the ability to load and execute malicious payloads using a signed service. This ability might be abused by an attacker, for example to achieve Application Whitelisting Bypass for purposes such as execution and evasion.

Persistence Mechanism

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

Privilege Escalation

After an attacker gains access to a computer, he might have limited privileges which can limit access to certain files and data. The service provides him with the ability to operate as NT AUTHORITY\SYSTEM which is the most powerful user in Windows, so he can access almost every file and process which belongs to the user on the computer.

Affected Versions

• Check Point Endpoint Security Initial Client for Windows – Below Version E81.30
• Files I used for analyzing the root cause:
• iDAFServerHostService.exe – 8.60.5.6825
• iDAFServer.dll – 8.60.5.6825
• daf_logger.dll – 8.60.5.6802

Timeline

Aug 1th, 2019 – Vulnerability Reported

Aug 4th, 2019 – Initial Response from Check Point

Aug 6th, 2019 – Check Point asked for clarification

Aug 6th, 2019 – Check Point has confirmed the vulnerability

Aug 19th, 2019 – Check Point provided a schedule for a fix

Aug 27th, 2019 – Check Point has released a patched version (E81.30) [1], published an advisory and issued CVE-2019-8461.

References

[1] Check Point Enterprise Endpoint Security E81.30