Locating unquoted strings in Services with spaces in the path

[Neemobeer]

A little background. Each running service has corresponding registry entries. One in particular, ImagePath contains the command executed when a service starts. It is a moderate vulnerability when the ImagePath is not quoted. What can happen is an attacker can make the service execute any arbitrator executable with whatever privileges that service has. In some cases with the SYSTEM account. Here is a command that can be run to locate unquoted image paths which you can then edit the ImagePath value and add double quotes around it.

Services are located in the registry at HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services each key represents a service.

Open a command prompt and run the following command

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

From my example we see I found one on my system. (I really just unquoted it)

Now open regedit and navigate to the key corresponding to the service name ClickToRunSvc from the path mentioned above. You will see the the path has a space and no quotes around the exe.

Double click the ImagePath value and add double quotes ONLY AROUND THE EXE PATH don't add them around any switches

Here it is fixed

Rinse and repeat.

Congratulations, you have just patched one or more security vulnerabilities!

 

[Josephur]

I think it's important to explain how this exploit can possibly work for an attacker.

Let's take for instance the following service executable path that is not quoted:
C:\Program Files (x86)\My Company\The Product\MyProgram 1.00.22\program.exe

Without quotes it's possible for this service to actually execute the following paths if they existed and with the same permissions as the service has:
C:\Program.exe
C:\Program Files (x86)\My.exe
C:\Program Files (x86)\My Company\The.exe
C:\Program Files (x86)\My Company\The Product\MyProgram.exe

This is due to the fact that the run arguments have spaces and the command environment would possibly execute
"C:\Program.exe" thinking "Files (x86)\My Company\The Product\MyProgram 1.00.22\program.exe" are parameters.

Hopefully this makes the fix you described make sense to some people that may not understand why this is a vulnerability in the first place.