During a recent engagement, our team discovered a local privilege escalation vulnerability in Asus' Armoury Crate software (version 5.3.4.0 and earlier). The vulnerability stems from an unquoted service path in the SetupAsusServices module (version 1.0.5.1 and earlier) that Asus distributes with the software.

When started on a Windows operating system, SetupAsusServices attempts to access several locations on the local C drive. This is due to the default behaviour of Windows when presented with file paths containing spaces. These locations were:

C:\
C:\Program Files\
C:\Program Files\ASUS\

This results in "NAME NOT FOUND" errors as shown below:

This behaviour can be exploited by a local attacker as long as they have write access to these locations. By placing a malicious executable in the requested path, it will be executed by the launched service with the privilege level of the application, which by default is system. Our team managed to exploit this vulnerability by placing a file named ARMOURY.exe in C:\Program Files\ASUS\, this granted our user elevated privileges after a system restart.

The service runs as an authenticated user with high integrity, enabling any malicious code to execute with powerful system privileges if successfully exploited. While local access is required, this poses a serious risk if chained with other vulnerabilities.

After responsibly disclosing this issue to ASUS, they promptly evaluated and patched the vulnerability in Armoury Crate by releasing version 5.3.4.0. This newer version mitigates the vulnerability by enclosing the file path with quotes, which prevents the iterative execution behaviour of Windows. We appreciate ASUS taking quick action patching this issue after our inital disclosure.

Is unquoted service path still relevant?

Unquoted service path vulnerabilities have been a known issue for over a decade but continue to appear in new software, demonstrating the persisting relevance of this vulnerability class.

An unquoted service path contains spaces but lacks quotation marks around the full path. This allows a local attacker with write access to somewhere along the affected path to insert a malicious executable file that will be run unintentionally by the vulnerable service.

The core issue stems from how Windows handles spaces in path names. By default, Windows uses spaces as delimiters to separate folder/file names in a path string. For example, consider the path:

C:\My Folder\MyProgram.exe

Windows will interpret this as:

• C:\My
• Folder\MyProgram.exe

It sees My and Folder as separate folder names because they are separated by a space. This causes problems when the space is intended to be part of the folder name My Folder rather than a delimiter.

On Windows systems, the operating system searches folders within an unquoted path and executes the first matching executable it finds. By placing a malicious executable first in the path, an attacker can exploit this behavior to escalate privileges when the service starts.

While simple to fix by properly quoting the path, many developers still overlook this crucial secure coding practice. Unquoted service path allow attackers to trivially bypass system permissions and controls. The prevalence of this issue in modern software highlights the need for continued education on properly handling path names in Windows services.

Best Practices to Resolve Unquoted Service Path

To mitigate the risk of unquoted service path vulnerabilities, developers should adhere to the following best practices:

• Always use quotes around service path: This is the most straightforward solution to the problem. By enclosing service path in quotes, you prevent the system from misinterpreting spaces as delimiters.

• Implement least privilege principle: Limit the privileges of your applications and services to only what they need to function.

Consider the following vulnerable service code:

void ServiceMain(int argc, char** argv) {

  char path[] = "C:\\Program Files\\MyService\\";
  
  SetCurrentDirectory(path);
  
  system("MyService.exe");

}

In the above code, the path passed to SetCurrentDirectory() is unquoted. This allows an attacker to place a malicious executable in C:\Program Files\ that will run instead of MyService.exe.

Here is the fixed code:

void ServiceMain(int argc, char** argv) {

  char path[] = "\"C:\\Program Files\\MyService\\\"";
   
  SetCurrentDirectory(path);
   
  system("MyService.exe");

}

By quoting the path, the service will correctly run MyService.exe as intended.

Quoting service path helps mitigate unquoted path vulnerabilities by ensuring the correct executables are called. It is a simple but critical secure coding practice on Windows platforms.

Responsible Disclosure Timeline

• November 29, 2022: Reported vulnerability to ASUS.
• December 12, 2022: ASUS security team confirms presence of vulnerability, noted that it will be fixed before the end of December.
• January 18, 2023: ASUS updated the release patch date to 30 January 2023
• January 31, 2023: Asus releases Armoury Crate new version resolving unquoted path vulnerability.