Exchange Privilege Elevation Vulnerability Addressed by Microsoft Patches
Exchange and a Privilege Elevation Vulnerability
An enormous amount has been written about the privilege elevation vulnerability in Exchange. Now, in an unprecedented move, Microsoft has issued patches to address the problem. You can read the EHLO blog to learn Microsoft’s perspective on the issue and download the updates as follows:
- Exchange Server 2013 – Cumulative Update 22
- Exchange Server 2016 – Cumulative Update 12
- Exchange Server 2019 – Cumulative Update 1
A roll-up update is available for Exchange 2010 (see below).
Microsoft recommends that customers install the updates as soon as possible
Devolutions Remote Desktop Manager
Devolutions RDM centralizes all remote connections on a single platform that is securely shared between users and across the entire team. With support for hundreds of integrated technologies — including multiple protocols and VPNs — along with built-in enterprise-grade password management tools, global and granular-level access controls, and robust mobile apps to complement desktop clients.
Why unprecedented? Well, since Exchange 2013, Microsoft has settled into a well-worn routine of issuing quarterly cumulative updates, which are full and complete versions of Exchange that include all available updates and fixes for a server at the time of issue. What Microsoft does not do is make architectural changes to Exchange in cumulative updates. Yet that is exactly what occurs here.
Although unusual, it’s a good response from Microsoft. The vulnerability has not been used in any publicly-known attack, but that’s not to say that this might not happen in the future. In addition, security researchers have developed the techniques exploited in the vulnerability step-by-step since October 2018, so the weaknesses being probed need to be closed off permanently before a bad actor succeeds in a damaging attack.
Changing EWS Push Notifications
The changes are two-fold to address the weaknesses exposed in the vulnerability. The first and probably most important change affects push notifications issued by the Exchange Web Services (EWS) API and consumed by clients such as Outlook for Mac. The change removes the hash of the Exchange server credentials from notifications used to authenticate the connections. When you apply the cumulative update to a server, EWS push notifications no longer carry these credentials (see KB4490060 for details).
As part of its mitigation strategy for the vulnerability, Microsoft applied this change within Exchange Online some time ago. No reports of client connection problems subsequently arose. This doesn’t mean that some third-party app that uses EWS push notifications might not experience issues, but it does mean that the commonly used clients continue to work happily.
Microsoft says that if customers need to delay deploying cumulative updates to servers, they should consider implementing a workaround by deploying an EWS throttling policy. Be aware that such a policy will impact how clients that depend on all forms of EWS notifications work. Push notifications are affected by the vulnerability, but disabling notifications also affects pull and streaming notifications.
Limiting Exchange Rights Over Active Directory
The second change is in the rights that Exchange has over Active Directory. Ever since Exchange 2000 switched to use Active Directory, the server has had extensive rights over directory objects, including the root of any domain holding Exchange servers. The rights are used throughout Exchange for operations as mundane as creating mailboxes or assigning Send As permission to mailboxes
The widespread use of Active Permission permissions by Exchange caused no problems initially. With Exchange 2000, we were worried more about understanding the true security boundaries within the directory. And after all, Active Directory was essentially an evolution of the old Exchange Directory Store, so it was natural that the two had a tight connection.
However, as time went by, administrators learned more about how Active Directory worked and customers voiced concerns about the default shared permissions model used to link Exchange and Active Directory. Microsoft responded with the introduction of the Split Permissions model in Exchange 2010.
Organizations that use the split permissions model are not affected by the current vulnerability. However, changing to a split permissions model takes some care and planning. Most organizations are likely to persist with the shared permissions model because it generally works well for how they manage Exchange and Active Directory. The changes Microsoft makes in the newly-released updates eliminate the ability of attackers to use the vulnerability to gain Domain Admin permissions when you use the shared permissions model.
Run Setup Now
A valid argument can be made that Microsoft should have reduced the control Exchange has over Active Directory in the past. But what’s important now is getting the fix out by running the Setup program (from the cumulative update) with the /PrepareAD switch in any Active Directory forest where Exchange servers exist. If you have multiple domains in the forest, you also need to run Setup with /PrepareDomain. Collectively, these steps adjust how Exchange uses Active Directory and close the exposed vulnerability.
Installing a cumulative update on a server is not enough. You must run Setup with these switches to adjust permissions in Active Directory at the forest and domain levels.
See KB4490059 for details of the changes made by Setup for different versions of Exchange. It’s worth emphasizing that you can run Setup to update Active Directory without installing the cumulative release on Exchange servers.
If you still run Exchange 2010 servers, you should install Exchange 2010 SP3 RU26 to fix the EWS problem and then follow the instructions in KB4490059 to run LDP to change Active Directory permissions.
Reset Exchange Credentials
After applying the appropriate cumulative or roll-up update to your servers, you should force a reset of the Exchange server credentials stored in Active Directory. Microsoft recommends using the Reset-ComputerMachinePassword cmdlet. This is a cautionary step to ensure that any possibility of compromised machine credentials are flushed.
Read this post if you’re interested in learning how Microsoft’s Azure Advanced Threat Protection team reacted to the vulnerability. It’s another take on how people understand and respond to developing threat.
Expect Further Vulnerabilities
Attackers won’t relax and stop probing Exchange for weaknesses they can exploit just because Microsoft has addressed this privilege elevation issue. The chess match will continue with move and counter-move from both sides. Although vulnerabilities of this nature are difficult to exploit in the real world, the fact that they exist and could be exploited is enough to warrant the kind of response we see today.
Expect future issues to occur, and when they do, stay calm, understand what’s going on, and then respond – hopefully after Microsoft delivers patches.