Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks

Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks

  • Comments 22

General Intro

“Man In The Middle (MITM) attack” is a term used to describe a class of security vulnerabilities in which an attacker intercepts communication between two parties and impersonates each one to the other. The attacker can view and/or modify the traffic without the two parties knowledge. As a result, a user might be tricked into entering his credentials on a spoofed server. Even though RDP traffic between the client and server is encrypted, the attacker can potentially bypass RDP encryption if he is able to get the keys used to establish the session. Thus, server authentication is necessary to prevent MITM attacks.

Significant improvements in authentication and security have been made in Terminal Services that can protect against such attacks. Terminal servers running Windows 2003 Server SP1 and later support the ability for a TS client to authenticate a TS server, which protects against MITM attacks. In Windows 2003 Server SP1 and later, you can configure the TS server with a SSL/TLS server certificate that will allow the client to verify the server’s identity. In Windows Server 2008, Network Level Authentication (NLA) is designed to be secure against MITM, and it supports the ability to authenticate the server with either a SSL/TLS server certificate or Kerberos.

Terminal servers running Windows 2003 Server without SP1 or earlier do not support a clients’ ability to authenticate the terminal server. With these earlier versions, you must ensure that your network is tamper-proof by using network level protection mechanisms (for example, IPSec) in order to protect against MITM attacks.

Server authentication mechanisms that can protect against MITM attacks

1. Network Level Authentication (NLA): NLA uses the Credential Security Support Provider (CredSSP) Protocol to perform strong server authentication either through TLS/SSL or Kerberos mechanisms, which protect against MITM attacks. In addition to improving authentication, NLA also helps protect the remote computer from malicious users and software by completing user authentication before a full RDP connection is established; an additional benefit is that fewer resources are used on the remote computer prior to authentication. Please see this MSDN article or the protocol specification for more details on the CredSSP protocol.

NLA with Kerberos

This is one of the most secure server authentication schemes for protecting against MITM. Both client and server should be a part of the same or a trusted domain.

NLA with TLS/SSL

There are scenarios in which Kerberos cannot be used for server authentication, which include:

o Terminal server farms, because farms do not have a Kerberos identity in Active Directory

o Internet connection scenarios (for example through TS Gateway), in which the client does not have access to Key Distribution Center (KDC)

o The terminal server is not domain-joined

In such scenarios where Kerberos cannot be used for server authentication, deploying SSL/TLS certificates that are issued by a trusted Certificate Authority will enable the client to identify the server’s identity and protect against MITM attacks. You will need to deploy these certificates to each TS server on which you want to have server authentication and ensure that they have the server name in the Subject field.  To set the SSL certificate for a connection on Windows Server 2008:

1. At a command prompt, run tsconfig.msc. (Note: tsconfig.msc is only available on Server SKUs.)

2.  Double-click the RDP-TCP connection object.

3.  On the General tab, click Select.

4.  Select the certificate you want to assign to the connection, and then click OK.

5. Please see this TechNet article on configuring trusted rdp publishers on the client side via Group Policy.

NLA with NTLM

If SSL/TLS certificates are not configured on the server and Kerberos authentication is not possible due to the reasons stated above, CredSSP will use the NTLM authentication mechanism to establish trust between the client and server. NTLM can verify a target server’s domain membership; however, if you would like to ensure strong server authentication, you must disable allowing credential delegation with NTLM-only server authentication. To disable these policies on Windows Server 2008, follow these steps:

a. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.

b. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

c. Ensure the following policies for NTLM-only server authentication are disabled:

i. “Allow Default Credentials with NTLM-only Server Authentication”

ii. “Allow Fresh Credentials with NTLM-only Server Authentication”

iii. “Allow Saved Credentials with NTLM-only Server Authentication”

2. Pure SSL/TLS is a standard mechanism that enables clients to authenticate to servers and provides a secure channel by encrypting communications. To use SSL/TLS, you must obtain certificates issued by a trusted Certificate Authority and configure them on each terminal server on which you want to have server authentication.

a. See steps above for setting SSL certificates on Windows Server 2008.

b. See this Knowledge Base article for information on how to configure Windows Server 2003 SP1 to use TLS for server authentication.

3. Network Level Protection mechanisms can be used to mitigate MITM attacks when the server OS version does not support NLA or pure SSL/TLS server authentication mechanisms. For example, you can configure IPSec policies on these earlier versions of TS in order to get mutual authentication and protect RDP traffic against MITM attacks.

a. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

b. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

