UPDATE
LAS VEGAS — Multiple critical vulnerabilities in the commonly used Remote Desktop Protocol (RDP) would allow a malicious actor to achieve remote code-execution over a client’s computer.
According to Check Point research released Tuesday at the CPX360 event in Las Vegas, both open-source and Microsoft proprietary RDP clients are at risk from an attacker who has either set up a malicious RDP server within a network, or who has compromised a legitimate one using other vulnerabilities.
Used by thousands upon thousands of enterprise users worldwide, RDP is a common application that allows those working remotely to connect to corporate resources; and, which allows tech support staff and researchers to connect to remote computers for diagnostic and support purposes.
To use RDP, teleworkers and support staff would have RDP clients installed on their machines that connect to a remote RDP server host.
“In a normal scenario, you use an RDP client, and connect to a remote RDP server that is installed on the remote computer,” Check Point explained in an analysis shared with Threatpost. “After a successful connection, you now have access to and control of the remote computer, according to the permissions of your user. But if the scenario could be put in reverse? We wanted to investigate if the RDP server can attack and gain control over the computer of the connected RDP client.”
It turns out that the vulnerabilities make it possible to do just that, essentially reversing the usual direction of communication and infecting the client computer – that in turn could then allow for an intrusion into the IT network as a whole.
According to Check Point, 16 major vulnerabilities and a total of 25 security vulnerabilities were found overall across the clients it examined; these include mstsc.exe (Microsoft’s built-in RDP client); FreeRDP (the most popular and mature open-source RDP client on Github, Check Point said); and rdesktop (an older open-source RDP client that comes by default in Kali-linux distros, often used by security research red teams for penetration testing).
Also, additional analysis showed that the xrdp open-source RDP server is based on the code of rdesktop, while the RDP client NeutrinoRDP is a fork of an older version (1.0.1) of FreeRDP. So, the team postulated that these two probably suffer from similar vulnerabilities as the parent code.
Attack Scenarios
Check Point analysis shows that there are a few common scenarios in which an attacker can gain elevated network permissions by deploying such an attack, thus advancing his lateral movement inside an organization.
For instance, a malefactor could attack an IT member that connects to an infected work station inside the corporate network, thus gaining higher permission levels and greater access to the network systems.
Or, a bad actor could attack a malware researcher that connects to a remote sandboxed virtual machine that contains a tested malware. This allows the malware to escape the sandbox and infiltrate the corporate network.
A third, less likely scenario would be if blue security research teams installed organizational honeypots to attack red teams that try to connect to them through the RDP protocol.
As mentioned, the feasibility of any attack relies on the perpetrator gaining prior access to an RDP server (or to set up a rogue one) – a notable mitigating factor.
Open-Source RDP Flaws
rdesktop
The analysis kicked off with manually parsing the code for rdesktop v1.8.3, with the researchers finding “several vulnerable patterns in the code.” At the end of the process, the team had uncovered 11 vulnerabilities with a major security impact, and 19 vulnerabilities overall in the library.
The most severe of these, RCE flaws with the CVE range of 2018-20179 to 2018-20181, arise from the fact that the code doesn’t check to make sure that the packet sent by the server is the right size before trying to parse it. If the server sends too many bytes (more than eight), the stream connecting the server to the client breaks, allowing for an information disclosure.
“The fields ‘length’ and ‘flags’ are parsed from the stream ‘s,’ without checking that ‘s’ indeed contains the required eight bytes for this parsing operation,” according to the analysis. “While this usually only leads to an out-of-bounds read, we can combine this vulnerability with an additional vulnerability in several of the inner channels and achieve a much more severe effect.”
Three logical channels share this second vulnerability: “lspci,” “rdpsnddbg” (a debug channel that is always active); and “seamless.” If an RDP server has a malicious, proprietary implementation of a process called “STRNCPY” (the researchers didn’t detail this), it’s possible to trigger a massive heap-based buffer overflow when copying data to the small allocated heap buffer.
“By chaining together these two vulnerabilities, found in three different logical channels, we now have three remote code-execution vulnerabilities,” according to the analysis.
Another concerning RCE flaw, CVE 2018-8795, allows an integer-overflow flaw when processing screen-content updates.
“Although width and height are only 16 bits each, by multiplying them together with bits-per-pixel, we can trigger an integer-overflow,” analysts noted. “Later on, the bitmap decompression will process our input and break on any decompression error, giving us a controllable heap-based buffer-overflow.”
rdesktop has patched the issues as part of its v1.8.4 release.
FreeRDP
The researchers also looked at FreeRDP v.2.0.0-rc3, which initially fares better in some ways than rdesktop; there are, for instance, minimal size checks before parsing data from the server.
“However, after a deeper examination, we started to find cracks in the code,” the team said: Overall, there were six flaws in the library, five of which represent a major security impact.
For one, FreeRDP suffers from the same screen-content integer-overflow RCE flaw, in this case assigned CVE 2018-8787.
Unique to FreeRDP however is the CVE 2018-8786 RCE flaw, which is an integer-truncation problem that arises when trying to calculate the required capacity for the bitmap updates array.
“Later on, rectangle structs will be parsed from our packet and into the memory of the too-small allocated buffer,” analysts explained. “This specific vulnerability is followed by a controlled amount (“bitmapUpdate->number”) of heap allocations (with a controlled size) when the rectangles are parsed and stored to the array, granting the attacker a great heap-shaping primitive.”
FreeRDP has patched the flaws as part of it s2.0.0-rc4 release.
The researchers released a proof-of-concept video:
Microsoft’s RDP Client
As part of its research, the team also reverse-engineered Microsoft’s RDP client, bBuild 18252.rs_prerelease.180928-1410.
“Microsoft’s implementation is much better than the implementations we tested previously,” the researchers said. “Actually, it seems like Microsoft’s code is better by several orders of magnitude.”
The code for instance contains several optimization layers for efficient network streaming, robust input and decompression checks, to guarantee that no byte will be written past the destination buffer; and there are checks for integer-overflows when processing bitmap updates.
However, the team uncovered what it considers to be a major flaw in the copy-and-paste clipboard feature, which allows information to be transferred over an RDP connection. The server accesses the clipboard through a broker application called rdpclip.exe. This talks to the RDP service using a dedicated virtual channel API. However, Microsoft’s code doesn’t verify that what’s being sent hasn’t been tampered with.
Courtesy: Check Point
“A malicious RDP server can transparently drop arbitrary files to arbitrary file locations on the client’s computer,” according to the analysis. “For example, we can drop malicious scripts to the client’s startup folder, and after a reboot, they will be executed on his computer, giving us full control.”
Check Point created a PoC exploit, where the researchers “simply killed rdpclip.exe, and spawned our own process to perform the path-traversal attack by adding additional malicious file to every copy-and-paste operation:”
The attack was performed with “user” permissions, and does not require the attacker to have system or any other elevated permission.
Also, they found that every time a clipboard is updated on either side of the RDP connection, a message is sent to the other side, to notify it about the new clipboard formats that are now available.
“We can think of it as a complete sync between the clipboards of both parties,” the team noted. “This means that our malicious server is notified whenever the client copies something to his ‘local’ clipboard, and it can now query the values and read them. So for instance, if a client locally copies an admin password, the server would then have it too.
In addition, the server can notify the client about a clipboard update without the need for a copy operation inside the RDP window, thus allowing an attacker to completely control the client’s clipboard without being noticed.
“A malicious RDP server can modify any clipboard content used by the client, even if the client does not issue a copy operation inside the RDP window,” according to the analysis. “if you copy a file on your computer, the server can modify your file, piggy-back on your copy to add additional files, or carry out the path-traversal files using the previously shown [attack].”
According to Check Point, Microsoft acknowledged the findings, but said that the issues aren’t severe enough to address: “As a result, this path traversal has no CVE-ID, and there is no patch to address it,” according to the analysis, adding that the team recommends that users to disable the clipboard-sharing channel (on by default) when connecting to a remote machine.
Threatpost reached out to Microsoft, and received a confirmation that no action will be taken: “The technique assumes a RDP server has already been compromised by another method. We have no current plans to address this particular scenario with a security update,” a Microsoft spokesperson said.
This post was updated at 2:49 p.m. ET on Feb. 5 to reflect a statement from Microsoft.
