New LDAP & RDP Relay Vulnerabilities in NTLM

Over the past few months, the Preempt research team discovered and reported two Microsoft NT LAN Manager (NTLM) vulnerabilities. These vulnerabilities have a common theme around two different protocols handling NTLM improperly. These issues are particularly significant as they can potentially allow an attacker to create new domain administrator accounts even when best-practice controls such as LDAP server signing and RDP restricted admin mode are enabled.

A video demonstration of the two vulnerabilities can be seen here.

How Preempt can help with NTLM can be seen here.

NTLM is a suite of Microsoft security protocols that enables authentication, integrity, and confidentiality for users. NTLM relay is probably the best kept widely known secret of the hacking world. If you ever invited a pen-testing firm to perform a security audit, they were probably able to compromise your network with some sort of NTLM relay attack.

Figure 1 contains a brief introduction to how NTLM relay is carried out:

In NTLM, simplistically, whenever a user wishes to connect to a server, the server issues a challenge and the user encrypts the challenge with their password hash. An attacker could create a parallel session with a server he wishes to attack and use the same challenge, forwarding the same encrypted hash to create a successful NTLM authentication. Using the successful NTLM authentication, the attacker could, for instance, open a Server Message Block (SMB) session and infect the target system with malware.

NTLM credential relay is thwarted in one of two ways:

SMB signing – SMB signing is a configuration where the server negotiates with the client to digitally sign all incoming packets with a derived session key. This way, even if the NTLM session was relayed, the server cannot be exploited as the attacking machine does not have any knowledge of the session key. Apart from SMB, DCE/RPC communications are also protected using this technique. At this point, it is worth mentioning that in an Active Directory network, the default is only for Domain Controllers to have SMB signing, where all other servers/workstations are not protected by default. Enhanced Protection for Authentication (EPA) – EPA is a mechanism where as part of the authentication process, the client is requested to digitally sign an element of the TLS session with the derived session key. EPA is used with HTTP among other protocols. This method protects the server from credential relaying in the same manner. It is also worth noting that the method holds several important caveats. First, it requires the protocol to support TLS. Second, EPA does not have any centralized configuration to enable it throughout the network. This means, that every server/application administrator has to manually enable it (default is usually off) to protect their application from credential forwarding.

Vulnerability 1: LDAP Relay (CVE-2017-8563)

The first vulnerability we report here is that Lightweight Directory Access Protocol (LDAP) is not protected from NTLM relay.

The LDAP protocol is used in Active Directory to query and update all domain objects (users, groups, endpoints, etc). There is a special configuration in the Group Policy Object (GPO) – “Domain Controller: LDAP server signing requirements”. When this GPO is set to “Require Signing” the domain controller rejects LDAP sessions that are not either digitally signed with a derived session key or the entire session is encrypted over TLS (LDAPS).

The vulnerability here is that while LDAP signing protects from both Man-in-the-Middle (MitM) and credential forwarding, LDAPS protects from MitM (under certain circumstances) but does not protect from credential forwarding at all. This allows an attacker with SYSTEM privileges on a machine to use any incoming NTLM session and perform the LDAP operations on behalf of the NTLM user. To realize how severe this issue is, we need to realize all Windows protocols use the Windows Authentication API (SSPI) which allows downgrade of an authentication session to NTLM.

As a result, every connection to an infected machine (SMB, WMI, SQL, HTTP) with a domain admin would result in the attacker creating a domain admin account and getting full control over the attacked network.

Vulnerability 2: RDP Relay

The second issue we reported is with RDP Restricted-Admin. RDP Restricted-Admin allows users to connect to a remote machine without volunteering their password to the remote machine that might be compromised.

RDP Restricted-Admin took some heat in the past since it allows an attacker to connect to a remote machine using pass-the-hash and similar techniques. But, no one in the past published a way to compromise a user performing RDP to a compromised endpoint. Preempt discovered that RDP Restricted-Admin, which is sometimes referred to (mistakenly) as Kerberosed RDP, allows downgrade to NTLM in the authentication negotiation. This means that every attack you can perform with NTLM such as credential relaying and password cracking could be carried out against RDP Restricted-Admin.

As RDP Restricted-Mode is often used by support technicians with elevated privileges to access remote machines, this puts their credentials at risk of being compromised. Furthermore, when combined with the first LDAP relay issue, this means that each time an admin connected with RDP Restricted-Admin an attacker was able to create a rogue domain admin.

Microsoft response Center (MSRC) response and timeline

Microsoft acknowledged both issues. For the first, a CVE has been issued (CVE-2017-8563) and a fix has been released. For the second, Microsoft claimed it is a “known issue” and recommends configuring the network to be safe from any sort of NTLM relay.

Timeline:

2017-04-02 – Preempt makes the first contact with MSRC to report about new vulnerabilities

2017-04-06 – MSRC acknowledges our initial report

2017-05-09 – MSRC confirms issue with LDAP and issues tentative CVE-2017-8563 and states RDP issue should be fixed by a method of configuration

2017-07-11 – Microsoft fixes CVE-2017-8563 as part of July patch Tuesday.

How Can I protect myself from these vulnerabilities?

The bottom line: NTLM is very risky as it puts you at risk of credential forwarding and password cracking. If you can, you should avoid using it in your network and you’ll be a lot safer.

I realize the previous recommendation might not be feasible for many organizations. So to be safe, I suggest taking the following steps (1-2 are must, 3-5 are highly recommended):