Pulse Secure client arbitrary file write Elevation of Privilege (CVE-2018-11002)

Published on Wed 20 March 2019 by @clavoillotte
Edited on Tue 04 June 2019

Product: Pulse Secure client for Windows, tested on versions 5.3r3.0 and 9.0r2.0

Type: Local Privilege Escalation

Summary: The permissive access rights on log folder, files and shared memory section, as set by the Pulse Secure client’s logging service, can be abused to create arbitrary files with write access. This can be used by an unprivileged user to obtain SYSTEM privileges on the local machine.

This vulnerability was (first) discovered independently by Matt Bush, and is currently unpatched (despite the CVE entry stating otherwise).

Update: Pulse has published a fix in version 9.1R1

Description

The Pulse Secure client creates log files in C:\ProgramData\Pulse Secure\Logging. The log files are created by privileged (SYSTEM) processes (notably PulseSecureService.exe) without impersonation, and are made writable by the Everyone group (presumably because both user and system processes write to the file):

Another vector is the share memory section used by the logging service, which also have a permissive ACL set:

This section contains the path to the log file that the service will use. This path can be modified by unprivileged users (e.g. using the EditSection tool from sandbox-attacksurface-analysis-tools):

A general explanation on privileged file operation bugs is available here.

To exploit this specific bug from an unprivileged user session, one can make the privileged process create and arbitrary target file via at least 2 methods:

• Delete logs, replace the C:\ProgramData\Pulse Secure\Logging directory by a junction to the \RPC Control\ object directory, and create an object manager symlink named debuglog.log in it that points to the path of the target file.
• Replace the log file path by the path of the target file directly in the memory section.

The logging service will create the file and set the same permissive ACL on it, giving Everyone write access to the file.

Proof of Concept

I’ve made a C# PoC (available here) that will use this vulnerability to create arbitrary files.

Interesting tidbits from the PoC:

• It uses the shared memory section vector, and (re)starts the user client to trigger log creation by the logging service
• To prevent the created file from being write-locked by the logging service, it adds an alternate data stream to the path written into the shared memory section
• It creates a temporary junction to avoid some path redirection (from C:\Windows\System32 to C:\Windows\SysWOW64) when the logging service writes the log file

You will need the NtApiDotNet library to compile it.

Below is a screenshot of it in action, creating an evil.dll file in C:\Windows\System32 and loading it in the DiagHub service (FakeDllLoader.exe) to obtain a SYSTEM shell:

Fix

While the CVE entry indicates that only “Pulse Secure Desktop Client 5.3 up to and including R6.0 build 1769” are vulnerable, our testing on the latest available version (9.0r2.0) as of 2019-03-04 show that the vulnerability is still unfixed. The vendor was notified in July 2018 but has yet to release a patch.

Update: Pulse has published a fix in version 9.1R1

References

https://www.themissinglink.com.au/security-advisories-cve-2018-11002

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11002

Timeline

2018-07-02: Initial report sent to vendor

2018-07-02: Vendor acknowledges reception of report

2018-07-05: Complement report sent to vendor, indication access rights misconfiguration also impacts the shared memory section

2018-07-05: Vendor confirms the vulnerability, indicates the report is a duplicate

2018-07-23: Follow-up email sent to vendor

2018-07-23: Vendor confirms the evaluation is in progress

2018-08-14: Vendor confirms the vulnerability, indicates they are working on a fix

2018-10-24: Follow-up email sent to vendor requesting a timeline (no response)

2018-10-24: Publication of https://www.themissinglink.com.au/security-advisories-cve-2018-11002

2019-01-17: Follow-up email sent to vendor, indicating the vulnerability is already public and that we will publish a complement in March (no response)

2019-03-20: Publication of this advisory

2019-03-29: Vendor indicates they are working on a fix

2019-05-22: Vendor indicates the release of a fix in version 9.1R1