It’s time that we had a chat about unquoted service path privilege escalation. Logging onto www.exploit-db.com right now will give you an indication that it’s a popular topic at the moment, but I have also found a lot of confusion and conflicting opinions about it. There are A LOT of them in the wild and dozens being published on exploit-db a week. From what I have seen, I would estimate that around 10% of software is vulnerable to this exploit.
It is useful? The answer lays somewhere between ‘sometimes’ and ‘depends’. More importantly, is it relevant? YES, and an important part of the resounding ‘yes’ lays in the simplicity of this exploit. Let’s go through the details to see what all the fuss is about.
For this example, we’re going to use Macro Expert 4.0. The proof of concept can be found here: https://www.exploit-db.com/exploits/40428/
How does it work?
A quick look at the service shows us what under the hood. Let’s compare the output of two services with one another. The difference that you’re looking for is that the BINARY_PATH_NAME of Macro Expert, lacks the quotes used in Plex Update services (figure 1 and 2).
Figure 1 – Marco Expert Service Details
Figure 2 – Plex Update Service Service Details
So? Well, let’s do a quick experiment. If I try to run the MarcoService.exe in command prompt by using the path without quotation marks, what would happen?
Figure 3 – Running Exe without quotations
It doesn’t work because it doesn’t know how to handle the space between ‘program’ and ‘files’. So how does the service work at all then? That’s because windows has an error handling mechanism of sorts that makes it include the space if there is a failure. In fact, when the service starts Windows will try and execute MacroService.exe by going through a series of failures first. From top to bottom, here is what Windows does with that path.
C:\program (no exe here)
C:\program files\grasssoft\macro (no exe here – there is another space in the directory path)
C:\program files\grasssoft\macro expert\marcroservice.exe (found it! – the service starts)
So how can this be used to an attacker’s advantage? Most services run with SYSTEM privileges which means that if you can get this service to start another exe of your choosing, then it would run as SYSTEM too. Neat.
How do you do that? Simply put your desired executable on the C drive and rename it as such C:\program.exe. Now when the service starts up again, you’ll have execution. In theory yes, but in practise, this doesn’t really work that well.
Your first problem is that a normal user doesn’t have permission to write to the C:\ drive. Chances are you won’t be able to slip in your payload. This is the primary reason why Unquoted Service Path vulnerabilities are not being seriously considered as a threat.
Plan B – Weak File Permissions
Before you abandon all hope, we have another shot at making this work. There was a second space in the directory name! Would it work if we put an exe here: “C:\program files\grasssoft\macro” Yip, it sure will. But if we don’t have access to write to the C:\ drive, then surely we don’t have permissions to write to the grasssoft folder in program files? You’ll never know if you don’t check. Take figure 4 as an example.
Figure 4 – Weak Permissions on Macro Expert folder
See where it says BUILTIN\Users:(OI)(CI)C. That means that if we have a low level permission user, then we can go ahead and slip our own exe into that folder. All that we need to do now is to restart the service. This is where you will hit another brick wall because you probably won’t have permission to restart the service. Alas, why not just restart the entire machine? Done deal.
File Name Warning (and how to bypass)
Windows does have another trick up its sleeve to try and protect the user. When you restart the machine and it find a file called C:\program.exe on it, then it’s going to prompt the user with a warning. When this warning appears, it’s already too late because the file has already been executed.
Figure 5 – File Name Warning
Odds are a user will just go ahead and click ignore without even reading the message. I however, am not in the business of alerting users when I can help it. See that tick box that says “Don’t perform this check at startup”, that means there is a registry key somewhere that we can tweak. I went ahead and analysed the registry before and after ticking the box and found the key in question. I used a program called Regshot 1.9 which I can highly recommend.
Figure 6 – How to disable File Name Warning
If you can get your executable to add this registry key as its first order of business, then you should be in the clear. It’s going to be a bit of a race condition, but in this case the odds are in your favour.
Blue Team – How to detect and eliminate the vulnerability
How do you detect Unquoted Service Paths on other applications that you got running on your computer? There are a ton of scripts out there. Hell, there’s even a metaploit module which you can find at exploit/windows/local/trusted_service_path. In my opinion, this is a bit extreme and adds unnecessary risk and complications to your hack. Personally I prefer to keep it clean with this command:
wmic service get name,displayname,pathname,startmode |findstr /i “auto” |findstr /i /v “c:\windows\\” |findstr /i /v “””
How do you protect against this vulnerability if you have hundreds of computers that you have to defend? Luckily there is a great powershell script which you can easily deploy to your machines. The script can be downloaded here: https://gallery.technet.microsoft.com/scriptcenter/Windows-Unquoted-Service-190f0341
Additional Resources and Acknowledgements
Here is a list of resources that I consulted when building my own understanding of Unquoted Service Paths that you may find useful yourself: