When a Denial of Service matters: fighting with risk assessment guys

During a recent Red Team operation we have been asked to attempt the takeover of a domain controller server in a Windows network. After wandering around the LAN for a while, we got stuck inside a machine where we could see a domain admin who had an open session there (Bloodhound’s power), but our low privileges did not allow to dump the LSASS’s memory to retrieve the credentials and play our usual (in these cases) impersonation tricks. Like most of the other systems in the network, in this compromised machine a low privileged user could install software on-demand via Microsoft System Center Configuration Manager.

However, after a quick check, we noticed that all software distributed through SCCM came with the latest versions available. Amongst the various applications, there were some whose installation could be started by an unprivileged user but, at the end of this process, showed at least one component running in privileged mode. One of such applications was Plantronics HUB.

Poly (annual revenue 1,2 USD billion) is the company behind the Plantronics brand producing audio devices for the segments business and consumer. Their software, Plantronics HUB, allows the end users to customize the settings and view the status of the audio devices plugged in a system.

After its installation a new service called “SpokesUpdateService.exe” shows up in the system. It is part of Plantronics HUB and runs as “NT_AUTHORITY\SYSTEM”.

The service continuously polls the filesystem for a file named “C:\ProgramData\Plantronics\Spokes3G\MajorUpgrade.config”.

If the file is found, some processing happens. Then it is disposed. As the content of the folder “C:\ProgramData\Plantronics\Spokes3G\” can be modified by any unprivileged user in the system, it is possible to create a symlink between “C:\ProgramData\Plantronics\Spokes3G\MajorUpgrade.config” and an arbitrary file located somewhere else in the filesystem, by means of the utility “CreateSymlink.exe” (part of google symboliclink testing tools). This condition allows to delete arbitrary files.

Arbitrary File delete: exploitation steps

Let’s assume an unprivileged user wants to delete the file “c:\windows\system32\license.rtf”. Of course it resides inside “c:\windows\system32”, so a user couldn’t erase it under normal conditions.

First let’s verify the file is actually there:

C:\Users\redteam\Desktop>dir c:\windows\system32\license.rtf
[...]
Directory of c:\windows\system32
03/09/2021 02:20 PM 538 license.rtf <--

Then the content of “C:\ProgramData\Plantronics\Spokes3G\” is moved somewhere else, so that the folder remains completely empty. The utility “CreateSymlink.exe” internally makes use of a junction and this requires the source folder to be completely empty.

Finally a symlink is created between “C:\ProgramData\Plantronics\Spokes3G\MajorUpgrade.config” and “C:\windows\system32\license.rtf”:

In a matter of milliseconds the file “license.rtf” is automatically deleted from the filesystem.

Of course one may decide to erase DLLs or documents of other users (if the full path of the target file in the filesystem is known) and try to put the system in an unstable state. But what’s the point here? What’s the danger?

If our red team exercise stopped now, what the outcome of a risk assessment would be? Ok, as an attacker we cause a local DoS in the system. And then? Certainly this would bring to a low impact and as a consequence a low risk. But we know that erasing an arbitrary file should not be considered only for what it looks like. Often can be the forerunner for something else.

At Red Timmy, for example, we remember very well how the RCE on Flexpaper web application was found. The vulnerable code path that allowed for remote commands execution was only reachable in case the application was in an uninitialized state. And to put the application in a state like that, after its installation, a configuration file had to be deleted.

To remain more consistent with the scope of the attack scenario we are describing in the hereby article, it is not the first time that a file delete bug leads to escalation of privileges in a system. Here a recent example.

And it is just due to these past experiences that we have decided to dig more on the Plantronics HUB arbitrary file delete bug. Remember, the forerunner for something else…

More analysis

So the process “SpokesUpdateService.exe” is trying to access “C:\ProgramData\Plantronics\Spokes3G\MajorUpgrade.config” as “NT_AUTHORITY\SYSTEM”. But what is actually that file?

From the previous analysis of another researcher conducted in 2019 we know that “MajorUpgrade.config” is a simple text file formatted as follows:

“<username>|advertise|<path_to_binary>”

with “<username>” being the name of the currently logged-in unprivileged user and “<path_to_binary>”… well, you guessed it!

