I have been playing with unquoted service paths/trusted paths the last few days and thought would write something up. Credit to Gavin Jones who introduced me to this issue, which to be honest I hadn’t heard of before and I  normally only checked cacls and permissions of services.

What is the issue?

Basically it is related to the path binary in services that are unquoted and contain spaces.

If we look at the below Skype service you will see the path is quoted – “c:\program files (x86\” which is the correct way.

You will come across some major vendors who do not enclose the path within quotes - c:\program files (x86)\ – this would be bad.

When they are unquoted and contain spaces within the path, this can be exploited.  By placing a malicious file in c:\ named program.exe would run when the service starts.. Typically services will be starting with the SYSTEM privilege.

For instance the below path.

c:\program files\sub dir\program name

It contains spaces in several places, areas we can place files for exploit are marked with *

c:\program*files\sub*dir\program*name

c:\program.exe files\sub dir\program name

c:\program files\sub.exe dir\program name

c:\program files\sub dir\program.exe name

The issue is a standard user probably is not likely to be able to write files to c:\, but if they can or if they can write further down the path, i.e if they can write to the \sub dir\ above, then you can escalate privileges. Obviously the service must be restarted in order to execute the new file, but if you have a restricted laptop then you may be able to get local admin access or servers once they reboot or the service restarts.

How to Check

You can manually look though the services and check the paths to see if they are unquoted and contain spaces.

There has been a recent Metasploit module that also deals with this exploit/windows/local/trusted_service_path 

I wanted a one liner script that would just list me the services that are set to auto start and were unquoted that I could just run without uploading any binary files or exploiting. If for instance you are conducting build reviews and just have RDP access and A.V is enabled, it is a quick clean way to check. There probably are better ways to check, but this is what I came up with and seems to work.

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

 

This will return services that are unquoted, set to auto start (as pointless if the service is disabled) and list the service name, description and path.

You can also manually do this using SC if you wish

List Services

sc query

Find Path Of Service.

Here you will see that skype is correct and within quotes.

sc qc skypeupdate

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: skypeupdate
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 0 IGNORE
BINARY_PATH_NAME : “C:\Program Files (x86)\Skype\Updater\Updater.exe”
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Skype Updater
DEPENDENCIES : RpcSs
SERVICE_START_NAME : LocalSystem

I tried this on my laptop and found 8 unquoted services from major vendors with this issue. So take a look at your system, you may find something interesting. :)

 

To Fix: Either contact the vendor there may be a patch for this to update the service, otherwise you can manually fix it yourself.

run Regedit and browse to HKLM\SYSTEM\CurrentControlSet\services

Find the service in question and simply at ” “ either side of the ImagePath string like below.

Before – unquoted service path (click image to expand)

before

 

After – Fixed service path (click image to expand)

after


Update: Nessus has now included a plugin for this and referenced commonexploits.com

http://www.tenable.com/plugins/index.php?view=single&id=63155

 

nessus