Weak Permissiona
Permissions on Windows systems are complicated and challenging to get right. A slight modification in one place may introduce a flaw elsewhere. As penetration testers, we need to understand how permissions work in Windows and the various ways that misconfigurations can be leveraged to escalate privileges. The permissions-related flaws discussed in this section are relatively uncommon in software applications put out by large vendors (but are seen from time to time) but are common in third-party software from smaller vendors, open-source software, and custom applications. Services usually install with SYSTEM privileges, so leveraging a service permissions-related flaw can often lead to complete control over the target system. Regardless of the environment, we should always check for weak permissions and be able to do it both with the help of tools and manually in case we are in a situation where we don't have our tools readily available.
Permissive File System ACLs
Running SharpUp
We can use SharpUp from the GhostPack suite of tools to check for service binaries suffering from weak ACLs.
PS C:\htb> .\SharpUp.exe audit
=== SharpUp: Running Privilege Escalation Checks ===
=== Modifiable Service Binaries ===
Name : SecurityService
DisplayName : PC Security Management Service
Description : Responsible for managing PC security
State : Stopped
StartMode : Auto
PathName : "C:\Program Files (x86)\PCProtect\SecurityService.exe"
<SNIP>
The tool identifies the PC Security Management Service, which executes the SecurityService.exe binary when started.
Checking Permissions with icacls
Using icacls we can verify the vulnerability and see that the EVERYONE and BUILTIN\Users groups have been granted full permissions to the directory, and therefore any unprivileged system user can manipulate the directory and its contents.
Replacing Service Binary
This service is also startable by unprivileged users, so we can make a backup of the original binary and replace it with a malicious binary generated with msfvenom. It can give us a reverse shell as SYSTEM, or add a local admin user and give us full administrative control over the machine.
Weak Service Permissions
Reviewing SharpUp Again
Let's check the SharpUp output again for any modifiable services. We see the WindscribeService is potentially misconfigured.
Checking Permissions with AccessChk
Next, we'll use AccessChk from the Sysinternals suite to enumerate permissions on the service. The flags we use, in order, are -q (omit banner), -u (suppress errors), -v (verbose), -c (specify name of a Windows service), and -w (show only objects that have write access). Here we can see that all Authenticated Users have SERVICE_ALL_ACCESS rights over the service, which means full read/write control over it.
Check Local Admin Group
Checking the local administrators group confirms that our user htb-student is not a member.
Changing the Service Binary Path
We can use our permissions to change the binary path maliciously. Let's change it to add our user to the local administrator group. We could set the binary path to run any command or executable of our choosing (such as a reverse shell binary).
Stopping Service
Next, we must stop the service, so the new binpath command will run the next time it is started.
Starting the Service
Since we have full control over the service, we can start it again, and the command we placed in the binpath will run even though an error message is returned. The service fails to start because the binpath is not pointing to the actual service executable. Still, the executable will run when the system attempts to start the service before erroring out and stopping the service again, executing whatever command we specify in the binpath.
Confirming Local Admin Group Addition
Finally, check to confirm that our user was added to the local administrators group.
Another notable example is the Windows Update Orchestrator Service (UsoSvc), which is responsible for downloading and installing operating system updates. It is considered an essential Windows service and cannot be removed. Since it is responsible for making changes to the operating system through the installation of security and feature updates, it runs as the all-powerful NT AUTHORITY\SYSTEM account. Before installing the security patch relating to CVE-2019-1322, it was possible to elevate privileges from a service account to SYSTEM. This was due to weak permissions, which allowed service accounts to modify the service binary path and start/stop the service.
Weak Service Permissions - Cleanup
We can clean up after ourselves and ensure that the service is working correctly by stopping it and resetting the binary path back to the original service executable.
Reverting the Binary Path
Starting the Service Again
If all goes to plan, we can start the service again without an issue.
Verifying Service is Running
Querying the service will show it running again as intended.
Unquoted Service Path
When a service is installed, the registry configuration specifies a path to the binary that should be executed on service start. If this binary is not encapsulated within quotes, Windows will attempt to locate the binary in different folders. Take the example binary path below.
Service Binary Path
Windows will decide the execution method of a program based on its file extension, so it's not necessary to specify it. Windows will attempt to load the following potential executables in order on service start, with a .exe being implied:
C:\ProgramC:\Program FilesC:\Program Files (x86)\SystemC:\Program Files (x86)\System Explorer\service\SystemExplorerService64
Querying Service
If we can create the following files, we would be able to hijack the service binary and gain command execution in the context of the service, in this case, NT AUTHORITY\SYSTEM.
C:\Program.exe\C:\Program Files (x86)\System.exe
However, creating files in the root of the drive or the program files folder requires administrative privileges. Even if the system had been misconfigured to allow this, the user probably wouldn't be able to restart the service and would be reliant on a system restart to escalate privileges. Although it's not uncommon to find applications with unquoted service paths, it isn't often exploitable.
Searching for Unquoted Service Paths
We can identify unquoted service binary paths using the command below.
Permissive Registry ACLs
It is also worth searching for weak service ACLs in the Windows Registry. We can do this using accesschk.
Checking for Weak Service ACLs in Registry
Changing ImagePath with PowerShell
We can abuse this using the PowerShell cmdlet Set-ItemProperty to change the ImagePath value, using a command such as:
Modifiable Registry Autorun Binary
Check Startup Programs
We can use WMIC to see what programs run at system startup. Suppose we have write permissions to the registry for a given binary or can overwrite a binary listed. In that case, we may be able to escalate privileges to another user the next time that the user logs in.
This post and this site detail many potential autorun locations on Windows systems.
Last updated