Exchange on-prem only Security Advisory An elevation of privilege vulnerability exists in Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could attempt to impersonate any other user of the Exchange server. To exploit the vulnerability, an attacker would need to execute a man-in-the-middle attack to forward an authentication request to a Microsoft Exchange Server, thereby allowing impersonation of another Exchange user. A planned update is in development. If you determine that your system is at high risk then you should evaluate the proposed workaround. After installing the update you can undo the above action with this command: New-ThrottlingPolicy AllUsersEWSSubscriptionBlockPolicy
for more about ThrottlingPolicy
Run the following command to create throttling policy
The attack scenario described in the blog referenced above requires NTLM. Systems that have disabled NTLM are not affected.
ttackers cannot compromise a Domain Admin account if an OnPrem deployment follows Microsoft’s security best practice guidance and has implemented Active Directory Split Permissions. For more information on using Active Directory Split Permissions with Exchange, see Understanding split permissions: Exchange 2013 Help.
This document refers to Exchange Server 2013, but the same model can be used for later versions of Exchange Server.
about this EWS Subscription throttling workaround:
A customer’s risk assessment must weigh the protections gained by the workaround as compared to the possible unwanted side effects of the workaround. The following are possible side effects of the EWS Subscription throttling policy:
This workaround may be disruptive to Outlook for Mac, Skype for Business Client, and Apple Mail Clients, causing them to not function properly. Importantly, the throttling policy won’t block Autodiscover and Free/Busy requests. The EWS throttling policy will also negatively impact LOB and other third-party Applications that require EWS Notifications. A second policy can be created to whitelist trusted accounts.
In the command output, review the “Result” section of the probe. If the value is succeeded, the issue was a transient error, and it no longer exists. Otherwise, refer to the recovery steps outlined in the following sections.