Microsoft’s Remote Desktop Services (RDS) is a commonly used technology for providing a remote Windows graphical environment. RDS use cases range from merely enabling remote server management all the way to providing full Virtual Desktop Infrastructure (VDI) for enterprises. In this blog, we’ll explore how the network level security controls have evolved to address risks, the reasons why defaults can impact an environment’s security, and using runZero to audit your environment.

In the beginning (abridged)

In 1995, before RDS, Citrix released a multi-user remote desktop product called WinFrame, based on Windows NT 3.51. This was promising enough that Microsoft later licensed the core technology from Citrix and used it to build a product called Terminal Services. It was first released in 1998 as Windows NT 4.0 Terminal Server Edition. In Windows 2000, Terminal Services became a standard Windows feature. After that, nearly every version of Windows Server improved on RDS in some way.

The network protocol used for communication between the RDS client and server is called Remote Desktop Protocol (RDP). The protocol evolved alongside the RDS changes and was the impetus for various improvements. Many of the security controls discussed in this blog are changes to RDP.

Not remotely secure

It will likely surprise no one that a protocol and corresponding implementations from the 1990s and early 2000s had security problems. The impact of these problems grew over time as more organizations started exposing the RDS services directly on the Internet. Some organizations were doing this to enable remote management of servers while others were hosting applications and other services for clients.

The major issues that we’re going to cover here are:

Information disclosure

When a client connected to RDS they would be presented a login screen. By default, the login screen often displayed a list of recent users and Windows Domain or Active Directory that the server was part of. This information could then be used in brute force attacks.

FIGURE 1 – Legacy RDS pre-login screen

Brute force attacks

The client side of the RDP protocol required minimal resources and there were no controls in place to stop attackers from using tools such as Hydra or Ncrack to test various username and password combinations in order to discover valid credentials. While Administrators could configure Windows policies to lock out accounts after a certain number of failed login attempts this precaution often wasn’t enforced for Administrator accounts – admins always had login access.

Denial of service

During the initial client connection and prior to authentication, the server provisioned an entire desktop environment before beginning the login process. This meant that attackers could easily create a resource-exhaustion situation by simply opening a large number of sessions. This could happen accidentally as part of an effort to brute force credentials.

Machine-in-the-Middle

The early versions of RDP were susceptible to Machine-in-the-Middle (MitM) attacks that could enable decryption or modification of RDS session data. They used a form of authentication that is now known to have many weaknesses. The encryption used was a stream cipher named RC4. At the time RC4 was commonly used in various protocols such as WEP, WPA, SSL, and TLS. Today, however, it is known to be broken by multiple techniques and the key sizes are such that modern computers make short work of them. It became so risky that RFC 7465 was drafted in 2015 to prohibit RC4’s use in all TLS versions. Further compounding the RDS risks, RDP allowed keys sizes as small as 40 bits in order to comply with US cryptographic export restrictions.

The issues with authentication didn’t end there. Microsoft’s implementation of the key exchange protocol depended on the client and server creating and exchanging random values. The server’s random value was sent unencrypted over the network. The server also provided a public RSA key that could be used by the client to encrypt the client’s random value so that only the server could read it. Unfortunately, Microsoft baked the same public-private RSA key pair into every RDS host. This key was, predictably, extracted and made public. With that information attackers with network access to RDS communications could decrypt the data and extract authentication and session information. Advanced attackers in the correct network position could intercept and monitor or modify an RDS session in real time.

Shoring up defenses

With the release of Windows 2003 Service Pack 1, Microsoft introduced the ability to use TLS, which addressed the issue of machine-in-the-middle (MitM) attacks by enabling the use of significantly more robust encryption cipher suites and key exchange protocols. This also enabled the protocol to take advantage of improvements in TLS over time instead of being locked into a single algorithm. Additionally, TLS allows clients to cryptographically verify they were connecting to the expected server.

In Windows Server 2008, Microsoft introduced Network Level Authentication (NLA), which required users to authenticate themselves before a session would be established. NLA forced authentication to occur after the TLS handshake, but before the console was provisioned, which mitigated the resource-exhaustion concerns, reduced information leakage, and significantly impaired brute-force attacks. Since information leakage was reduced attackers could no longer collect the names of users, but they could still access the Windows hostname and domain information via the CredSSP authentication process. However, this is still an overall improvement in security. There is one downside to requiring NLA – users can no longer authenticate and change expired passwords. This functionality has to be provided via another mechanism such as a Remote Desktop Gateway.

