Secure Unquoted Service Paths in your EUC Environment

This post has already been read 5818 times!

This was brought to my attention recently when being “ethically” hacked and is an easy one to remediate but apparently one that has been around for a while.

Essentially Windows Services have a path defined to the executable such as C:\Program Files\Application\service.exe. The issue is if this path does not have quotes around it then the service will try to start an exectuable in the parent path first. This could allow someone in you platform the access they require to inject a malicious executable onto your platform and execute it with a service restart.

Now there are loads of ways that you can fix this such as manually “quoting” each path in the registry or contacting the vendors to check if they have a fix for this.

First lets check and see what non windows services are vulnerable to this exploit.

Open PowerShell on one of your servers that your users connect to and type in the following one liner

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

There you can see all the services with unquoted paths – here check for any vendor specific services. You could go through and “Quote” all the services manually but chances are (and as I did) you will get one wrong / or put the quotes in the wrong place and render the server useless.

Luckily, Microsoft have given us a script to fix it!

https://gallery.technet.microsoft.com/scriptcenter/Windows-Unquoted-Service-190f0341#content

Just download the script and run it on your servers and base images then you can re-check for any vulnerable services after it has executed. Yes – I know its PowerShell ISE – but its a quick and easy win on the Infrastructure Servers !

Once run you can re-run the command above and check that there are no non-windows services listed in there and that you have closed this one off the list for your next vulnerability scan.

Quick one but hopefully something useful.

Thanks,

Dave