Reduce Your Risks: Remote Desktop Service Vulnerabilities
Remote Desktop Service (RDS)
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 – 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.
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.
CVE Common Vulnerabilities and Exposures: Microsoft Terminal Server using Remote Desktop Protocol
(ii) Wikipedia: Cain and Abel software
For advice on any element of your cyber security, feel free to get in touch.