Windows unquoted service path enumeration vulnerability-Is this still a concern?

A bit of background:

‘Windows Unquoted Path Enumeration vulnerability’ was identified few years ago and most applications have released multiple versions after identifying this issue however, this is still worth verifying regularly which apparently where this article comes from.

In simple terms, when a service is created whose executable path contains spaces and isn’t enclosed within quotes, leads to a potential vulnerability called ‘Unquoted Service Path’ which allows a general user to gain SYSTEM privileges (only if the vulnerable service is running with SYSTEM privilege level which most of the time is the case). In Microsoft Windows, if the service is not enclosed within quotes (“”) and is having spaces, it would handle the space as a break and pass the rest of the service path as an argument. Apparently, this vulnerability allows an attacker to escalate the privilege for NT AUTHORITY/SYSTEM for a low-level privilege user account which is extremely dangerous.

How to replicate/test this vulnerability:

p align=”justify”>You can easily recognize this by running a script that I have pointed out below but additionally, if you’re keen to try this in a test environment, you can download one of the applications listed in the CWE ID 428.

https://www.cvedetails.com/vulnerability-list/cweid-428/vulnerabilities.html

One of the sample app we can use to test this in a test (isolated) environment is, ‘BitComet’. BitComet Service for Windows before version 1.8.6 contains an unquoted service path vulnerability which allows attackers to escalate privileges to the system level.

After Installing BitComet v.1.7 for test in my test lab:

As you can see below, the ImagePath in the registry (run “regedit” from the run command) is clearly unquoted and it means this app makes the device/environment vulnerable to a potential hacker.

Actions/Recommendations: As there is no simple patch/fix from Microsoft to fix these kind of vulnerabilities, the best way is to regularly analyse the devices (or asses every 3^rd party application before onboard them in to the corporate environment) to ensure they’re not compromised. A group of Github contributors have done a fantastic job putting together a PowerShell script that analyse, detect and fix these paths in your Windows devices if there’s any.