CVE-2021-43638: USB Over Ethernet | Multiple Vulnerabilities in AWS and Other Major Cloud Services

Executive Summary

• SentinelLabs has discovered a number of high severity flaws in driver software affecting numerous cloud services.
• Cloud desktop solutions like Amazon Workspaces rely on third-party libraries, including Eltima SDK, to provide ‘USB over Ethernet’ capabilities that allow users to connect and share local devices like webcams. These cloud services are in use by millions of customers worldwide.
• Vulnerabilities in Eltima SDK, derivative products, and proprietary variants are unwittingly inherited by cloud customers.
• These vulnerabilities allow attackers to escalate privileges enabling them to disable security products, overwrite system components, corrupt the operating system, or perform malicious operations unimpeded.
• SentinelLabs’ findings were proactively reported to the vulnerable vendors during Q2 2021 and the vulnerabilities are tracked as CVE-2021-42972, CVE-2021-42973, CVE-2021-42976, CVE-2021-42977, CVE-2021-42979, CVE-2021-42980, CVE-2021-42983, CVE-2021-42986, CVE-2021-42987, CVE-2021-42988, CVE-2021-42990, CVE-2021-42993, CVE-2021-42994, CVE-2021-42996, CVE-2021-43000, CVE-2021-43002, CVE-2021-43003, CVE-2021-43006, CVE-2021-43637, CVE-2021-43638, CVE-2021-42681, CVE-2021-42682, CVE-2021-42683, CVE-2021-42685, CVE-2021-42686, CVE-2021-42687, CVE-2021-42688.
• Vendors have released security updates to address these vulnerabilities. Some of these are automatically applied while others require customer actions.
• At this time, SentinelLabs has not discovered evidence of in-the-wild abuse.

Introduction

Throughout 2020-2021, organizations worldwide needed to adopt new work models, including work from home (WFH), in response to the COVID-19 pandemic. This required organizations to make use of various solutions that allow WFH employees to securely access their organization’s assets and resources. As a result, the market for WFH solutions has seen tremendous growth, but security has not necessarily evolved accordingly.

In this post, we disclose details of multiple vulnerabilities we discovered in major cloud services including:

• Amazon Nimble Studio AMI, prior to: 2021/07/29
• Amazon NICE DCV, below: 2021.1.7744 (Windows), 2021.1.3560 (Linux), 2021.1.3590 (Mac), 2021/07/30
• Amazon WorkSpaces agent, below: v1.0.1.1537, 2021/07/31
• Amazon AppStream client version below: 1.1.304, 2021/08/02
• NoMachine [all products for Windows], above v4.0.346 below v.7.7.4 (v.6.x is being updated as well)
• Accops HyWorks Client for Windows: version v3.2.8.180 or older
• Accops HyWorks DVM Tools for Windows: version 3.3.1.102 or lower (Part of Accops HyWorks product earlier than v3.3 R3)
• Eltima USB Network Gate below 9.2.2420 above 7.0.1370
• Amzetta zPortal Windows zClient <= v3.2.8180.148
• Amzetta zPortal DVM Tools <= v3.3.148.148
• FlexiHub below 5.2.14094 (latest) above 3.3.11481
• Donglify below 1.7.14110 (latest) above 1.0.12309

It is important to note that:

1. These vulnerabilities originated from a library developed and provided by Eltima, which is in use by several cloud providers.
2. Both the end user (AWS WorkSpaces client in this example) and cloud service (AWS WorkSpaces running in AWS Cloud) are vulnerable to various vulnerabilities we will discuss below. This peculiarity can be attributed to code-sharing between both the server side and client side applications.
3. While we have confirmed these vulnerabilities for AWS, NoMachine and Accops, our testing was limited in scope to these vendors, and we believe it is highly likely other cloud providers using the same libraries would be vulnerable.
4. Also, of the vendors tested, not all vendors were tested for both client side and server side vulnerabilities; consequently, there might also be further instances of the vulnerabilities there.

Technical Details

While these vulnerabilities affect multiple products, the technical details below will mainly focus on AWS WorkSpaces as an example. This is where our research began, and the flaws are essentially the same across all mentioned products.