4. A virtual private network (VPN) tunnel can be set up to secure your connection and prevent MITM attacks when users are connecting to servers on your network via the Internet. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Mitigation mechanisms supported on different Server OS versions

The table below provides a summary of mitigation mechanisms available for various server OS versions and corresponding clients.

Server OS Version

Client OS
Windows Server 2000, 2003 Windows Server 2003 SP1 / R2 Windows Server 2008
Windows XP SP2 and earlier
Network Level Protection or VPN Pure SSL/TLS Pure SSL/TLS
Windows XP SP3*, Windows Vista, Windows Vista SP1
Network Level Protection or VPN Pure SSL/TLS

NLA or

Pure SSL/TLS

*Windows XP Service Pack 3 now supports NLA; therefore if you have Windows Server 2008 in your environment, it is strongly recommended that you upgrade to Windows XP SP3 or later in order to take advantage of Network Level Authentication. See this Knowledge Base article for more details on upgrading to TS Client 6.1 with Windows XP SP3.

· Note that CredSSP is not enabled on Windows XP SP3 by default; therefore you will also need to perform the steps outlined in this KB article to turn on CredSSP.

· Also note that even though RDP Client 6.1 is available on Windows XP SP2 now, NLA is still not supported on Windows XP SP2.

Windows Server 2003 SP1 and higher

Strong server authentication, which prevents MITM attacks can be achieved on Windows Server 2003 SP1 and higher, using the two server authentication mechanisms described above. Pure SSL/TLS can be used for Windows Server 2003 SP1 and Windows Server 2008. In addition, Windows Server 2008 uses NLA for clients that support it.

Earlier Server OS versions prior to Windows Server 2003 SP1

As shown in the table above, TLS/SSL certificates can only be deployed on Windows Server 2003 SP1 and later, while NLA is available only on Windows Server 2008. Windows Server 2003 without SP1 and earlier does not support NLA or pure SSL/TLS server authentication mechanisms. Therefore, on earlier Server versions, you will need to use network level protection mechanisms (such as IPSec) to get mutual authentication and protect RDP traffic against MITM attacks. Alternatively, you can set up a VPN tunnel for your connection.

1. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

2. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

3. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Client SKU used as a TS server

If you are connecting remotely to client operating systems, then only Windows Vista and Windows Vista SP1 that support Network Level Authentication will be able to provide strong server authentication with Kerberos as Windows Server 2008 described above. NLA with SSL/TLS is not possible on Client SKUs. On a downlevel client OS, you can configure VPN to secure your communications. See this KB article on configuring VPN on Windows XP.

Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post
  • Frank,

    What you are describing is actually acheived with one NTLM handshake. NTLM session key is derived from the user password, so without the knowlege of user password server would not be able to create a session key (I'm talking about a non-domain case). CredSSP requires server to prove its knowlege of the NTLM session key before sending it user credentials.

    In addition, you can form a trust between client and server based on the server's certificate. You do not need to switch to TLS for that, because CredSSP internally does 2 handshakes: first TLS and then SPNego (which in your case results in NTLM).

    Thx,

    Sergey.

  • Ah, that clears it up.  I was focused just on the NTLM traffic on the wire, and forgot about the actual session key computation.  Thanks!

  • Can I connect to a Win2008 using NLA from a Win2003SP2 server using Remote Desktop?  When I try to connect it says "The remote computer requires Network Level Authentication, which your computer does not support.  My Remote Desktop Connection version is "Shell Version 6.0 (Build Number 6000) Control Version 6.0.6000. "Network Level Authentication not supported"... when I do an about.  I can do this from my XP box, but not from Server2003sp2.

  • Unfortunately, Win2k3 does not have CredSSP backported to it so you would not be able to get NLA. You can get it with XP SP3 (after enabling CredSSP) or any OS after Vista/WS08.

  • Any thoughts as to supporting TLS1.2 on Windows7 or 2008 R2 machines? The client refuses to connect with higher versions of the protocol than TLS1.0 even when they are enabled by the Schannel registry keys. It would be nice to be able to use the Suit B TLS_ECDHE_ECDSA_AES_GCM AEAD cipher suites.

  • Stuart,

    Unfortunately, it's not possible. The client and server are hardcoded to use TLS 1.0.

    Thx,

    Sergey.

  • Requiring NLA on 2008 R2 server stops Windows XP SP3 Remote Desktops from connecting/using a RDP session even if XP SP3 system has had CredSSP enabled for Remote Desktop Connection purposes.

Page 2 of 2 (22 items) 12