PATH Vulnerabilities Exploration

In our routine ForestVPN app audit, we found a major .NET Core flaw enabling privilege escalation on Windows. Attackers must breach a security boundary by locating a writable PATH directory to exploit it.

This article delves into the intricacies of the PATH environment variable, scrutinizing its security implications and offering insights into potential misconfigurations.

This PATH vulnerability surfaced during an audit of our product’s closed beta for Windows, unreleased to consumers. Upon identification, we promptly addressed the issue and notified Microsoft of our discovery.

What is the PATH environment variable?

When a user endeavors to execute a program via the command line interface (CLI), Windows must ascertain the precise path to the program. Consider the ‘ping’ command, for instance; although Windows may not initially recognize its location, it adeptly locates and executes it.

Windows uses the PATH environment variable to locate executable files, which consists of a semicolon-separated list of directories that includes both system and user-defined paths. This discussion will concentrate on the system PATH. When searching for an executable like ‘ping,’ Windows sequentially scans the directories in the PATH and runs the first match found, disregarding case. In this case, the ‘ping’ executable was found in the first PATH entry, C:\Windows\system32, resulting in the execution of C:\Windows\System32\ping.exe.

The PATH serves as a directory of trusted locations that Windows scans for executable programs and dynamic link libraries (DLLs). It is integral not just to command-line operations but also to Windows’ system processes, which refer to the PATH when a required DLL is not found.

PATH: An unmonitored attack surface

Rigorous compliance with rules is crucial to ensure the security of PATH directories. Should unprivileged users, whether local or remote, gain control over these directories, their integrity becomes jeopardized. Regrettably, administrators might add directories to the PATH variable without the operating system’s security checks, potentially because of user mistakes or flawed installations.

The security risk of a world-writable directory in the PATH is a subject of much confusion. We unequivocally establish its risk through the following attack scenarios.

The PATH to NT Authority/System

In cybersecurity and ethical hacking, learning privilege escalation is crucial. This involves leveraging a system or application flaw to access restricted areas, much like finding hidden routes in a castle that bypass usual defenses and lead directly to the core.

The unveiled roadmap presents a strategic method for privilege escalation on a local machine, focusing on situations where one discovers a writable directory in the system’s PATH variable. Before proceeding, we will examine the foundational assumptions that prepare the groundwork for the ensuing attack scenarios.

To commence, our assumptions are grounded in real-world conditions conducive to attacker exploitation. The following points outline the assumptions and prerequisites for our privilege escalation process:

1. The attacker has already gained a foothold on the local machine, potentially through social engineering, phishing, or exploiting a vulnerability that grants limited user-level access. This initial access is crucial for executing subsequent steps towards elevating privileges.
2. The system possesses a directory writable by the current user, also listed in the PATH environment variable. The PATH variable specifies directories where executable programs are located. If a directory is writable and part of PATH, it can trick the system into executing malicious code.
3. The local machine features scheduled tasks or services running with elevated privileges, executing binaries from the PATH. Many systems have tasks running periodically with higher privileges for maintenance or updates. If these tasks execute programs without specifying an absolute path, they might inadvertently run a malicious program placed in a writable PATH directory.
4. System administrators have not secured the writable directory with proper permissions or neglected best practices in configuring the PATH environment variable, leading to potential security oversights. In complex environments, administrators may overlook such configurations.

Free vpn access info

An attacker, assuming system vulnerabilities, may escalate privileges by placing a malicious executable in a writable PATH directory, running it covertly, and maintaining persistence. This highlights the importance of proper system setup and security checks for ethical hackers and security experts.

The victim is running Windows A directory listed in PATH is writable by any user The attacker has the ability to write files to the directory in 2)

Scenario 1: PATH interception—search order hijacking

This outcome naturally stems from leveraging the PATH variable. An administrator who often employs a custom script, clean.bat, for administrative duties adds its directory, C:\tools, to the system’s PATH to streamline usage. Upon calling clean, the script launches, allowing the administrator to attend to further tasks.

Unknown to the administrator, the C:\compiler directory in the PATH variable has global write access and takes precedence over the intended script directory. An attacker exploits this vulnerability by inserting a script named identically to the original in C:\compiler. As a result, executing the command ‘clean’ initiates the rogue script in C:\compiler instead of the legitimate one.

From this point, the administrator account is compromised, requiring only bypassing User Account Control (UAC), which isn’t foolproof and is easily bypassed.

Search order hijacking occurs when a malicious binary supplants an anticipated benign executable in the PATH variable, covertly executing its payload before invoking the original program, thus eluding administrator detection.

This vulnerability affects not only commands run by administrators but also scripts and applications that use the shell to execute commands. If these do not carefully invoke other programs, they may activate the flaw.

In internal testing of the Windows ForestVPN pre-release application, vulnerabilities associated with writable directories in PATH were discovered. The installation necessitated the identification and installation of missing .NET runtimes. Adhering to official guidelines, the recommended procedure entails programmatically executing the dotnet command as follows:

