UPDATE: Microsoft fixed the vulnerability formally, as expected, in the February updates to Exchange.
Drop us a line if you have any questions or concerns about staying patched.
What is PrivExchange?
Last week Microsoft acknowledged a vulnerability, now being referred to as PrivExchange, that impacts all supported versions of Exchange (2010 through 2019).
(Technically, the issue exists due to NTLM and not to Exchange itself. But, given how Exchange leverages NTLM, this is a big deal. )
To summarize, this vulnerability involves a man-in-the-middle attack that requires the ability to intercept client-to-server communications as well as to leverage a compromised computer account to connect outbound via EWS, leveraging NTLM, and authenticate using EWS Push.
If successful, an elevation of privilege can be achieved. The risk within an environment depends on the ability to and likelihood of achieving both of the above tasks.
How to Stop PrivExchange
While no official fix is out yet, the Exchange Product Group recently approved the official mitigation steps of disabling loopback checking via the registry and disabling EWS subscriptions on each Exchange server. Disabling loopback checking can be done with the following:
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f
This does not require a reboot or any service restarts to take effect.
Removing DisableLoopbackCheck in the registry is a prerequisite to additional changes. In addition to this change, Microsoft is also recommending that EWS subscriptions be blocked entirely. Neither the removal of DisableLoopbackCheck nor blocking of EWS subscriptions on their own are sufficient. Both need to be completed to form an effective workaround to this issue.
If you choose to block EWS subscriptions at the Organization level (per the syntax below), be careful and determine first whether it will break any functionality for applications or users within the environment. It very well might. In that case, if the associated functionality is required, you will need to “trust” these users and allow EWS subscriptions for them via a targeted whitelist Throttling Policy. This will increase risk but the goal is for this to be temporary until the next Exchange CU is released.
To prevent EWS subscriptions from being created, use the following steps:
1. Create an organization-scoped policy that blocks all EWS subscriptions:
New-ThrottlingPolicy -Name NoEwsSubscriptions -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0
2. Create a regular-scoped policy, to whitelist “trusted” users who require full EWS functionality:
New-ThrottlingPolicy -Name AllowEwsSubscriptions -ThrottlingPolicyScope Regular -EwsMaxSubscriptions 5000
3. Assign the regular policy to any “trusted” users:
Set-Mailbox User1 -ThrottlingPolicy AllowEwsSubscriptions
The Exchange Product Group is working on a more holistic and complete solution to this issue and expects to address it in the next CU for Exchange.
On a related note, complete mitigation can be achieved via moving to a split-permissions model between AD and Exchange. This is a much more involved process and, as such, it would need to be planned, tested, and executed extremely carefully.
Official documentation on this vulnerability can be found here and here.
Questions about implementing the fix above? Get in touch with one of our Exchange experts.