Microsoft Windows unquoted service path enumeration fix

Last Updated on September 16, 2023 by Dave Farquhar

Tenable plugin 63155 and Qualys QID 105484 reference a high-severity vulnerability regarding unquoted search paths. Unfortunately the fix action tends to be a bit vague. If you’re looking for a way to fix the Microsoft Windows unquoted service path enumeration, you’ve come to the right place. Here’s how to fix an unquoted path for Windows services.

How bad is unquoted service path enumeration?

Honestly, I’m used to seeing this as the last vulnerability standing on an otherwise clean machine. That’s because plugin 63155/QID 105484, or its Rapid7 equivalent, which it tracks as a variant of CWE-428 named Windows Unquoted Search Path or Element can allow local privilege escalation, are tricky to fix. It allows unauthorized, untrusted software to run, and that’s bad. But an attacker in a position to take advantage of this is in a position to do lots of other things too. I’ve always given things like keeping your office suite and web browser and Adobe apps up to date higher priority.

Since this is a fix that requires a configuration change, not a patch, and the fix varies from machine to machine, this is a nagging one. The way most organizations prioritize, at least one new lower effort/higher reward vulnerability comes along every month. It’s worth fixing, but where this one falls always depends on how big your vulnerability backlog is, and this one is more vulnerable than most to the dreaded pocket veto.

It’s very easy for this one to fall through the cracks. But that doesn’t mean it has to.

Protect the unquoted search paths or elements in the registry: Here’s how

Some scanners give a fix action that reads something like this: Protect the unquoted search paths or elements in the registry. Sounds a little vague, doesn’t it? Tenable’s fix action is more specific and, I think, more understandable: Ensure that any services that contain a space in the path enclose the path in quotes. Between that and looking at the Plugin Output column in the scan report, I may be able to figure out what to do from there if I was seeing this for the first time. But there’s nothing like an example.

If you absolutely, positively need a clean scan, say, for contractual or regulatory reasons, let’s walk through how to fix Tenable plugin 63155, Qualys QID 105484, and the Rapid7 equivalent.

First, open a command prompt and run this command:


wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """'


When I ran the command, I got this result:


Intel(R) Management and Security Application Local Management Service LMS C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\LMS\LMS.exe Auto

Keep in mind this is what I got on my machine. The offending service may very well be different on your machine, or some of them. LMS.exe seems to be a frequent offender but it’s not guaranteed to be the only one.

To fix it manually, open Regedit. I have an introduction to registry editing if you’re unfamiliar with this. But if you’re remediating vulnerabilities, getting familiar with the Registry is a good idea. Look in HKLM\System\CurrentControlSet\Services for the service you found in the previous step.

The culprit is in the setting named ImagePath. Add quotes around everything to fix it.

This fix requires a reboot to take effect. So if you made the change already and the vulnerability is still showing up on scans, try rebooting before submitting it as a false positive. If the vulnerability signature sees the computer is still in a vulnerable state even though the system is configured differently, that’s a true positive, not a false positive. Wait until an available maintenance window if this vulnerability is on a production server, of course.

Alternative fix for Tenable plugin 63155 or Qualys QID 105484

If you don’t mind enabling Powershell, Microsoft has an automated fix. That said, some will argue having Powershell enabled is a bigger vulnerability than the unquoted paths issue. Of course, playing that game is a good way to end up with Powershell enabled everywhere and not get your vulnerability fixed. One of the keys to successful vulnerability management is picking your battles.

If you have Powershell enabled, this fix is convenient.

If the service in question is something you don’t really need, it’s a good practice to uninstall it instead. But this turns it into a fix that varies from machine to machine and is difficult to automate.

How important is unquoted service path enumeration to fix?

Like I said, in order to be able to use this, a threat actor has to already be on a system and in position to do other things. This is the kind of vulnerability an attacker would use to maintain a presence on a system and/or elevate privileges, rather than get a foothold on one. In other words, if this is a problem, the attacker is already winning. This vulnerability helps an attacker establish a dynasty.

Tenable gives it a VPR score of 6.7 on a scale of 1 to 10. It’s below the threshold of things commonly exploited, but not far off. Since this question’s come up before, I recommend fixing VPR 9s and 10s in a week or two. I recommend fixing VPR 7s and 8s in 30 days. And anything below that, two months, maybe more if needed.

It’s also worth factoring in the system with the problem. On some level, you know how important a system is. If every computer on your network evaporated tomorrow, what systems would you rebuild first? Those are the systems that deserve this effort. Once you get those done, take care of the others as you get to them.