When configuring RDS in Windows Server 2008, administrators had the option to require NLA for all connections or to allow the client to decide. Starting with Windows Server 2012, however, NLA was required by default to improve security across Windows environments.

Real world impact of NLA by default

We explored our data to determine if requiring NLA by default had a real world impact. In other words, do we see a significant percentage of assets where a less secure option has been enabled for Window Server 2012 and beyond?

The chart below shows the overall percentage of specific Windows operating systems (OS) in our data as well as the breakdown of NLA is enforcement.

FIGURE 2 – Operating system distribution for RDP NLA enforcement.

As the results illustrate, the majority of RDS on Windows Server versions where NLA is required by default do, in fact, require NLA. This is great news. It indicates that secure defaults can have a positive impact on security posture. Another takeaway is that more modern environments are less likely to operational or compatibility requirements that force less secure configurations. An argument could be made that the NLA requirement being disabled by default on Windows Server 2008 / 2008 R2 shows up in the results as well, but this state may be influenced by those servers being more likely to have legacy or third-party clients that don’t support NLA.

We also reviewed the OS distribution of services that did not permit using NLA at all. This list is dominated by Red Hat Enterprise Linux and its various derivatives running the xrdp RDP service. The xrdp service does not currently support NLA, so these results are not surprising. However, we were encouraged to find so few results for Microsoft Windows machines without NLA support that the number is not statistically significant.

FIGURE 3 – Operating system distribution for RDP without NLA support.

Using runZero to audit RDP configurations

At runZero we put a tremendous amount of effort into trying to extract as much information from scan targets as possible, particularly if the information can help us understand the security posture of the device. From RDS services this includes enumerating all of the RDP authentication mechanisms that target supports. Explore our recommendations to audit RDP configurations in your environment.

Attributes of interest

We store RDP authentication attributes on the RDP service of an asset with the prefix rdp.auth. Here are the attributes that can be used to audit your environment to check to see if NLA is enabled or required as well as if standard, legacy RDP authentication is still enabled:

• rdp.auth.nla – a value of supported indicates that the target supports NLA (this is good!).

• rdp.auth.rdp – a value of supported indicates that the target still allows authentication using the legacy RDP mechanism. (Red flag. It should only really be required if you have very old clients that still need to connect).

• rdp.auth.ssl – a value of supported indicates that the target still allows authentication using the TLS. (Somewhere in the middle. This is better than legacy RDP but still weaker than NLA).

In rdp.auth.rdp and rdp.auth.ssl a value of ERROR_HYBRID_REQUIRED_BY_SERVER indicates that the authentication mechanism is not supported and NLA is required. This is the desired state.

Within runZero you can use a Service inventory search to audit your environment. To find assets supporting legacy RDP authentication you can use the following search criteria:

protocol:rdp and _service.rdp.auth.rdp:="supported"

To find assets supporting either legacy RDP or SSL the following Service inventory search criteria can be used:

protocol:rdp and (_service.rdp.auth.rdp:="supported" OR _service.rdp.auth.ssl:="supported")

A glance into the near future

An interesting recent development is the introduction of Remote Desktop (using the RDP protocol) to both the Gnome and KDE desktop environments. In both cases Remote Desktop is a full fledged, native feature. Based on the currently released code, it appears that the implementations support NLA and do not support either the legacy RDP or SSL protocols. We will be monitoring the growth of these implementations over time and look forward to sharing more insight on that in the future.

Final Thoughts

Thankfully, the security of Microsoft’s RDS has improved over time. As with many such improvements, the benefits are lost if the new features are not implemented. In this case, Microsoft made the pragmatic decision for the most secure option to also be the default and we can measure the real world impact. In short, secure-by-default matters.

Latest SonicWall vulnerability: (CVE-2024-40766) 

SonicWall disclosed a vulnerability that affects SonicOS management access and SSLVPN software on SonicWall Gen 5, Gen 6, in addition to Gen 7 devices running SonicOS version 7.0.1-5035 or earlier.

CVE-2024-40766 is rated critical with CVSS score of 9.3, and potentially allows for unauthorized resource access by an attacker. There is limited evidence that this vulnerability is being exploited in the wild.

What is the impact?

Successful exploitation of this vulnerability potentially results in unauthorized resource access and in some cases could lead to a DoS after causing vulnerable devices to crash.

Are updates or workarounds available?

SonicWall recommends restricting management access to trusted sources or disabling WAN management from the public Internet. Additionally, SonicWall has released updated firmware and is available for download from mysonicwall.com.

How to find potentially vulnerable systems with runZero

From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:

hw:"SonicWall" type:"Firewall"