Remote Desktop Protocol flaws could be exploited to attack RDP clients

89

Microsoft desktop flaws

 

Microsoft’s Remote Desktop Protocol is being used by millions around the world. Various businesses, IT staffs and tech supporters are taking advantage of the convenience that RDP provides to connect to remote computers from different locations in order to access data, remote work, etc. It’s crucial to understand that while remote connections offer enormous benefits, Remote Desktop Protocol flaws and vulnerabilities has made it a prime target for hackers and cybercriminals. A report by McAfee showed that 63.5% of all ransomware attacks targeted RDP flaws in the first quarter of 2019.  

 

What Makes RDP Vulnerable?

Part of these vulnerabilities comes from the fact that Remote Desktop Protocol was originally developed to make computers on the same network able to communicate. Therefore, channels with pre-existing permissions could allow access to users without re-authorizing.

Attackers who take advantage of RDP flaws can use a variety of methods to do so. They might gain access to their victim’s computer as if they’re sitting in front of it, having total control over the private data and program management which is a catastrophic failure for an operating system. Some of these attacks are “wormable” too, which means they can travel and infect other computers on the network as well. They can be complex hacking against specific targets or brute-force attacks that look for RDP vulnerabilities by scanning the default ports for RDP, also known as 3389 exploit.

 

Some of the Major Remote Desktop Protocol Flaws

BlueKeep, designated as CVE-2019-0708, is one of the most famous and concerning RDP exploit that was first reported in May 2019 and is a major threat to unprotected RDP servers on older versions of Windows.

CVE-2019-0932 is another known security issue which allows the attacker to access Skype application on Android operating systems without the user’s knowledge.

It’s important to note that only officially recognized exploits from Microsoft receive CVE designations which refers to “common vulnerability and exposure”.  However, there are plenty of RDP potential security issues that Microsoft has never noted or released patches for. These are considered less critical in the sense that they require users to make some mistakes before they present threats. One of the exploits in this category that officially deemed noncritical, allows an unauthorized attacker to alter text on the clipboard on a vulnerable system. For example, your administrator password is a long string of letters, numbers and symbols so instead of typing it out, you just highlight and copy it. Now if you're under attack by this exploit, you've just given the attacker admin access to your computer.

data breach

alt: data breach

Primary Solutions

Some of these RDP flaws and potential security risks can be avoided by taking a few initial actions such as: setting up Network-Level Authentication (NLA), implementing a firewall, using better passwords, choosing Two-Factor Authentication, having role-based access policies, creating an account lockout policy, keeping updated to the latest released patches and using more secure third-party remote desktop applications.

Aside from common security issues and solutions, in the following we’re going to explain another RDP vulnerability which is a little different from other ones as it affects the client side of the remote connection.

 

Path Traversal Vulnerability in Shared Clipboard

A typical RDP scenario is about connecting an RDP client to an RDP server, thus depending on the user’s permissions, the client gaining access over the remote server. Therefore, users are mostly focused on the default direction of client to server and hardly anyone considers the other way around where an attack takes place from a vulnerable remote server in order to gain control of a client. That was until Eyal Itkin in a Check Point research found another Remote Desktop Protocol flaw.

Referring to his founding as reverse RDP attack because of the opposite direction of normal RDP communication and gaining control over the client’s machine, Itkin showed that this was a possible exposure for mstsc.exe (which is the Microsoft built-in RDP client) through the clipboard sharing channel. When an RDP client uses the ‘Copy & Paste’ feature over an RDP connection, an RDP server which is under attack can drop arbitrary files to arbitrary paths on the client’s machine, limited only by the permissions of the client. For example, if the attacker drops malicious scripts to the client’s ‘Startup’ folder, they will be executed after a reboot, giving the malicious actor full control.

More interestingly, 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 available clipboard formats. In other words, a malicious server gets notified whenever the client copies something to its local clipboard, which the server can then query and read the values.

Even more terrifying is that the vulnerable RDP server can also notify the client about a fake clipboard update without the need for an actual copy operation inside the RDP window, thus completely controlling the client’s clipboard without the user being noticed at all.

network rdp


Alt: network rdp

An Improperly Patched Path Traversal Flaw

While Microsoft’s first official response wasn’t so promising, later Itkin showed that in addition to RDP itself, Hyper-V also inherits the security vulnerability since it uses RDP behind the scenes as the control plane for managing the Virtual Machine, resulting in a guest-to-host sandbox escape vulnerability. After this, Microsoft finally took the issue more seriously and recognized the flaw as CVE-2019-0887 and patched it as part of its July 2019 Patch update. Although Check Point researchers originally confirmed that "the fix matches our initial expectations", fun part is that as it turns out, the July patch released by Microsoft can be simply bypassed by replacing backward slashes (e.g., file olocation) in paths with forward slashes (e.g., file/to/location), which in Unix-based systems traditionally act as path separators.

Published by Blogger at 2021 February 05