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"

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"

One of the key components of runZero’s ability to provide asset discovery, exposure management, and attack surface management data is its ability to identify an asset’s operating system (OS), hardware, and services aka fingerprinting. This is often performed with very little or even conflicting data.  

In this blog, we explore commonly used fingerprinting techniques and gain insights from the runZero Research Team on their approach to deciphering a real-world fingerprinting challenge. Let’s go!

Fingerprinting concepts

For the purposes of this blog, “fingerprinting” is defined as the process of trying to identify, with as much precision as possible, some aspect of an asset. There can be significant variation in the precision that can be achieved when fingerprinting. With certain data we may be able to identify the operating system and exact build number. With different data, it may only be possible to vaguely bucket the asset into an OS family such as “Windows” or “Linux.” For services we can sometimes even determine the programming language it was written in and perhaps a range of language versions that may have been used. All outcomes can be possible against the same asset depending on which protocols and services we can observe.

Fingerprinting techniques generally fall into one of three categories:

An example of self identification based fingerprinting would be an SSH MOTD banner of “Red Hat Enterprise Linux Server release 5.11 (Tikanga)”. That is pretty straightforward and doesn’t require any additional data. Attribute based fingerprinting, which we will discuss further in the next sections, includes looking at various response and data attributes such as TCP field values such as MSS or Window Scale. Behavior based techniques typically take more work to find and implement. An example would be when a particular OS or service implementation drops a TCP connection only when sent a certain payload at a particular stage in protocol negotiation.

A hat by any other name #

Identifying the OS of a network-connected system, without credentials, and with minimal services, has always been a game of precision. Some of the trickiest examples are the forks of the Red Hat Enterprise Linux (RHEL) distribution.

CentOS and certain other Linux distributions such as Oracle Linux were originally forks or “bug and binary compatible” redistributions of Red Hat Enterprise Linux. The relationship changed in 2021 when Red Hat, which acquired CentOS in 2014, discontinued CentOS Linux and created CentOS Stream. With this change CentOS would no longer be downstream of RHEL but would instead be the upstream source from which RHEL is created. The logical flow has since changed again and now has Fedora as the root with both CentOS Stream and RHEL downstream. In response to CentOS Linux being discontinued two new distributions were created: AlmaLinux OS and Rocky Linux.

Often, the only real difference between these distributions is the replacement of Red Hat trademarks and branding with that of the particular Linux project. In many cases, these distributions are byte-for-byte identical at the software package and network levels. These present a challenge to remote fingerprinting as a result.

To overcome these challenges, we collect and analyze enormous amounts of data. Our first pass at trying to differentiate the RHEL derivatives used a combination of two attributes, such as SSH version negotiation strings and the TCP Receive Window size. Over time, we realized this wasn’t going to be sufficient and that we needed more and better data.

Analyzing data at scale is useful, but in situations like this it is vital to know exactly what combination of distribution and version leads to what results. For this effort we built hundreds of virtual machines running as many versions of the different distributions as we could. In some cases, these releases were over two decades old!

Verify target, one SYN only #

From each of these virtual machines we collected as much information as we could about how the TCP stack communicated. While it is true that fingerprinting an operating system via TCP stack quirks has been a thing for years, our challenge was to improve our detection while sending the absolute minimum amount of traffic and, importantly, to look for evidence that would persist through common configuration changes by the system administrators.

To explain our findings, we first need to define some terms:

• TCP Receive Window: Maximum amount of data that a particular endpoint can receive and buffer. The sending host has to stop after sending the maximum amount of data and wait for ACK and window updates.

• MTU: Maximum Transmission Unit, which is the largest packet that the network interface can accept.

• MSS: Maximum Segment Size, which is the maximum amount of TCP data that can fit into a single packet, calculated as the MTU minus the protocol headers.

• TCP Window Scale: An optional factor by which the TCP Receive Window is scaled; this allows receive windows to exceed the maximum of 65535 bytes that can be specified in the TCP Receive Window field.

Of the TCP attributes that we observed, the one that provided the murkiest fingerprinting results was the TCP Window Scale. The values for it, when present, range from 0 to 14. With this information, we can usually determine if the target is running a general family of operating systems.

FIGURE 1 – TCP Window Scale by operating system.

Combining the TCP Receive Window and MSS offered the next significant improvement. In our past work, leveraging the Receive Window size sometimes yielded values that seemed to change unexpectedly. The reason why became clear when we looked at the data from the lab.

The key points were:

• Changes to the link-layer MTU impacts the value of MSS, since MSS is calculated as the MTU minus the size of certain TCP/IP headers.

• MSS is different between IPv6 and IPv4 due to the IPv6 IP headers being 20 bytes larger.

• For Linux-based systems, Receive Windows less than the maximum value were almost always an even multiple of MSS. Due to the MSS difference mentioned above this means that the Receive Windows would vary as well.

• Critically, the MSS multiplier for Linux-based OSs correlated with the Linux kernel version.

With the information above in hand, we can organize Linux systems into specific kernel version buckets based on the observed multiplier. That is quite a bit of information from the response to a single SYN packet!

FIGURE 2 – Relationship between IPv4/IPv6 MSS Multiplier and Linux Kernel version.

The kernel version also offers a hint as to the relative age of the system. A MSS multiplier of 4 indicates that the machine is likely running an ancient version of Linux, far beyond EOL, and certainly not something that should still be in production.

A little from column A, a little from column B #

TCP-based fingerprinting by itself doesn’t improve fingerprinting of RHEL derivatives as much as we’d like. Since most of the systems in our analysis had SSH running, we looked for patterns in RHEL-derivative type and version in the light of SSH version negotiation advertisements (for example, SSH-2.0-OpenSSH_8.7) combined with the Linux kernel version. This strategy quickly yielded results. We found that we could generally identify the distribution’s major version, and in some cases, minor version range as well.

The screenshots below demonstrate how specific patterns pop out under bulk analysis.

FIGURE 3 – Relationship between different Enterprise Linux distribution versions and various network attributes.

As we can see in this screenshot, by combining SSH version advertisement and various measured TCP attributes, it is possible to narrow the Linux distribution involved, sometimes down to individual point releases. Even when it is not possible to precisely determine the version, it is almost always possible to determine if the distribution in question is derived from RHEL.

FIGURE 4 – runZero detecting operating systems derived from Red Hat Enterprise Linux.

While determining which RHEL-based distribution an asset is running from just SSH remains unsolved, the work involved resulted in greatly improving the ability to assert the OS family, major version, and sometimes minor versions of the OS. This provides customers insight into the state of their asset fleet as well as the age, support, and end of life status of these assets. The same techniques also allow us to fingerprint other operating systems, such as OpenBSD, down to the specific release version.

Final thought #

Precise fingerprinting is the foundation for delivering actionable asset discovery, exposure management, and attack surface management data to any type of organization. The runZero Research Team’s process behind precise fingerprinting enables security and IT teams to better understand where and when to take action against potential threats in their environments.

Want to learn more about runZero’s unique research on the state of asset security? Check out the runZero Research Report for a deeper look into the drivers behind CAASM.