Amazon WorkSpaces is a fully managed and persistent desktop virtualization service that enables users to access data, applications, and resources they need anywhere from any supported device. WorkSpaces supports provisioning Windows or Linux desktops and can be quickly scaled to provide thousands of desktops to workers across the globe.

WorkSpaces increases security by keeping data off the end user’s device and increasing reliability with the power of the AWS Cloud, an increasingly valuable service for the growing remote workforce.

WorkSpaces architecture; source: AWS

As shown above, authentication and session orchestration is done over HTTPS, while the data stream is either PCoIP (PC Over IP) or WSP (WorkSpaces Streaming Protocol), a proprietary protocol.

The main difference between them is that on Amazon WorkSpaces, only WSP supports device redirection such as smart cards and webcams. This is where the vulnerabilities reside.

The WSP protocol consists of several libraries, some of which are provided by 3rd parties. One of these is the Eltima SDK. Eltima develops a product called “USB Over Ethernet”, which enables remote USB redirection.

The same product, with some modifications, is used by Amazon WorkSpaces to enable its users to redirect USB devices to their remote desktop, allowing them to connect devices such as USB webcams to Zoom calls directly from the remote desktop.

The program is bundled with the “client” (connect to other shared devices) and the “server” (share a device over the internet):

USB Over Ethernet screenshot; source: Eltima

The drivers responsible for USB redirection are wspvuhub.sys and wspusbfilter.sys, both of which are vulnerable and seem to have been in use since the beginning of 2020, when WSP protocol was announced.

Before going through the vulnerabilities, it’s important to understand how the Windows Kernel IO Manager (IOMgr) works. When a user-mode thread sends an IRP_MJ_DEVICE_CONTROL packet, it passes input and output data between the user-mode and kernel-mode, depending on the I/O Control (IOCTL) code invoked. As per Microsoft’s documentation, “an I/O control code is a 32-bit value that consists of several fields”, as illustrated in the following figure:

Input/output Control Code Structure; source: Microsoft

For the purposes of this post, we will focus on the two least significant bits, TransferType. The documentation tells us that these bits indicate how the system will pass data between the caller of NtDeviceIoControlFile syscall and the driver that handles the IRP.

There are three ways to exchange data between kernel mode and user mode using an IRP:

1. METHOD_BUFFERED – considered the most secure. Using this method IOMgr will copy the caller input data out of, and then into, the supplied caller output buffer.
2. METHOD_IN/OUT_DIRECT – Depending on the data direction, the IOMgr will supply an MDL that describes a buffer, and ensures that the executing thread has read/write-access to the buffer. IOCTL routines can then lock the buffer to the memory.
3. METHOD_NEITHER – considered more prone to faults. The IOMgr doesn’t map/validate the supplied buffer; the IOCTL handler receives a user-mode address. This is mostly used for high speed data processing.

The vulnerable IOCTL handlers, which contain several vulnerabilities and are the same across all vulnerable products, are 0x22005B and 0x22001B.

This code deals with a user buffer of type METHOD_NEITHER (Type3InputBuffer)

This means that the IOCTL handler is responsible for validating, probing, locking, and mapping the buffer itself depending on the use case.

This opens up many possibilities to exploit the device, such as double fetches, and arbitrary pointer dereference, which can lead to other vulnerabilities as well. In the image below, it can be seen that buffer verification does not exist at all in this code:

IOCTL 0x22001B Handler

Here’s a brief explanation of this code:

1. First, the routine checks whether the calling process is 32bit or 64bit (red arrow).
2. It then decides whether to use alloc_size_64bit or alloc_size_32bit based on the first check’s results (blue arrow) .
3. Next, there is a call to ExAllocatePoolWithTag_wrapper with user controlled size parameter (pink arrow).
4. At this point, the code proceeds to blocks that handle 32 bit memmove (yellow arrow) and 64 bit memmove (green arrow). As can be seen in the image, at this stage there are cases of insecure arithmetic operations on user controlled data without any overflow checks when calculating the copy size, which can lead to integer overflows that might eventually lead to arbitrary code execution.

Generally speaking, accessing (reading/writing) user-mode addresses requires probing. Dealing with Type3InputBuffer also requires you to lock the pages to the memory and only fetch data once.

