Title: Pulse Secure Client Authentication Bypass
Version: Pulse Desktop Client 9.0R1 and 5.3RX before 5.3R5.
Researcher(s): Nassar Amin, Ricardo Ramos, Russel Crozier and Dominic Chell
Disclosure Date: 01-03-2018
Public Disclosure Date: 07-09-2018
Vendor Reference: Pulse
An unauthenticated user with physical access is able to gain SYSTEM privileges on a Windows workstation prior to OS authentication due to a weakness in the Pulse Desktop Client 9.0R1 and 5.3RX before 5.3R5. The vulnerability provides full interactive access to the operating system.
Pulse Secure Client automatically attempts to connect to a pre-configured VPN service following an attempted Windows authentication (any credentials can be used). If the connection is disrupted (e.g. pulling out the ethernet cable) the Pulse Secure Client displays an error prompt requesting the user to enter proxy server configuration details, including a server address, username and password.
By default, the Pulse client attempts to connect to the configured proxy service on TCP port 80; supplying the configuration for a proxy server with a self-signed certificate forces the Pulse client to warn the user that the certificate is invalid but provides the option to “View” the certificate which when selected loads the standard Windows certificate wizard running as SYSTEM. From the Windows certificate wizard it is possible to select the option to export the certificate, then browse to a location where the certificate should be stored on the file system. Inevitably this provides the option to browse to cmd.exe, right click to obtain a command prompt as SYSTEM and full access to the workstation.
01/03/2018: MDSec reported vulnerability to Pulse Secure Product Security, PSIRT.
07/03/2018: PSIRT acknowledge receipt of vulnerability and request technical details.
07/03/2018: MDSec provide PGP encrypted technical report to PSRIT.
20/03/2018: PSIRT respond requesting further details.
23/03/2018: MDSec provide further support to PSIRT, send additional PGP encrypted technical report.
29/03/2018: PSIRT respond advising the issue requires a physical breach, at most this is more of an OS issue.
29/03/2018: MDSec reply to PSIRT indicating the intention to disclose the issue publicly.
30/03/2018: PSIRT respond requesting MDSec hold off disclosing the issue publicly for internal Dev teams to issue a fix.
30/03/2018: MDSec agree to holding off public disclosure.
03/04/2018: PSIRT confirm internal Dev teams have identified a fix and are working towards implementation.
07/09/2018: Public disclosure