- The Dyson Airwrap is $120 off ahead of Black Friday - finally
- This 5-in-1 charging station replaced several desk accessories for me (and it's 33% off for Black Friday))
- The best Galaxy Z Flip 6 cases of 2024
- This retractable USB-C charger is my new favorite travel accessory (and it's on sale for Black Friday)
- Skip the iPad: This tablet is redefining what a kids tablet can do, and it's 42% off for Black Friday
Critical RDP Vulnerabilities Continue to Proliferate | McAfee Blogs
This month’s Patch Tuesday brings us a relatively small number of CVEs being patched, but an abnormally high percentage of noteworthy critical vulnerabilities.
Vulnerability Analysis: CVE-2021-34535
One such vulnerability is identified as CVE-2021-34535, which is a remote code execution flaw in the Remote Desktop client software, observed in mstscax.dll, which is used by Microsoft’s built-in RDP client (mstsc.exe). The vulnerability is very closely related to a bug released in July of 2020, CVE-2020-1374, which also came through Microsoft’s Patch Tuesday process and had highly similar characteristics. The vulnerability is an integer overflow due to an attacker-controllable payload size field, which ultimately leads to a heap buffer overflow during memory allocation. The vulnerability can be triggered via the RDP Video Redirection Virtual Channel Extension feature [MS-RDPEV], which is typically deployed on port 3389, and is contained inside of compressed UDP payload and encrypted RDP using TLS.
But does this flaw, despite its impressive 9.9 CVSS score, rise to the level of past RDP vulnerabilities, including the infamous BlueKeep (CVE-2019-0708)? Not so fast – there are a few additional factors to take into consideration.
Attack Scenario
First and foremost, this is a client-side vulnerability, meaning there is no real ability for self-propagation, or “wormability” from an Internet perspective. The most likely attack scenario would be to convince a user to authenticate to a malicious RDP server, where the server could trigger the bug on the client side. During reproduction of the issue, we were able to easily trigger the crash and observe a later memcpy using the controlled overflow, which should facilitate exploitation. We think it is likely that exploits will be developed for this vulnerability but the availability of a patch prior to any known public exploitation helps to mitigate risks for organizations and individuals.
Secondly, thanks to the widespread proliferation and reach of BlueKeep and other related RDP vulnerabilities, a significant portion of RDP clients and servers have been disabled or moved from the network perimeter. This is less important given the client-side nature of the bug but does help with the overall attack surface.
In addition to Microsoft’s built-in RDP client (mstsc.exe), which is the more common Remote Desktop network connection, we have also confirmed that some lesser- known RDP vectors are affected by this vulnerability. Microsoft Hyper-V Manager “Enhanced Session Mode” and Microsoft Defender’s Application Guard (WDAG) both use RDP to screen share and present the secured browser respectively. This gives the end user a remote view of their isolated instance in the context of the host system. Rather than reimplementing the RDP session sharing capability, Microsoft ported the existing RDP client code base into Hyper-V and WDAG. Since the RDP client code is self-contained in mstscax.dll (an ActiveX COM object) it can simply be loaded into the Hyper-V (vmconnect.exe) and WDAG (hvsirdpclient.exe) processes to avail of the RDP client functionality. There does not appear to have been any attack surface reduction on this code base as the same DLL is loaded within all three processes mstsc.exe, vmconnect.exe and hvsirdpclient.exe. The impacted components are:
- Microsoft’s built-in RDP client mstsc.exe uses the vulnerable mstscax.dll when a client remotely connects to an RDP server over the network. We have confirmed mstsc.exe crashes and the vulnerability can be triggered then the client has authenticated to an RDP server.
Mitigation: Patch
- Microsoft’s Hyper-V Manager software also uses mstscax.dll where the vulnerable function resides. When using “Enhanced Session Mode” (enabled by default in Hyper-V Manager), the process vmconnect.exe loads mstscax.dll. We have confirmed through testing that triggering the vulnerability from inside a Hyper-V Windows 10 image will crash vmconnect.exe on the host. This means that it is subject to guest-to-host escapes using the vulnerability. (Hyper-V is disabled by Default on Windows 10).
Mitigation: Patch or disable “Enhanced Session Mode”
- Microsoft Defender’s Application Guard also uses mstscax.dll to present the user with a view of their containerized Edge and IE browser. When a “New Application Guard window” is navigated from Edge it launches the process hvsirdpclient.exe which loads mstscax.dll. We have not confirmed the WDAG process hvsirdpclient.exe crashes but it does use the same code base so we recommend patching if using WDAG (WDAG is disabled by Default on Windows 10).
Looking Forward
The built-in RDP client and Hyper-V/WDAG clients communicate over different transport mediums in the form of TCP/IP and VMBus but they both use the same RDP client protocol implementation. Given that the flaw is contained within mstscax.dll, and is self-contained, the vulnerability was ported to these two implementations along with the rest of the code base.
While the urgency for patching remains somewhat lower than past critical vulnerabilities, threat actors will look to weaponize any of these low-hanging fruit that leverage common network protocols. Patching should be a top priority, and furthermore, a comprehensive and ongoing review of internet-facing and internal networked RDP clients and servers would be highly recommended. Eliminating or reducing the attack surface is one of the best counter attacks to vulnerability exploitation.
Microsoft have published a Knowledge Base article for the issue here with corresponding patch information. In the meantime, we are continuing to monitor this vulnerability closely; if exploitation is observed we may release additional content for customers.
For RDP security best practices please see https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/
With thanks to Cedric Cochin, McAfee.