Microsoft's Remote Desktop Protocol has been saddled with security bugs and weaknesses, which means you need to take certain precautions when using RDP for remote connections.
With the coronavirus spreading across the world, more people are working from home as a way to practice social distancing. But remote workers still need to do their jobs to the best of their abilities. Sometimes that means connecting to a workstation or server within the company to perform key tasks. And for that, many organizations with Windows computers rely on Microsoft's Remote Desktop Protocol (RDP). Using such built-in tools as Remote Desktop Connection, people can access and work with remote machines.
RDP has been hit by various security holes and obstacles over the years. Most notably, 2019 gave rise to a vulnerability known as BlueKeep that could allow cybercriminals to remotely take over a connected PC that's not properly patched. Further, hackers continually use brute force attacks to try to obtain the user credentials of accounts that have remote desktop access. If successful, they can then gain access to the remote workstations or servers set up for that account. For these reasons and more, organizations need to adopt certain security measures to protect themselves when using Microsoft's RDP.
SEE: How to work from home: IT pro's guidebook to telecommuting and remote work (TechRepublic Premium)
In the following Q&A, Jerry Gamblin, principal security engineer at Kenna Security, and A.N. Ananth, chief strategy officer at managed security service provider Netsurion, offer their thoughts and advice for organizations that use RDP.
What security vulnerabilities and flaws should organizations be aware of with RDP?
Gamblin: Like all vulnerabilities, it is important to take a risk-based approach and prioritize patching RDP vulnerabilities that have known weaponized public exploits like CVE-2019-0708 (BlueKeep). Patching vulnerabilities without weaponized public exploits like CVE-2020-0660 are safe to keep in your normal patching cadence.
Ananth: RDP as implemented in versions of Windows, including Server 2008/12 R2, 7, 8.1, 10, are known vulnerable to exploits described as CVE-2020-0609, CVE-2020-0610, CVE-2019-1181, CVE-2019-1182, CVE-2019-1222, and CVE-2019-1226. As of mid-2019, about 800 million users were considered vulnerable. Exploits for these vulnerabilities have been on sale on web criminal marketplaces since 2018.
Older servers, which are vulnerable, are often patched at a slower cycle, and this extends the life of such vulnerabilities. Web crawlers like shodan.io make it easy for attackers to quickly identify vulnerable public-facing machines. Worldwide, more than two million systems are exposed to the internet via RDP, of which more than 500,000 are in the US.
How do hackers and cybercriminals try to take advantage of RDP accounts and connections?
Gamblin: Finding and exploiting an RDP vulnerability will be the first step in an attack chain that would likely be used to attack internal data stores and directory services to pivot to either a financial motive, or the ability to disrupt operations.
Ananth: One common tactic is RDP brute-forcing, where attackers automate many login attempts using common credentials, hoping one hits. The second involves exploiting a software vulnerability to gain control of an RDP server. For instance, attackers could exploit BlueKeep (CVE-2019-0708) to gain complete control of a managed service provider's (MSP) unpatched RDP servers.
A new module in Trickbot specifically tries to brute-force RDP accounts. The Sodinokibi and GandCrab malware attacks incorporate RDP modules. Ryuk ransomware, which has been especially active in 1Q 2020, uses RDP to spread laterally after the initial foothold is gained. The RobinHood attack against the City of Baltimore in May 2019 and the SamSam attack against the city of Atlanta in August 2018 are examples of RDP originated attacks.
What security options should organizations put in place to better protect themselves against threats to RDP accounts and connections?
Gamblin: Without many exceptions, all RDP instances should require multiple levels of access and authentication controls. This would include the use of a VPN to access an RDP instance and requiring a second factor (like Duo) for authentication. Some major organizations place RDP directly on the internet, but most (hopefully) are doing this unknowingly. Checking on this is pretty simple; just fire up your favorite internet-wide scanner and look at all the RDP instances directly exposed.
Ananth: There are some built-in, no-cost defenses that can secure RDP. These include:
- Patching: Keep servers especially up to date.
- Complex passwords: Also use two-factor authentication, and implement lockout policies.
- Default port: Change the default port used by RDP from 3389 to something else via the Registry.
- Windows firewall: Use the built-in Windows firewall to restrict RDP sessions by IP address.
- Network Level Authentication (NLA): Enable NLA, which is non-default on older versions.
- Limit RDP access: Limit RDP access to a specific user group. Don't allow any domain admin to access RDP.
- Tunnel RDP access: Tunnel access via IPSec or Secure Shell (SSH).
However, even if you took all these prevention and hardening steps, one cannot guarantee safety. Monitor RDP utilization. Look for first-time-seen and anomalous behavior. A succession of failed attempts followed by a successful attempt indicates successful brute force password guessing. A Security Information and Event Management (SIEM) solution with effective correlation capabilities can quickly pinpoint such attempts.
- Dark Web: A cheat sheet for professionals (TechRepublic)
- 2020 Tech conferences and events to add to your calendar (free PDF) (TechRepublic download)
- Policy pack: Workplace ethics (TechRepublic Premium)
- Remote working 101: Professional's guide to the tools of the trade (ZDNet)
- 5 best standing desk converters for 2020 (CNET)
- The 10 most important iPhone apps of all time (Download.com)
- Tech history: Check out our coverage (TechRepublic on Flipboard)