PrivEsc: Unquoted Service Path

One method for escalating permission from Local/Domain User to Local Administrator, is “Unquoted Service paths”. In my experience finding unquoted service paths is a common occurrence, however actually being able to exploit them is not. In this article we’ll explore how to find these issues and how to quickly determine if they’re exploitable or not.

If a service is vulnerable a threat actor may be able to escalate privileges to the level of the account that starts the service. A service is vulnerable if the path to the executable has a space in the filename and the file name is not wrapped in quote marks; exploitation requires write permissions to the path before the quote mark.

It’s that last part which is generally the problem in my experience as by default since Windows XP this has not been possible under default configuration. I have however seen on penetration tests where default permissions have been modified and therefore exploitation is possible.

You can use the following command to determine if there are any potentially vulnerable services:

wmic service get name,pathname

This will show the name of each service and its executable (showing whether or not the path is quote wrapped.

If you can see a service which has a path that includes a space but the path is not wrapped in quote marks then it is potentially vulnerable. Now for this to be worth while the service must run with higher privileges than I already have as a domain user, I can check that with the command:

wmic service get pathname,startname

This will show a list of services, their executable paths and the user the service runs as. Here a threat actor would aim for any account with higher permissions than they had, typically something like LocalSystem.

If a path is not quote wrapped, Windows does not know which part is the executable and if suffixes are parameters or not. For example, it cannot distinguish the following paths:

C:\Program Files (x86)\Privacyware\Privatefirewall 7.0\pfsvc.exe
C:\Program Files (x86)\Privacyware\Privatefirewall.exe
or
C:\Program.exe

This means that it will attempt to execute the file as if any of those were correct, starting at the shortest and moving up to the longest path until one works. Therefore if you can create a file in the root of C:\ called Program.exe, when Windows attempts to start the service it will first try to execute your program and not the valid EXE.

However by default you will not have write permissions to these directories as a domain user or local user. However if the permissions have been changed from default privilege escalation is possible.

Any EXE that you plant in the C:\Program.exe position will be executed when the system loads. Generally however, users won’t have write access to the root of C:\. However with the example path given above, there is an alternative option though in:

C:\Program Files (x86)\Privacyware\Privatefirewall.exe

If you can write to either of these locations, the exploit should work. For this task create an EXE which executes the following commands:

net user tester Password123! /add
net localgroup "Administrators" tester /add

So for our example I would plant the EXE in the required location, rebooted and when I log in the EXE would have already been executed. (Alternatively if you can simply restart the affected service that would have the same effect without requiring a reboot).

Fixing Unquoted Service Paths

The fix for this issue is relatively simple, as I’m sure you’ve guessed – it is simply, to quote wrap the executable path for each service.

However, it’s also worth checking the permissions of folders on the C:\ drive, in particular subdirectories of C:\Program Files, to ensure they’re sane. That’ll help prevent exploitation of this issue and related service-based privilege escalation techniques.

Be very wary before altering the permissions on folders in the C:\ drive, in particular anything under “Program Files”. Also be aware that when software installs itself it can alter these permissions so it’s always best to ensure that permissions on key directories are sane.