Local Exploit trusted_service_path is not traversing the sub-folders

[sumitvgithub]

Steps to reproduce

Consider a service Vuln Service which is vulnerable to Unquoted Service Path (used for Windows Privesc).

Executable path: C:\Program Files\A Folder\B Folder\C Folder\Executable.exe
Startmode: Auto
Start Type: LocalSystem

Consider BUILTIN\Users has Write access to C:\Program Files\A Folder. We have a low privileged user meterpreter shell on the victim machine. The exploit/windows/local/trusted_service_path only finds if it is able to place a malicious executable, i.e. C:\Program.exe and if not it errors out that saying Access Denied however if this user would've been in the administrators group, the exploit would have gracefully given us the SYSTEM shell since running icacls on C:\Program Files tells that Administrators has Full Access to this folder (which is default). However, being in the Users group by default only has (RX)(OI)(CI)(IO)(GR,GE) permissions hence it cannot place malicious Program.exe.

Current behaviour

This exploit is not traversing the subfolders to check whether it can place a malicious executable in that directory given the necessary permissions, say Write permissions to Users group or Full access permissions to Everyone. It is placing an executable Program.exe, i.e. executable path being C:\Program.exe, and if not able to do so, for example, since Users don't have write permissions to "C:\Program Files", then it is not traversing to the writable folder, for example, to check whether it can place A.exe, i.e. C:\Program Files\A.exe, if not, then B.exe, i.e. C:\Program Files\A Folder\B.exe and so on.

What should happen?

Since A Folder has Write access to the Users group, this exploit should traverse down the path to place a A.exe in C:\Program Files, i.e. executable path would then become C:\Program Files\A.exe. Considering the user has SEShutdown Process Privilege (which Users group has by default), the exploit should reboot the system once A.exe is placed since sc.exe cannot be run by users in the Users group. Hence, rebooting the system will run those services that should auto-start which will the communicate with the Service Control Manager and will run our A.exe once it tries to execute C:\Program Files\A Folder\B Folder\C Folder\Executable.exe leading to give us the SYSTEM shell. If possible, print a message saying to connect to the specified port accordingly. Rest is obviously to the attacker to set up the listener and get SYSTEM shell.

Victim Operating system

Windows 7 (Build 7601, Service Pack 1)

Metasploit version

Metasploit Framework: 4.17.25-dev-
Console: 4.17.25-dev-

I installed Metasploit from

Rapid 7 metasploit-framework Github repository

What OS are you running Metasploit on?

OS: Kali
Version: 2018.4

Kernel details

Kernel release: 4.18.0-kali2-amd64
Kernel version: SMP Debian 4.18.10-2kali1 (2018-10-09)

[h00die]

hey @sumitvgithub . I was chatting with @zeroSteiner this morning about missing a 'unquoted service path' exploit, and he found the trusted_service_path module. I found your medium.com write-up independently and figured i'd work through it to test the module was still working and write-up some documentation. I independently identified that it was writing to the shortest path first (only), which was prob ok in XP days, and that it needed to do longest path and keep testing as it got shorter. lo and behold by the time I made it to the end of your article I found we traveled the same exact path. Thank you for linking in that article to this issue, and writing up a very clear issue. Sorry it took so long to get to, but I'm 90% done re-writing it to handle this.

[sumitvgithub]

Hey @h00die . Glad to hear that. It really took some time but that's fine. I went over your linked PR and it looks great. Looking forward to test the module in the next update soon!