Remote Desktop Protocol Security
June 24, 2013
As a PCI Professional and Network Security Consultant, I frequently run into insecure Remote Desktop Protocol (RDP) implementations while working with clients. Actually, if I am performing an assessment, I’m required to verify that there are no improperly implemented RDP solutions on the network by many of the requirements in section 2 and 8 of the PCIDSS. If configuration issues are observed or discovered during technical review, I’ll take this information to the client to discuss.
Typically, I find that clients have no idea their RDP implementation is insecure, and we often have to spend quite a bit of time discussing solutions before they are comfortable with developing, documenting and eventually rolling out their solution.
Microsoft RDP requires significant configuration changes to enforce strong encryption requirements and reduce the attack surface. Numerous other parameters, beyond the scope of this blog, must be considered when setting up a secure RDP environment. Some of the most important things to consider are which user accounts have permissions to log in via RDP, password policy and use of two-factor authentication schemes if the RDP environment is available remotely.
Today, we’ll focus on strongly encrypting RDP communications and avoiding configurations that make account passwords brute-force easy.
Specific technical information related to Windows Server 2012 is not included within this article; however, many of the concepts discussed within this article are applicable.
By default, RDP contains the following significant risks that should be addressed before placing an RDP server into production:
- Private key disclosure
- Use of weak encryption for RDP communications
- Use of weak encryption for RPC over RDP communications
- Acceptance of stored login credentials on clients
- Enabling Network Layer Authentication
Let’s drill into each of these further.
1. The Notorious RDP “Private Key Disclosure” Vulnerability
This Man in the Middle (MITM) vulnerability exists because of Microsoft’s decision to embed a private key into a publicly distributed Dynamic Linking Library, mstlsapi.dll - a subroutine of the “TLSInit” API dynamically creates, uses and de-allocates this key.
Windows XP clients are vulnerable to this, and the mainstream solution is to tunnel RDP over strongly encrypted protocols such as VPN, SSH or SSL. Windows Vista and Windows 7 RDP listeners can be configured to use an SSL certificate through local or group policy. Windows Server 2000, 2003, 2008 and 2012 can also be configured to use an SSL certificate through local or group policy.
Note: For XP, technically a hex editor could be used to modify mstlsapi.dll and replace the default key pair with one that is unique to the system. However, this hex hacking is difficult to implement and maintain with the added bonus of not being supported. Time to retire those old XP machines - this one is too likely to cause problems!
All versions of Windows supporting Certificates: Determine if the server will be using a certificate issued by a publicly trusted CA or an internally trusted CA. Self-signed is NEVER good enough because no user can be expected to know the difference between YOUR self-signed certificate and MINE. Go through your normal certificate request and issuance process - this is generally found within the IIS administration tool.
Windows 2003: Open “TSAdmin,” right-click on the “RDP TCP” and choose properties. Select the SSL certificate, and require SSL for all sessions. See the 2008 screenshot below.
Windows 2008: Open the “Remote Desktop Session Host Configuration” tool. Right-click on “RDP TCP,” then choose properties. Select the SSL certificate (see bottom red circle in the following screenshot). After selecting the SSL certificate, set the “Security Layer” to “SSL (TLS 1.0).”
In large scale enterprise environments, with an internal CA that’s integrated with Active Directory, the following group policy parameter highlighted in blue takes most of the work out of securing RDP communications with certificates:
2. Weak Encryption for RDP Communications
The default tendency for RDP servers is to allow the use of weak encryption. Not only is the encrypted session vulnerable to a MITM attack, the encryption strength is also quite weak. All versions of Windows desktop platforms (XP, Vista, 7) and Windows Server platforms (2000, 2003, 2008) can be easily configured to require “high” encryption or “FIPS” encryption to resolve this problem. However, full resolution is entirely dependent upon the platform’s ability to use an SSL certificate for RDP.
Windows 2003: To configure 2003, use the “TSAdmin” tool and right-click on the “RDP TCP” and choose properties. Set the encryption level to “High.” (See the middle red circle in the screen-shot following the Windows 2008 info.)
Windows 2008: See the middle red circle in the screen shot from the “Remote Desktop Session Host Configuration” tool.
3. Weak or No Encryption for Remote Procedure Calls
The default tendency for RDP protocol enabled systems is to use weak or NO encryption for Remote Procedure Calls. All versions of Windows desktop platforms (XP, Vista, 7) and Windows Server platforms (2000, 2003, 2008) can be easily configured to require strong encryption for RPC communications which resolves this problem.
Note: This functionality is called “Terminal Services” under older versions of Windows and “Remote Desktop Services” under newer versions of Windows. It’s found in the system policy in Windows Components.
4. Acceptance of Stored Login Credentials
The default tendency for RDP servers is to accept client login credentials presented through the client handshake instead of forcing logins to go through the login graphical user interface on the server. This “functionality” allows clients to store weakly protected usernames and passwords - a practice that is positively terrible for security - and enables tools like “TSGrinder” to attack the RDP server and brute force user ID’s and passwords.
If stored credentials don’t cause a breach, brute-force exposure most likely will. This particular configuration is the root cause of most successful attacks against RDP that lead to security breaches. This is extremely easy to fix through Group Policy or individual server configuration. The following screenshot was taken from Server 2008:
This configuration by itself does little good if clients are allowed to continue to save credentials; if the environment is full of old “.RDP;” or if lots of login information is saved within the registry on clients.
Efforts must be made to disable this feature on the clients and clean up the stored login credentials. Otherwise, any attacker smart enough to try the credentials they manually recover WILL get in.
Group Policy is the best way to prevent saved passwords on clients. See the two parameters shown in the screenshot below:
5. Enabling Network Layer Authentication
Numerous recent versions of Microsoft Windows, including Windows Vista, Windows 7, Server 2008 and Server 2008 R2, support a feature called Network Layer Authentication (NLA). This feature can be configured to require authentication of the remote TCP/IP client at a network layer before communications with the actual RDP service is permitted.
Certain minimum requirements must be met by client machines in order to work with NLA, including the following:
MSTSC.EXE (Remote Desktop Connection) clients must be upgraded to 6.0 or higher.
The client must use an operating system that supports Credential Security Support Provider (CredSSP) protocol. (Windows 7, Windows Vista, Windows Server 2008, Windows Server 2008 R2 or Windows XP SP3 computers enhanced with the CredSSP implementation guidance provided by Microsoft in this support article).
RDP Server must be running Windows Server 2008 or 2012.Other versions of RDP implementations on Windows do not support RDP Services protected by NLA.
To configure NLA for RDP Services:
- Open Remote Desktop Session Host Configuration.
- Under Connections, right-click on the RDP Connection, and select Properties.
- On the General tab, check the “Allow connections only from computers running Remote Desktop with Network Level Authentication” box.
Note: These features are also controllable via group policy. If policy is enforcing the parameter, the box will be checked and not selectable.
NLA was not sniffed and reviewed for this article, and the extent to which it has been tested by others is unknown by me.
RDP Server support is often negatively impacted by NLA due to the difficulty with meeting the CredSSP protocol requirements on 100% of the clients.
With proper patching and perimeter defense measures, NLA may be an extra measure. Long-term it could positively or negatively impact the overall risk of the RDP implementation. The extent to which it does impact is not known. Do your homework.
Portions of this article were created based upon the work of Erik Forsberg, who is credited with the discovery of the RDP Private Key Disclosure vulnerability originally published in 2003.
Portions of this article focus on implementing an X.509 server-side certificate and requiring its use by RDP servers. These measures were originally published by Microsoft with the express intent of defeating published attacks such as those included in the Oxid.it tool “Cain and Abel.” All published information explicitly specifies the necessity to use recent RDP clients that are able to validate the encryption genealogy of the X.509 certificate used. Clients that fail to verify the certificate chain shall remain vulnerable to MITM attacks.
Portions of this article focus on configuration settings intended to defeat the current capability of RDP brute-force tools like Darknet.org’s TSGrinder – Brute-Force Terminal Server. Testing of the suggested countermeasure was conducted in my personal lab and further verified by exposing an RDP server with strong passwords to the internet for a period of 9 years. However, such testing is by no means conclusive or exhaustive. Use of two-factor authentication for RDP communications is a far superior method and is strongly encouraged (and required in many cases where PCI DSS is applicable).
The remaining information in this article was developed in my personal lab using sniffers and other tools to verify the effectiveness of the solutions. However, these opinions are solely my own. The final security of the environment is dependent upon numerous environment and tool specific factors. Your individual mileage may vary.