Reduce Your Risks: Remote Desktop Service Vulnerabilities

Advania - Remote desk service vulnerabilities_

Posted On

27 Apr 2017

Written by

Advania UK

Duration of read

5 min

Subscribe via email

Remote Desktop Service (RDS)

Remote Desktop service (RDS), known as Terminal Services in Windows Server 2008 and earlier, is a component of Microsoft Windows. It equips a user with a high degree of usability and accessibility by enabling the remote control of a computer, client or virtual machine over a network connection (i), commonly over a graphical user interface.

Remote Desktop Service – The Risks

Security flaws and misconfigurations can render a Remote Desktop service vulnerable to the following attacks:

RDS Exposed on the Internet

RDS typically allows for remote administration of systems by support personnel. In its default state, a Windows server will only allow Administrator-level users to log in to the host via the service.

There is no necessity to expose the Remote Desktop service to the Internet, thus enabling untrusted users on the Internet to attempt connections. Worse still, malicious Internet based attackers could carry out brute force attacks against the service. By default, the first account an attacker would try is ‘Administrator’ which is not usually configured with an account lockout.

If a password is guessed successfully, the resulting access could have substantial repercussions for your organisation and facilitate further attacks against trusted or connected infrastructure.

Man-in-the Middle Attacks (MiTM)

Although the Remote Desktop service provides data encryption between the client and server by default, it doesn’t provide authentication for verifying the identity of the Terminal Server. This lack of identity verification allows a malicious person, by deploying other nefarious activities, to intercept all communications sent between a client and a Terminal Server.

The likelihood of this type of attack depends on a hacker’s ability to control connections between the client and the Terminal Server. Typically, this requires the criminal to perform other attacks such as ARP (Address Resolution Protocol) spoofing or DNS (Domain Name System) spoofing, which redirect connections to the attacker prior to sending the data to the legitimate server.

If such conditions are met, tools such as Cain and Abel (i) are freely available and trivial to use to perform MiTM attacks and compromise Remote Desktop protocol.

Similar attacks could be made to capture encrypted RDS traffic. Thankfully however the decryption of even medium level encryption is beyond the capability of most casual attackers.

Encryption Attacks

By default, the Remote Desktop service uses an encryption setting of Client Compatible (medium). This level of encryption encrypts data sent between the client and the server at the maximum key strength supported by the client. It’s generally used in an environment containing mixed or earlier-version clients.

The medium setting may facilitate the use of weak encryption which could be decrypted in a reasonable time-frame and lead to the disclosure of sensitive information.

Denial of Service (Network Level Authentication)

Terminal Servers which support Network Level Authentication (NLA) but do not have it configured present a risk. NLA forces the client computer to present user credentials for authentication before the server will create a session for that user.

As session creation is relatively resource intensive, NLA provides a layer of defence against Denial of Service attacks whereby a malicious user makes repeated connections to the service to prevent its legitimate use by others.

Remote Desktop Service – Advice for Improving Security

In brief, implement Transport Layer Security (TLS) with high levels of encryption and enforce Network Level Authentication (NLA). Read on for details.

Transport Layer Security Authentication

Remote Desktop services should be configured to use Transport Layer Security. Prerequisites for TLS are as follows:

A certificate for the Terminal Server should be obtained from an internal PKI solution or a trusted third party Certificate Authority
Clients must be using a modern OS and use the RDP 5.2 client or later
Clients must trust the root of the server’s certificate

To configure TLS authentication on the Terminal Server itself:

On the General tab of the RDP-tcp Properties dialog box, perform the following:

Select the certificate to be used for the server
Set the Security layer to Negotiate or SSL
Set the Encryption level to High, or enable Federal Information Processing Standard (FIPS) compliant encryption. This may also be done via Group Policy.

High Level Encryption

Mandate at least High level encryption. This can be configured in Group Policy as follows:

Open Group Policy
In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Encryption and Security, double-click the Set client connection encryption level setting, then click Enabled
To set the encryption level, select the High level then click OK

Network Level Authentication

Where supported, Network Level Authentication (NLA) should be configured. Prerequisites for NLA use are as follows:

The client computer must be using at least Remote Desktop Connection 6.0
The client computer must be using a modern operating system such as Windows 7
The Remote Desktop Session Host server must be running Windows Server 2008 R2 or Windows Server 2008
NLA can be configured through Group Policy by applying the following settings:
- Require user authentication for remote connections by using Network Level Authentication Group Policy setting which are located in;
- Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

On Windows 2012 and above, NLA is enabled by default, however if it has been inadvertently disabled, it can be re-enabled via the Group Policy setting:

Require user authentication for remote connections by using Network Level Authentication:

In the following:

Computer\Policies\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

RDS Exposed on the Internet

You should disable the remote services from the Internet and restrict to internal IP address ranges only. If this is not feasible, restrict the service to singular Internet based addresses.