Privilege Escalation: Unquoted Service Path
Unquoted Service Path:
The Unquoted Service Path vulnerability is a fairly common one but not very easy to exploit. This is due to the fact the location a user has to be able to write is not available to them by default.
This vulnerability is present when a Windows services has its binPath AKA the path to the binary to run the service, has a space in the name.
We can search for these with wmic.
wmic service get name,pathname
We can see after looking at the output we see a service called Firewall2 with the following path.
C:\Program Files (x86)\Firewall 2.0\Firewall2.0.exe
We can see that there is a space between Program and Files! This meas the service is vulnerable to Unquoted Service Path exploits!
Before we can exploits this we must first understand how Windows treats this path. With a space in the path and it is not surrounded with a ” then Windows will not know exactly what path you are refering too.
When Windows sees a path with a space inside it will look at the smallest path first. In our example it will assume the first path is the following.
This is becuase it hits the first space and grabs the extention to append. You can see where this is going! If we were able to create a binary called Program.exe in C:\ and the service restarts we would have our binary ran instead of the correct one.
Lets assume that path does not exist either, then it will look for the following when it hits the next space in the name.
You can see it is slowly peicing the path togeather using the slowedt first. If we have write access to the Program Files directory we can abuse this as well with our own binary. This lookup process will continue to each space in the path until it gets the full path and correctly runs the right binary.
To exploit this we must place a binary we want to run in 1 of the 2 following locations.
# Create binary Program.exe and place it here C:\ # Create binary Firewall.exe and place it here C:\Program Files(x86)\
If we are unable to write to any location up to the space then we wont be able to exploit this. One side effect of using the Program.exe example is that when the user logs into the system it will prompt them to rename the binary. This is due to the fact Windows knows it may not be the right binary and can cause issues. Whats important here is that when the warning appears the binary was already executed. We will have our access by this point.
Take a moment and redo the excersise on a Windows XP Machine and use the tool accesschk to check permissions on directories to see what you have access to!