On a recent engagement we found Plantronics Hub (software related to video conferencing) installed on a range of client systems. It comes with its own Windows service running with SYSTEM privileges which makes it a promising target to look at for potential privilege escalation vulnerabilities.

We found an arbitrary file delete vulnerability which allows to escalate to SYSTEM and an arbitrary file read vulnerability which allows to read any file on the machine from an unprivileged user context. Versions <= 3.25.1 are vulnerable.

Overview

After installing the software, we see a new service running as SYSTEM:

Get-Service PlantronicsUpdateService | Select-Object DisplayName, @{Name="UserName";Expression={(Get-WmiObject -Class Win32_Service -Filter "Name = '$($_.Name)'").StartName}}, @{Name="BinaryPath";Expression={(Get-WmiObject -Class Win32_Service -Filter "Name = '$($_.Name)'").PathName}} 

DisplayName UserName BinaryPath 
----------- -------- ---------- 
Plantronics Update Service LocalSystem "C:\Program Files (x86)\Plantronics\Spokes3GSpokes\UpdateService.exe" install
As the name suggests, this service is used to update the program whenever a new version is available. The user-facing part of the software is running in a low privileged user context and when a user clicks the “Check for Updates” button, it somehow has to communicate with the privileged service.

Here, this communication happens via the file system – the unprivileged part of the application drops a file called “MajorUpgrade.config” into “C:\ProgramData\Plantronics\Spokes3G”. This file is then processed by the service and afterwards deleted. An abitrary file read can be achieved by crafting a special “MajorUpgrade.config” file, while privileges can be escalated by exploiting the privileged file delete.

Arbitrary File Read

The first problem occurs with the file content of this upgrade file itself. There is an existing exploit from 2020 by Markus Krell that allows to run an arbitrary binary as the updater instead of the intended one:
%username%|advertise|C:\Windows\System32\cmd.exe

This was eventually fixed and the service is now checking if the executed program is signed by the vendor & has a specific product name string (which is included in the signed part). This is, however, still vulnerable to the aforementioned file read vulnerability since the specified update file is copied to “C:\Program Files (x86)\Plantronics\Spokes3G\UpdateServiceTemp”, independent from those checks.

This target location is readable by any authenticated user and the copied file will share those permissions as well. This means it is possible to copy, for example, a file on the administrator desktop and then read it from a low privileged users context.
We set “MajorUpgrade.config” to the following content:
user|advertise|C:\users\administrator\desktop\secret.txt
After a few moments we can then read the target file from the “UpdateServiceTemp” directory as a low-privileged user:
dir "\Program Files (x86)\Plantronics\Spokes3G\UpdateServiceTemp"
 Volume in drive C has no label.
 Volume Serial Number is F6F0-B8BC

 Directory of C:\Program Files (x86)\Plantronics\Spokes3G\UpdateServiceTemp

30/01/2024  08:28    <DIR>          .
30/01/2024  08:24    <DIR>          ..
30/01/2024  08:27                56 secret.txt
               1 File(s)             56 bytes
               2 Dir(s)  34.224.492.544 bytes free

 

Arbitrary File Delete to SYSTEM

Using ProcMon we can see that checks for the existence of this update file happen regularly:
You can see that “SpokesUpdateService.exe”, which is running as SYSTEM, is trying to open a file. Should it succeed it will read it & then delete it using “SetDispositionInformationEx”.
After that the file is gone from the file system. Privileged file delete scenarios like this one are well known to be exploitable as demonstrated by Andrew Oliveau in his blog post Deleting your Way into SYSTEM.
We are abusing a race condition in the Windows Installer’s rollback functionality. During MSI installation the Windows Installer Service that is running as SYSTEM is creating “C:\Config.Msi”, which contains a .rbs file with information on how to rollback the installation if an error occurs. This folder is not accessible by default – we can, however, use Object Manager Symbolic Links to redirect our privileged file delete to this folder. We delete the “Config.Msi” folder and then recreate it with favourable permissions. At this point we can modify the .rbs file and let the Windows Installer Service execute whatever we want with SYSTEM privileges when the rollback occurs – here opening a new elevated cmd window.