From File Deletion to Domination: Exploiting Cisco’s VPN Clients for Privilege Escalation.

Preface

In today’s interconnected world, remote access to corporate networks is vital for businesses and their employees. Cisco AnyConnect Secure Mobility Client and Cisco Secure Client Software are two such solutions that cater to this need by offering secure and reliable remote connectivity – or do they?

CVE Overview

Meet CVE-2023-20178, a significant vulnerability discovered in the Cisco AnyConnect Secure Mobility Client and the Cisco Secure Client. Officially announced by Cisco on 7th June 2023 this vulnerability allows threat actors to arbirtrarily delete files and escalate their privileges on hosts running vulnerable versions of the clients. In this article, we will take an in-depth look at the Proof of Concept generated by Filip Dragović, by providing a demo of the exploit being carried out, and then a deep-dive into what is happening behind the scenes.

Running the Exploit

After downloading and compiling the exploit from github, we are left with a single executable file to run, before we establish the VPN tunnel using either AnyConnect, or Secure Client.

In the initial phase, we can see the Command Prompt displaying basic information such as the current user and their limited low-level privileges.

However, upon executing the exploit, we are now presented with an elevated Command Prompt that is running as SYSTEM, resulting in unrestricted control over the host, demonstrated by navigating to, and listing the contents of C:\Windows\System32\Config.

Attack Analysis

So what is actually happening behind the scenes? When the VPN session is initially established, Ciscos’s vpndownloader.exe is spawned as a background process, running with SYSTEM level privileges, and attempts to check for any VPN profile and/or software updates, as shown below:

Using Process Monitor from the SysInternals suite to monitor the vpndownloader.exe process.

Windows Installer Service

To understand how the vpndownloader process is exploited, it is necessary to additionally understand how the Windows Installer service operates whenever it is invoked:

• The Windows Installer service plays a crucial role in facilitating the installation of applications on Windows. It operates by leveraging an .msi file, which serves as a comprehensive database defining the specific modifications required for installing an application. These modifications encompass a wide range of actions, including the creation of folders, the copying of files, the modification of registry keys, and the execution of custom actions.
• To achieve this, the installer process enforces transactionality on all operational installs, meaning that during the installation process, the service meticulously records each change made to the system, such as:
  • Adding/removing files
  • Registry changes
  • Component registrations
  • Services and drivers
  • Any other custom actions
• Additionally, when the installer service replaces an existing file on the system with a newer version obtained from the installation package, it retains a copy of the previous version in an aditional .rbf (rollback file).

This process ensures that if the need arises to roll back the installation or uninstall the application, the service can restore the system to its original state accurately.

Monitoring the C:\Config.msi folder for the creation of .rbs files.

Exploit Breakdown

The exploit then takes advantage of this process, which uses the Windows Installer service to create a temporary file in C:\Config.msi.
When C:\Config.msi is created, the exploit then leverages default permissions that allow arbitrarily deleting or moving folders.

By deleting or moving the C:\Config.msi folder, the exploit can then recreate it with a weak Discretionary Access Control List (DACL) and replace its contents with malicious files used to elevate privileges, using the following steps:

1. The exploit creates a dummy C:\Config.Msi folder and sets an opportunistic lock (oplock) on it.
2. The vulnerable vpndownloader.exe process attempts to delete or move the C:\Config.Msi folder but is forced to wait due to the oplock placed on it.
3. Now within the exploit, the oplock callback is triggered, and several additional sub steps are executed:
   • The dummy C:\Config.Msi folder is moved to a temporary location to keep the oplock active, allowing the vulnerable process to continue waiting.
   • The exploit spawns a new thread to invoke the Windows Installer service and install a specially crafted .msi file (with the user interface disabled).
   • Once the Windows Installer service creates the C:\Config.Msi folder for the second time (indicating the start of rollback), the callback thread exits, releasing the oplock.
   • Because the oplock has been released, when the vulnerable process deletes or moves the original C:\Config.Msi folder, the exploit’s create operation succeeds and resumes to recreate the C:\Config.Msi folder with a weak DACL.
   • From within the newly created (and now with a weak DACL) Config.msi directory, the exploit waits for the Windows Installer service to create a .rbs file and again attempts to move C:\Config.msi to another temporary directory, which succeeds on the completion of the creation of the .rbs file, as the Windows Installer service closes it’s handle on this file, allowing the move operation to proceed.
   • The exploit then creates C:\Config.msi one last time and placed both a malicious .rbf and .rbs file inside the directory.
   • The Windows Installer service, at this point, is still unaware that the C:\Config.msi directory has been compromised, and continues normal operations by following the transactions recorded (maliciously created) in the rollback script.
4. Contained within the the malicious .rbs script, are, at a high-level, instructions to spawn a new Command Prompt. As a result of the this, the Windows Installer service unknowingly proceeds to roll back the changes, following the instructions to spawn a Command Prompt, which due to the process itself running as SYSTEM, spawns in the same user-level context.

Affected Clients

First and foremost it is crucial to know that this vulnerability is only known to exist on the Windows clients for Cisco’s AnyConnect Secure Mobility Client and Secure Client.

At the time of writing, the following versions are recognised by Cisco as vulnerable:

• Cisco AnyConnect Secure Mobility Client v10 or earlier, before version 4.10MR7 (4.10.07061)
• Cisco Secure Client v5 or earlier, before version 5.0MR2 (5.0.02075)

Remediation

There are no workarounds to address this vulnerability. Businesses wishing to remediate against this should update to the latest version of Cisco AnyConnect Secure Mobility Client and Cisco Secure Client.