The easiest way to cause an overflow in this code is by passing different parameters for the allocation and copy functions. This can be done by crafting a special IRP:

struct struct_usercontrolled { int gap1; int firstObject_handle; int secondObject_handle; int thirdObject_handle; int alloc_size_32bit; unsigned int gap2; unsigned int copy_size_32bit; unsigned int alloc_size_64bit; unsigned int gap3; unsigned int copy_size_64bit; }

Where either copy_size_64bit or copy_size_32bit are greater than alloc_size_32bit or alloc_size_64bit.

Even if the copy size and allocation size were the exact same parameter, the code is still exploitable due to the fact that there are insecure arithmetic operations when calculating the memmove size parameter.

In a simplified version, to trigger this vulnerability, an attacker may send the following IOCTL (assuming running a 64bit process):

uc.alloc_size_64bit = 0x20; uc.copy_size_64bit = 0x100;

memset(&ol, 0, sizeof(ol)); // _OVERLAPPED HANDLE EventW = CreateEventW(NULL, TRUE, FALSE, NULL); ol.hEvent = EventW;

if (!DeviceIoControl(file_device_handle, 0x22001B, &uc, size, &OutBuffer, 8u, &NumberOfBytesTransferred, &ol) && (GetLastError() != ERROR_IO_PENDING || !GetOverlappedResult(file_device_handle, &ol, &NumberOfBytesTransferred, 1))) { exit(printf(“IOCTL 0x22001B\r\n”)); }

This code will result in allocation of 0x20 bytes:

3: kd> r rax=0000000000000000 rbx=ffff92889d98ad40 rcx=0000000000000001 rdx=0000000000000020 rsi=ffff92889d98a000 rdi=000000603e8ff5c8 rip=fffff80627175366 rsp=ffffde0f29eed6e0 rbp=0000000000000000 r8=0000000000004c50 r9=fffff806271761e0 r10=fffff80627170ca0 r11=0000000000000000 r12=ffff92889962bc40 r13=0000000000000000 r14=0000000000000020 r15=ffff92889949eb38 iopl=0 nv up ei pl zr na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246 wspvuhub+0x15366: fffff806`27175366 e899c6ffff call wspvuhub+0x11a04 (fffff806`27171a04)

and copying of 0x435 bytes:

3: kd> r rax=ffffad0e69959eb0 rbx=ffff92889d98ad40 rcx=ffffad0e69959eb0 rdx=000000603e8ff5c8 rsi=ffffad0e69959eb0 rdi=000000603e8ff5c8 rip=fffff80627175420 rsp=ffffde0f29eed6e0 rbp=0000000000000000 r8=0000000000000435 r9=00000000000001b0 r10=0000000000004c50 r11=0000000000001001 r12=ffff92889962bc40 r13=0000000000000000 r14=0000000000000020 r15=ffff92889949eb38 iopl=0 nv up ei pl zr na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246 wspvuhub+0x15420: fffff806`27175420 e85b090000 call wspvuhub+0x15d80 (fffff806`27175d80)

Since we control both the data and the size this makes a very strong primitive to achieve code execution in kernel mode.

BSoD Proof Of Concept

Using the DeviceTree tool from OSR, we can see that this driver accepts IOCTLs without ACL enforcements (note: Some drivers handle access to devices independently in IRP_MJ_CREATE routines):

Using DeviceTree software to examine the security descriptor of the device

This means the vulnerability can be triggered from sandboxes and might be exploitable in contexts other than just local privilege escalation. For example, it might be used as a second stage browser attack (although most modern browsers have a list of allowed IOCTLs requests) or other sandboxes for that matter.

Impact

• Who is affected? Users with the mentioned client versions are prone to vulnerabilities that if exploited successfully may be used to gain high privileges. Since the vulnerable code exists in both the remote and local side, remote desktops are also affected by this vulnerability.

• What is the risk? These high severity flaws could allow any user on the computer, even without privileges, to escalate privileges and run code in kernel mode. Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products. An attacker with access to an organization’s network may also gain access to execute code on unpatched systems and use this vulnerability to gain local elevation of privilege. Attackers can then leverage other techniques to pivot to the broader network, like lateral movement.