Developers quickly addressed a security risk where dotnet could be hijacked via the PATH variable by limiting its loading to secure directories, preventing rogue binary executions.

Scenario 2: DLL search path hijack on an external privileged application

Dynamic-Link Libraries (DLLs) serve as modular application dependencies contained within distinct binary files. They enable code sharing without replication across multiple files. An application accesses a DLL’s functionality by loading the library into memory and executing the desired function. Since the DLL’s code executes within the application, it must be secure and cannot be loaded indiscriminately.

Occasionally, a Windows application may fail to load due to missing DLLs. To resolve this, the application searches for these files in its installation directory, the current directory, the system and Windows directories, and finally in the paths specified by the PATH environment variable.

This behavior, typically justified, is susceptible to exploitation when Windows cannot locate the required DLL and defaults to loading from PATH directories. A user with write access to a PATH directory could exploit this vulnerability through Phantom DLL Hijacking. Two case studies demonstrate instances where privileged applications, including drivers and services, are prone to this issue.

The curious case of the driver

In July 2020, a BugCrowd researcher found a privilege escalation flaw in ForestVPN’s Windows app, where it incorrectly loaded igdgmm32.dll from a PATH directory.

Bugcrowd’s first review failed to duplicate the problem. Our team determined that ForestVPN.exe runs with only user-level permissions, but a risk persists for horizontal privilege escalation. There’s still a concern that an attacker might exploit this to gain higher privileges by attacking an administrator using ForestVPN.exe on the same machine from a separate user account.

Subsequent scrutiny confirmed that ForestVPN’s installation protocol adequately established appropriate access permissions for generated directories. The folders containing ForestVPN.exe are immutable to users without elevated rights. The researcher’s proof-of-concept originated from C:\Python38, an unrelated directory with global write permissions, presumably resulting from an administrative oversight. The majority of users remain unimpacted unless their system includes a globally writable directory.

Upon investigation, we determined that igdgmm32.dll is a component of the Intel HD Graphics Drivers. This driver loads within the Windows Presentation Foundation (WPF) UI framework, which is employed for constructing Windows user interfaces. The issue of the library loading from the PATH environment variable was linked to its absence as a dependency, exclusively affecting systems with Intel chipsets.

Without a vendor patch, we quickly fixed the problem by adding necessary DLLs to the install package. We informed Microsoft and Intel; Intel acknowledged the flaw in an old driver and confirmed it was fixed in the latest version.

O dependency, where art thou?

During an audit of our upcoming Windows app, we used Procmon to observe that Microsoft.DiaSymReader.Native.amd64.dll loaded with every service start or reboot.

Analogous to DLL hijacking, this DLL was vulnerable to interception and execution from a PATH directory. The AppService operated under NT AUTHORITY\LOCAL SERVICE without inherent privileges. Nonetheless, flawed Windows permission delineations allowed privilege elevation to NT AUTHORITY\SYSTEM through a malevolent DLL in a modifiable PATH location. Our developers pinpointed and swiftly addressed the core problem by bundling the DLLs within the installation package.

Scenario 3: DLL search path hijack on default Windows applications

Built-in Windows applications may be vulnerable to DLL Hijacking even without extra installations. This exploitation technique has been thoroughly investigated, highlighting numerous instances of potential abuse. Since Windows applications frequently operate with elevated privileges, a successful DLL Hijacking can allow a user to execute code with those privileges. A necessary condition for this attack is a writable directory in the PATH accessible to a user with lower privileges.

The notable aspect is Microsoft’s approach to resolving vulnerabilities. Two critical exploits in Windows 8 and earlier, as well as Windows 10, were deemed unfixable. The older OS exploit was subtly resolved by releasing Windows 8.1 in 2013, without a solution for Windows 10. A machine’s PATH directory without proper access controls can lead to privilege escalation, highlighting the need for users to enforce strong access controls.

What does this mean for the end user?

In April 2018, Microsoft declared that weaknesses requiring a writable PATH directory are not considered vulnerabilities because directories should not allow global write access. Thus, exploitation through writable PATH directories won’t likely receive official patches, leaving users responsible for securing their PATH directory permissions.

Fortunately, such vulnerabilities are rare. Users rarely alter the system PATH environment variable and designating a world-writable directory is even less frequent. Nonetheless, installation processes can introduce security risks. ForestVPN employs stringent protective strategies to prevent its applications from loading code from writable PATH directories. It executes programs from secure paths and addresses DLL planting vulnerabilities effectively.

Users need to remain vigilant to protect their privacy and security. We’ve analyzed PATH vulnerabilities, clarifying misunderstandings, and provided a PowerShell script for auditing writable PATH directories. Running the script as a limited user can help identify and secure these directories by adjusting permissions.

Users are essential to system security, and equipping them with appropriate tools and technologies is crucial. Our insights into PATH vulnerabilities, paired with the provided script, will empower users to identify and address potential risks proactively, thwarting exploitation by adversaries. Stay vigilant and prioritize your digital security.