Blog by: Paul van der Haas, Security Specialist, SecureLink Netherlands
As a force of habit, we run a default ‘checklist’ to test for privilege escalation. Numerous of sites are available to set up such a checklist. Fuzzy security is one of them for example.
One of the tests that penetration testers ‘always’ should do is to check for unquoted service paths. Services with a whitespace in the BinaryPathName could be used for privilege escalation. An example is given below.
Given that a service has the following “BinaryPathName”:
Notice the whitespace between ‘Program’ and ‘Files’ and the lack of quotes (“”). When the Service Control Manager (SCM) starts the service, it treats the BinaryPathName value as a command and tries to execute it. Quotes would tell Windows which part of the text represented the executable's path and which parts were command line arguments, if any.
Unquoted service paths
In the absence of quotes, Windows assumes that space characters are delimiters. So first, it parses out C:\Program and looks for C:\Program.com, C:\Program.exe, C:\Program.Bat, etc. The ambiguity due to the lack of quotes means that if there were a C:\Program.exe, Windows would execute that program instead of the intended target program.
To exploit this, a file (Program.exe) must be written to the ‘C:\’ folder. Not everyone is able to write to the ‘C:\’ folder, which most of the time means that you must be an Administrator. Another option is that you have physical access to the system and disk encryption is not enabled. In some cases, you can boot with another Operating System, Kali for example, and place the Program.exe executable on the disk.
However, once you are administrator, there are probably more (read better) options to gain ‘NT AUTHORITY\SYSTEM’ rights. And access to a system without disk encryption is most of the time a bigger problem than escalation to ‘NT AUTHORITY\SYSTEM’.
In the real world
Recently we did an assessment of a workstation and we ran through the checklist mentioned above. Surprising though, two services were found with an unquoted service path. Since we had already physical access, and of course the disk was unencrypted, this vulnerability could be exploited to gain ‘NT AUTHORITY\SYSTEM’ rights.
While reproducing this vulnerability in my local Virtual Machine with Windows 10 (where I installed all the Windows features), the following result was shown:
Does this mean Microsoft Windows 10 features exist with unquoted service paths? Well, yes. I quickly made a report to submit it to the MSRC portal. The following is a part of a report I have written.
The ‘Wms’ and ‘WmsRepair’ services runs as Local System, have auto start enabled and has an unquoted service path which could lead to privilege escalation. By placing Program.exe at the C:\ drive, code can be executed as SYSTEM.
To be able to exploit this vulnerability an attacker should have local administrator rights or physical access to the system (without disk encryption).
Below you can find a Proof of Concept for one of the services found.
Unquoted service ‘WmsRepair’ (notice that the service runs as SYSTEM and is on auto start):
Steps for exploitation:
1) Create a payload and name it ‘Program.exe’
msfvenom -p windows/x64/exec cmd='cmd.exe /c net user Elevation Elevate2019! /add && net localgroup Administrators Elevation /add' -f exe > Program.exe
2) Place the payload (Program.exe) in ‘C:\’ as a local admin
3) Start the service ‘Windows MultiPoint Server’ (Wms)
The service should not start Program.exe.
The service started Program.exe and run as ‘SYSTEM’. The payload was executed, and a new local administrator was born:
It is recommended to automatically test services for unquoted service paths. Place quotes at the start and end of the path.
Is this exciting?
Finding a ‘vulnerability’ is always exciting! However, as you may have noticed, the word vulnerability is quoted. The unquoted service path finding for Windows features is reported to Microsoft. The following response is given:
Thank you for sending us this report. Our team was able to reproduce the issue you reported, but this does not meet our bar for servicing via a security update. Instead, this is something we may address in a future release of Windows, so we will be closing this case.
This issue requires that the attacker has administrator privileges which reduces the likelihood of a successful attack. We have a blog post from a few years that details why we don't prioritize service path issues - https://blogs.msdn.microsoft.com/aaron_margosis/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unquoted-service-paths/
Since this could be viewed as low risk, should we not test it anymore? No, it is still worthwhile to test for this issue. It could be a characteristic of a lack of quality control / lack of secure design and in some cases an easier path for privilege escalation. Reporting this finding however should not (by default) have a high-risk classification. As one colleague once said (I know, this is not how things should be said): They mostly have bigger fish to fry.