EAA Client Escalation of Privilege Vulnerability on Windows

This post covers the details of CVE-2021-40683 (CVSS 6.5), the vulnerability impacting the Akamai Enterprise Application Access (EAA) Client running on Windows systems, for which Akamai has provided a patch to its customers.

On August 31, 2021, Akamai was notified by a customer conducting an assessment of the EAA Client application that they had identified an unquoted service path vulnerability introduced when installing the client on an endpoint. Upon reviewing the report, Akamai initiated its incident management process to verify the report, create a fixed version of the EAA Client, and communicate the need for patching to its customers. Details about the vulnerability, the potential impact on clients, and the remediation process are covered in the remainder of this post.

Vulnerability overview

The vulnerability identified in the EAA Client is known as an unquoted service path or a path interception by unquoted path vulnerability. This vulnerability takes advantage of a weakness in the way Windows handles paths provided when spawning a new process, either through the CreateProcess function or through a service registered in the Windows registry. In either method of invocation, the path to the executable, or the ImagePath in the case of a Windows service, must be quoted if the path contains a space to limit the potential for an unexpected application to be run. This unexpected behavior stems from the way in which Windows will interpret spaces in a path, like that found in C:\Program Files, if the path is not quoted. With both invocations, when an unquoted space is encountered, the path before the space will be checked for an executable meeting the invocation’s criteria. In most cases, no such application will exist, and the processing will continue until the full path of the executable is reached and launched.

By way of example from the CreateProcess documentation, if there is an executable at C:\Program Files\Sub Dir\Program Name.exe, the operating system will attempt to launch the following applications, if present, 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 checking of additional paths may allow an adversary the opportunity to place a malicious process at any of the paths listed above, which would be executed with the same level of permissions as the expected process, and could lead to an escalation of privilege when a higher-privilege identity is used, like in the case of the EAA Client.

The solution to avoid this search processing is presented in the Security Remarks section of the same documentation, which recommends putting any path that includes spaces in quotes, which will indicate that searching should not be conducted. For the example above, the recommendation would be to use the string “C:\Program Files\Sub Dir\Program Name.exe” for any invocation of that executable.

In the case of the EAA Client, a Windows service is installed to enable the client to operate. Prior to the fix, the ImagePath, or path to the executable to launch for the service, was set to

C:\Program Files\EAAClient\wapptunneld.exe

and following the fix, the path was set to

“C:\Program Files\EAAClient\wapptunneld.exe”

During our investigation, our engineering and security teams tested to ensure that, by default, windows restricts the creation of files at C:\Program.exe to administrative-level users, which dramatically limits the exposure of this issue. But out of an abundance of caution, we continued to develop and release the fixed version of our client in the event that some environments deviate from the default permissions for C:\.

Potential impact

Due to the path searching, there was a potential for an actor to place a malicious executable at the path C:\Program.exe, which would have been executed as an administrator when attempting to launch the EAA Client service, either at machine boot or when the EAA Client service restarted for some reason. If this were to happen, the malicious application would have had administrative access to the system and would have been able to take any action an administrator could.

During the analysis of the issue, we determined that the default configuration of Windows would restrict changes to the required path to administrative users, thus requiring a similar level of access as an actor would get by conducting this type of attack. Additionally, if this vulnerability were exploited, the wapptunneld executable would not be started, preventing the EAA Client on the endpoint from functioning, which would likely require further investigation or remediation.

Suggested actions

Akamai recommends that all Windows endpoints running the EAA Client be upgraded to one of the fixed versions, which are 2.5.3, 2.4.1, and 2.3.1. At this time, no older versions have been fixed, as their support has ended.

Akamai also recommends reviewing other applications and services installed on endpoints to ensure that they are not vulnerable to this same attack, as this method is not specific to the EAA Client.

Timeline

All times in UTC

We elected to delay disclosure of the details of the vulnerability to allow customers to patch their endpoints prior to disclosure.

Acknowledgments

We would like to thank Shafi Ur Rahman, Pallerla Vishnu Vardhan Reddy, and Virtusa for identifying the vulnerability and responsibly disclosing the vulnerability to Akamai.