---

Introduction

SafeBreach Labs discovered a new vulnerability in Amazon HostedAgents HostedApplicationService which is deployed with Amazon’s Windows machines.

In this post, we describe the vulnerability we found in the Amazon HostedAgents HostedApplicationService.

We then demonstrate how this vulnerability could have been exploited by an attacker in order to achieve persistence, privilege escalation and in some cases defense evasion. The exploitation technique involves implanting an arbitrary unsigned executable which is executed during a post-exploitation phase by Amazon’s service that runs as NT AUTHORITY\SYSTEM.

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

Amazon Workspaces

Amazon WorkSpaces is a managed, secure Desktop-as-a-Service (DaaS) solution.

The service offers a cloud-based virtual desktop experience for end-users.

Vulnerability Discovery

In our initial exploration of the software, we targeted the “Amazon HostedAgents HostedApplicationService” process (Stxhd.HostAgents.HAService.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 pre-installed on Amazon’s Workspaces Windows image, which means that its impact as a vulnerability might be relatively bigger.
• This service automatically starts once the machine 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 the “Amazon HostedAgents HostedApplicationService” was started, the Stxhd.HostAgents.HAService.exe process was executed as NT AUTHORITY\SYSTEM.

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

As can be seen multiple times, the process looked for a missing EXE file (C:\Program.exe) before it found and executed the real executable file (.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 which is signed by Amazo?.

Root Cause Analysis

Once the Stxhd.HostAgents.HAService.exe is executed, it tries to execute multiple executables which are listed in the Stxhd.HostAgents.HAService.exe.config file:

Three of these executables don’t have a “runAs” attribute, which means that they will be created as NT AUTHORITY\SYSTEM:

1. C:/Program Files/Amazon/StxHD/HostAgents/InputInjectionAgent\Stxhd.HostAgents.InputInjectionAgent.exe1
2. C:/Program Files/Amazon/StxHD/HostAgents/StxhdAgent\Stxhd.HostAgents.StxhdAgent.exe1
3. C:/Program Files/Amazon/StxHD/HostAgents/LogonAgent\Stxhd.HostAgents.LogonAgent.exe

We can find the root cause of this vulnerability inside the implementation of the “LaunchProcessAsUser” method (which can be found in the “ProcessExtensions” class of the code):

Using the String.Format method, the program tries to concatenate the path of the executable with its arguments and pass it as the lpCommandLine parameter: “ ”.

The problem is that it doesn’t wrap the path of the executable with quotes (‘“” ’), so the CreateProcessAsUser function doesn’t know how to parse it properly.

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\Amazon\StxHD\HostAgents\StxhdAgent\<EXECUTABLE>.exe

Potential Malicious Uses and Impact.

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

Persistence Mechanism

The vulnerability 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 service just executes the malicious payload once the service is started.

Privilege Escalation

The vulnerability provides an attacker with the ability to gain NT AUTHORITY\SYSTEM access as an Administrator.

Timeline

Sep 22nd, 2019 – Vulnerability reported to Amazon

Sep 23th, 2019 – Initial response from Amazon

Sep 24th, 2019 – Amazon has confirmed the vulnerability

Oct 1st, 2019 – Amazon provided a timeline for patch deployment. They won’t issue a CVE because the environment is fully-controlled by them.

Oct 23rd, 2019 – Amazon has fixed the vulnerability.