Privilege escalation attacks are sneaky. An existing user has certain privileges (and restrictions) on the network, but a privilege escalation attack can grant that user a higher level of access. That user now can do more on the network and cause more damage.
A combination of several known issues with Microsoft Exchange and related components can allow any user with an Exchange mailbox to become a Domain Administrator, wrote Dirk-jan Mollema, a security researcher with Fox-IT, a security consulting firm based in the Netherlands. Active Directory grants high privileges to Microsoft Exchange by default, and Microsoft’s authentication protocol NTLM (NT LAN Manager) lets authentication performed on one machine to be passed onto other machines on the network (This is called a relay attack).
“In most organisations using Active Directory and Exchange, Exchange servers have such high privileges that being an Administrator on an Exchange server is enough to escalate to Domain Admin,” Mollema wrote.
The vulnerability exists only in on-premises Exchange. Exchange Online is not affected.
US-CERT issued an advisory about the flaw. "A remote attacker could exploit this vulnerability to take control of an affected system."
Microsoft Responds
Microsoft released guidance on addressing the vulnerability, and noted that attackers cannot compromise the Domain Admin account via this vulnerability if the administrators had followed security best practices and implemented Active Directory Split Permissions on Exchange. While the information provided is for Exchange 2013, it can also be applied to later versions of Exchange Server, Microsoft said.
"To address this vulnerability, a Throttling Policy for EWSMaxSubscriptions could be defined and applied to the organization with a value of zero," Microsoft said in the guidance, as that will prevent the Exchange server from sending EWS notifications. An update is planned, but until then, organizations can look at some of the proposed workarounds.
Relaying Authentication
The [Exchange Windows Permissions] group has [WriteDacl] access on the Domain object in Active Directory, which means any member of the group can modify the domain privileges, such as the ability to perform DCSync, or synchronization operations by Domain Controllers. When authentication is relayed to LDAP, objects in the directory can be modified to grant higher levels of access, such as performing DCSync to replicate users’ hashed passwords in Active Directory. An attacker with those hashed passwords can impersonate any users on the network and authenticate to any service using NTLM or Kerberos authentication.
“Thus, if we can get an Exchange server to authenticate to us with NTLM authentication, we can perform the ACL attack,” Mollema said.
A researcher with the Zero Day Initiative discovered a way to get Exchange to authenticate to an arbitrary URL over HTTP via the Exchange PushSubscription API, Mollema said. It was possible to relay the NTLM authentication back to Exchange (in a reflection attack) and impersonate other users. Mollema modified this technique to perform a relay attack against LDAP in order to gain DCSync rights.
"An attacker that has credentials for an Exchange mailbox and also has the ability to communicate with both a Microsoft Exchange server and a Windows domain controller may be able to gain domain administrator privileges," US-CERT wrote in its vulnerability notice.
NTLM isn't the only protocol vulnerable to relay attacks. LDAP (Lightweight Directory Access Protocol) is widely used in enterprises for locating organizations, individuals, and other resources (files and devices) on a network. LDAP lets enterprises access and maintain distributed directory information services. Relaying to LDAP over HTTP would allow automatic authentication to other machines on the network. An attacker on the same network segment as the Exchange server can perform the attack by using an SMB to HTTP relay attack and not have to know the user's Exchange password.
Practical Mitigations
Mollema’s PrivExchange proof-of-concept code shows how a user with an Exchange mailbox can get DCSync privileges as part of a relay attack against LDAP. The code has been tested against the following combinations: Microsoft Exchange 2013 (CU21) on Windows Server 2012R2, relayed to a Windows Server 2016 DC; Microsoft Exchange 2016 (CU11) on Windows Server 2016, relayed to a Windows Server 2019 DC; Microsoft Exchange 2019 on Windows Server 2019, relayed to a Windows Server 2019 DC. The proof-of-concept works against fully patched systems, and on Exchange servers using the default Shared permission mode, Mollema said.
“Microsoft Exchange 2010 SP3 seems to be not affected,” Mollema said, noting that this version negotiated signing similar to SMB. Both version 14.3.435.0 (latest update at the time of writing) and 14.3.123.4 show this behaviour.
Mollema outlined a few things enterprise administrators can do to prevent a PrivExchange attack. The first, and main mitigation would be to remove the “unnecessary high privileges” that Exchange has on the Domain object. If the Exchange server has lower levels of access, that automatically limits how much damage an attacker can cause. Mollema linked to information and PowerShell scripts for removing “dangerous Exchange permissions.”
Since PrivExchange requires NTLM relaying, specifically relaying to LDAP, many of Mollema’s mitigations focus on defending against relay atttacks. Enabling LDAP signing and LDAP channel binding would prevent relaying to LDAP and LDAPS. Enabling Extended Protection for Authentication on the Exchange endpoints in IIS would verify the channel binding parameters in the NTLM authentication. Tying NTLM authentication to a TLS connection prevents relaying to Exchange web services. Microsoft has previously outlined steps (in response to CVE-2018-8518) to remove the registry key which allows relaying back to the Exchange server.
Many organizations do not have SMB signing enabled, so enforcing SMB signing on Exchange servers (and preferable all other servers and workstations in the domain) would help prevent cross-protocol relay attacks to SMB.
Other steps include blocking Exchange servers from making connections to workstations on arbitrary ports, which is a good practice to begin with.
This story was updated to include the US-CERT advisory and the Microsoft security guidance.