London: 020 0200 8142

Reduce Your Risks: Remote Desktop Service Vulnerabilities

Remote Desktop Service (RDS)

Remote, from late Middle English (in the sense ‘far apart’) from the Latin remotus

Greetings to the second of our Reducing Your Risks blog series. Written by PR’s team of Penetration Testers with a combined experience of 25 plus years, we look across the spectrum of IT risks and offer tips to improve your organisation’s security.

Here, we address Remote Desktop service vulnerabilities, the common threats, and how to guard against them.

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.

Here are a couple of screenshots of RDS accessed via Microsoft’s Remote Desktop protocol:

Remote Desktop service login screen

Remote Desktop service post authenticated screen

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.

References

CVE Common Vulnerabilities and Exposures: Microsoft Terminal Server using Remote Desktop Protocol

(i) Wikipedia

(ii) Wikipedia: Cain and Abel software

For advice on any element of your cyber security, feel free to get in touch.

Category: Blog

We are Perspective Risk

  • Information security is crucial to every aspect of your business – operational efficiency, profitability, business continuity, customer confidence, brand loyalty, protection against fraud and meeting regulatory requirements.

    Our penetration testing, pen testing, pen tests and cyber security testing has proven time and time again to be an effective security assessment of business IT infrastructure.

    Perspective Risk provides in-depth security assessments, risk management and compliance solutions to help you keep your confidential information safe and your critical systems secure. We’re innovative, flexible and supportive, helping you through any information security issues to deliver real business benefits and excellent value.

  • Call Me

    Pop your details in below and we’ll be in touch soon!

    • This field is for validation purposes and should be left unchanged.

    ×
    Get Quote
    • This field is for validation purposes and should be left unchanged.
    ×