Since CVE-2019-15742 a check has been introduced on Plantronics HUB aimed to verify that “<path_to_binary>” is a valid signed file. So, it is not possible anymore to provide an arbitrary resource to execute.

Indeed we confirmed that if the binary contains a valid signature, eventually it is executed with the rights of “NT_AUTHORITY\SYSTEM”.

As evincible from the procmon screenshot above, the “<path_to_binary>” we have specified inside “MajorUpgrade.config” is pointing to the file “WMIProviderInstaller.msi”. There is nothing special with such a resource, except it is just one of the binaries released by the vendor itself, downloadable from the Poly website and which embeds a signature Plantronics HUB recognizes as valid.

Passing the validity check, the “WMIProviderInstaller” MSI package is installed by means of “msiexec.exe”.

What does that mean? It means there is a TOCTOU vulnerability here. Such a behaviour can be reliably exploited 100% using an exclusive oplock through the “SetOplock” utility of the Google symboliclink testing toolkit.

The idea is to replace “WMIProviderInstaller.msi” after its signature has been validated with an arbitrary binary, before msiexec executes it.

From DoS to EoP

Ok, our initial stance in the target system where Plantronics HUB application has been installed is the following. We have downloaded:

…and copied both of them inside the same directory, as shown below:

Here  “evil.msi” is a simple C compiled file that when executed opens a “cmd.exe” prompt via “system()“. It is finally packed as an MSI binary.

At this point an exclusive oplock is set for “msiexec.exe”:

Then the file “MajourUpgrade.config” is created inside “C:\ProgramData\Plantronics\Spokes3G” with the value “<path_to_binary>” pointing to the filesystem location where “WMIProviderInstaller.msi” has been stored to.

The oplock is immediately triggered…

Now “evil.msi” can be manually renamed as “WMIProviderInstaller.msi”.

The oplock is finally released by pressing ENTER inside the SetOpLock window and a privileged command prompt opens in a blink of an eye:

Additionally the file “MajourUpgrade.config” has been deleted from the filesystem, as part of the normal data processing path of the application. Sweet. We started from a DoS and ended up to achieve EoP. Affected versions of Plantronics HUB include the latest available in the moment we write (3.21). Marco Ortisi has created an automated PoC. Due to the simplicity of this bug, we are not planning to release the code.

End of the road

Useless to say after escalating our privileges to “NT_AUTHORITY\SYSTEM” this vulnerability has allowed us to dump the memory of the LSASS process inside the compromised Windows server, retrieve the credentials of a domain admin user, impersonate that session and from there complete our chain up to add ourselves to the Domain Admin Group.

The entire environment was configured decently, but the weakest link in the chain has proved to be a third-party component installed via SCCM. Now in the risk assessment we have got a high impact finding.

Final considerations

There are so many cases where a Denial of Service bug has been initially underrated by risk assessment guys that we can be witness of. Recently Marco Ortisi has found for RedTimmy Security a DoS bug in the latest version of the VPN solution Pulse Connect Secure (PCS). The exploit crashes the remote service. After the crash a watchdog process is in charge to reload it again within few seconds. Because of this, try to guess what the assessment guys said about the case? Low impact bug and consequently low risk, of course. Just normal business.

However it has turned out that the affected component is the one responsible for remote client authentication (normally happening via HTTPS) and the bug can be turned into a perpetual denial of service. It means that while the attack is ongoing, nobody can remotely authenticate to the VPN. Furthermore, it is a pre-auth vulnerability. It means the attack can be launched by an anonymous user on the internet without valid credentials.

It looks definitely scary during a pandemic, when everybody is forced to work from home. Hence expose the facts to the risk assessment guys exactly like this, tell them a story about business productivity decrease and look at how they change their minds.

Although we are not ready to publicly release the full details of PCS bug yet, for sure we will do that during our Practical Web Application Hacking Advanced course at Blackhat this year on Jul 31st / Aug 1st () and Aug 2nd / Aug 3rd … it’s implied along with other juicy vulnerabilities! Again this year the Blackhat trainings will be delivered online! We really hope to see you in our class.

Meanwhile we have got a question for you: did we manage to turn the Pulse Connect Secure Server denial of service bug to something else? Bets are open.