Recommendations

We responsibly disclosed our findings to product vendors. We are aware of the following vendor responses:

Accops has released an advisory page here.

NoMachine has released an advisory page here.

On AWS (Amazon Workspaces), a manual update needs to be performed if you either have:

1. AutoStop WorkSpaces with maintenance turned off.
2. AlwaysOn WorkSpaces with OS updates turned off.

In order to check your maintenance settings:

1. Open the WorkSpaces console at https://console.aws.amazon.com/workspaces/.
2. In the navigation pane, choose Directories.
3. Select your directory, and choose Actions, Update Details.
4. Expand Maintenance Mode.

Make sure to update the client application.

While we have no evidence of in-the-wild exploitation of these vulnerabilities, we further recommend revoking any privileged credentials deployed to the platform before the cloud platforms have been patched and checking access logs for irregularities.

Conclusion

Vulnerabilities in third-party code have the potential to put huge numbers of products, systems, and ultimately, end users at risk, as we’ve noted before. The outsized effect of vulnerable dependency code is magnified even further when it appears in services offered by cloud providers. We urge all organizations relying on the affected services to review the recommendations above and take appropriate action.

As part of the commitment of SentinelLabs to advancing public cloud security, we actively invest in public cloud research, including advanced threat modeling and vulnerability testing of cloud platforms and related technologies. For maximum protection, we strongly recommend using SentinelOne Singularity platform.

We would like to thank those vendors that responded to our disclosure and for remediating the vulnerabilities quickly.

Disclosure Timeline

Amazon

• May 2, 2021 – Initial disclosure.
• May 2, 2021 – First response from AWS security team.
• May 7, 2021 – AWS security team report that they’re still actively investigating the issue.
• May 13, 2021- AWS security team report that they’re still actively investigating the issue.
• May 18, 2021 – AWS security team acknowledged the reported issues.
• Jun 25, 2021 – AWS security team reported that they pushed out a fix to all regions.
• Jul 1, 2021 – AWS security team asked for more technical details regarding the issues.
• Jul 11, 2021 – SentinelOne answers the questions.

Eltima

• Jun 6, 2021 – Initial disclosure.
• Jun 14, 2021 – Eltima Support first responded that they’re reviewing the report.
• Jun 15, 2021 – Eltima Support claimed that they are aware of the vulnerabilities, but it’s resolved because the feature is turned off.
• Jun 15, 2021- We responded that the product is still vulnerable even if the feature is turned off.
• Jun 15, 2021 – Eltima Support responded that they discontinued using those IOCTLs due to security reasons but for backward compatibility they still keep it.
• Jun 19, 2021 – We clarified that the vulnerable code is still reachable and exploitable.
• Jun 29, 2021 – Eltima Support responded that their team started the work on a new build without the mentioned vulnerabilities.
• Jul 1, 2021 – Eltima Support requests more time.
• Sep 6, 2021- Eltima notified us that they released fixed versions for their products.

Accops

• Jun 28, 2021 – Initial disclosure.
• Jun 28, 2021 – Accops first responded that they’re reviewing the report.
• Sep 5, 2021 – Accops reported that the issue is fixed and updated modules are available from Accops website and support portal for download. Customers are notified to upgrade to new versions. Fixed modules are Accops HyWorks Client for Windows version 3.2.8.200 onwards and Accops HyWorks DVM Tools for Windows version 3.3.1.105 onwards (part of Accops HyWorks release 3.3 R3).
• Dec 4, 2021 – Accops has released a utility to detect vulnerable endpoints. The utility is downloadable from Accops support site.

Mechdyne

• We tried to contact Mechdyne several times during June 2021 to September 2021 but did not receive a response.

Amzetta

• Jul 1, 2021 – Initial disclosure.
• Jul 2, 2021 – Amzetta acknowledges the vulnerabilities and removed the product from their website.
• Sep 3, 2021 – Amzetta notified us that they released fixed versions for their products.

NoMachine

• Jun 28, 2021 – Initial disclosure.
• Jul 5, 2021 – NoMachine acknowledges the vulnerabilities.
• Oct 21, 2021 – NoMachine informed us that the patches are released.