Introduction

SafeBreach Labs discovered a new vulnerability in the ASUS ATK Package which is pre-installed on ASUS computers.

In this post, we describe the CVE-2019-XXXX vulnerability we found in the ASUS ATK Package. We then demonstrate how this vulnerability could have been exploited by an attacker during a post-exploitation phase, in order to achieve persistence and in some cases defense evasion. The exploitation technique involves implanting an arbitrary unsigned executable which is executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability, the attacker needs to have Administrator privileges.

ASUS ATK Package

This app includes a set of utilities which allow users to define the functionality of computer keyboard hot keys (Fn) and other ASUS drivers and software [1]

Vulnerability

Discovery

In our initial exploration of the software, we targeted the “ASLDR Service” (AsLdrSrv.exe), because:

• It runs as NT AUTHORITY\SYSTEM – the most privileged user account. This kind of service might be interesting to attackers when looking for privilege escalation to SYSTEM, which is very useful and powerful.
• The executable of the service is signed by “ASUSTek Computer Inc.” If the attacker finds a way for a malicious payload to be executed by AsLdrSrv.exe, the service can be used as an application whitelisting bypass.
• This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.

In our exploration, we found that after “ASLDR Service” was started, the AsLdrSrv.exe signed process was executed as NT AUTHORITY\SYSTEM.

We noticed an interesting behavior once the service’s process was executed:

As can be seen, AsLdrSrv.exe looked for missing EXE files before it executed the required one (“C:\Program Files (x86)\ASUS\ATK Package\ATK Hotkey\HControl.exe”):

1. C:\Program.exe
2. C:\Program Files(x86)\ASUS\ATK.exe
3. C:\Program Files(x86)\ASUS\ATK Package\ATK.exe

PoC Demonstration

In order to test this privilege escalation vulnerability, we compiled an EXE file (unsigned) which writes the following to the filename of a txt file:

1. The name of the process which loaded it
2. The username which executed it

Our arbitrary unsigned EXE file was executed as NT AUTHORITY\SYSTEM by a legitimate process (without changing the service’s path or overwriting any file).

Root Cause Analysis

Once the AsLdrSrv.exe process started, it tried to spawn the “HControl.exe” process, performing the following steps:

First, the “HControl.exe” process name was concatenated to the path of the AsLdrSrv.exe executable (“C:\Program Files (x86)\ASUS\ATK Package\ATK Hotkey\”) and saved into the ATK_path buffer.

Next, it called the CreateProcessAsUserW WinAPI function with the ATK_path buffer, in order to start the HControl.exe process. In our case, the ATK_path buffer turned into:

“C:\Program Files (x86)\ASUS\ATK Package\ATK Hotkey\HControl.exe”

The ATK_path parameter is not a quoted string, which is the root cause of the unquoted search path vulnerability.

The final path contains a space (“Program Files(x86)”), and the CreateProcessAsUserW function doesn’t know whether it’s part of the path or whether it’s an argument, so it tries to parse it by itself.

According to the CreateProcessAsUser function documentation in MSDN, we will see the following:

The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous.

For example, consider the string “c:\program files\sub dir\program name”. This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

c:\program.exe c:\program files\sub.exe c:\program files\sub dir\program.exe c:\program files\sub dir\program name.exe

The root cause of this unquoted search path vulnerability happens because the command line doesn’t contain a quoted string between the path of the executable and the argument – so the CreateProcessAsUser function tries to split it by itself each time it parses a space character:

1. C:\Program.exe
2. C:\Program Files(x86)\ASUS\ATK.exe
3. C:\Program Files(x86)\ASUS\ATK Package\ATK.exe

Potential Malicious Uses and Impact.

Below we show three possible ways that an attacker could have leveraged the CVE-2019-xxxxx vulnerability we discovered and documented above.

Defense Evasion / Whitelisting Bypass

The vulnerability gives attackers the ability for malicious payloads to be executed by a signed service**. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability also gives attackers the ability to execute malicious payloads in a persistent way, each time the service is loaded. That means that once the attacker drops a malicious EXE file in one of the paths we mentioned earlier, the service will load the malicious code each time it is restarted. This way the malicious payload might not be detected by security products, because the service process which executes the attacker’s payload is signed, and executes it “natively.” No suspicious action is required by the attacker. The serviceit just executes the malicious executable once it is started.

Affected Versions

ATK Package version 1.0.0060 and all prior versions

Timeline

Sep 2nd, 2019 – Vulnerability reported to ASUS

Sep 5th, 2019 – ASUS confirmed the vulnerability.

Oct 7th, 2019 – ASUS released a new driver.

Oct 21st, 2019 – ASUS released a patched version [2] and a security advisory [3].

Dec 5th, 2019 – ASUS issued CVE-2019-19235

References

[1] https://www.filehippofile.com/atk-package/

[2] https://www.asus.com/support/faq/1041545

[3] https://www.asus.com/Static_WebPage/ASUS-Product-Security-Advisory/