With all the attention and noise focused on the Microsoft cloud, it’s easy to forget sometimes that there is still a substantial fleet of on-premises servers running SharePoint and Exchange. Despite the spotlight being on the cloud, the engineering teams at Microsoft still work on on-premises Exchange, the latest proof being the release of cumulative update 14 for Exchange Server 2019 on 13 February 2024. This update, formally known as the “2024 H1 Cumulative Update for Exchange Server,” fixes several bugs, but more importantly, contains a fix for a serious security issue that is being exploited in the wild.
Extended Protection Rides Again
Back in September 2022, I wrote about Exchange adding support for Windows Extended Protection (EP). To briefly recap, EP is a Windows feature that improves Windows’ built-in authentication functionality for IIS web apps (including Exchange) by adding an additional channel binding token (CBT) to protect against adversary-in-the-middle (AitM) attacks where an attacker sits between the source system and a target system, intercepting, modifying, and/or replaying requests from the source. At the time of that article, EP could be enabled for Exchange by using a set of Microsoft scripts, but initial uptake seemed fairly low. In August 2023, Microsoft forewarned its installed base that when Exchange 2019 CU14 was released, Microsoft would default to enabling EP when CU14 was installed on an Exchange server. Now CU14 is here.
CVE-2024-21410 is a Serious Vulnerability
While not a perfect rule, it’s a safe bet that most security issues serious enough to be given a CVE number are worth immediate attention. When Microsoft issues a CVE number, it is a recognition that a vulnerability exists—the associated CVSS severity rating tells you how serious the vulnerability is. In this case, the CVSS score is 9.8 of a possible 10.0, so it is well worth your time to mitigate.
The vulnerability here is that an attacker can mount an escalation-of-privilege (EOP) attack by capturing NTLM credentials and replaying them against an Exchange server. This is a pretty classic AitM attack, one which can be blocked in two ways: you can stop the credential theft on the client side, or you can harden the server so that it ignores the replayed credentials. The EP subsystem takes this latter approach, but Microsoft has a guide to mitigating hash-based replay attacks that has some valuable guidance for protecting the client. This attack gets a 9.8 because it’s easy to conduct, can be performed over a network, does not require the attacker to have any privileges, and does not require a targeted user to take any action. A successful attack lets the attacker impersonate the victim to the Exchange server, meaning the attacker can send, read, or delete items in the user’s Exchange mailbox, or take administrative actions if the victim account has administrative privileges.
In this case, Microsoft requested this CVE number in December 2023, but they didn’t assign it to a specific issue until February 13, 2024. This assignment, and the resulting disclosure, are because Microsoft detected signs that this vulnerability was being exploited in the wild. Despite Microsoft releasing EP support 16 months ago, there were enough unprotected servers to allow a large enough number of successful attacks for Microsoft to notice. Although they have not publicly said so, this is likely because there are easy-to-use automated attack tools circulating.
Enabling EP with CU14
It’s important to note that all CU14 does is apply EP by default when you install it. You can do this manually using the ExchangeExtendedProtectionManagement.ps1 script. In fact, you could already have enabled EP with this script, and you may still need to do so to enable EP on your Exchange 2016 servers (if any) after upgrading servers to CU23.
CU14 does not check to see whether your organization is ready to support EP. You still need to run the Exchange Server Health Checker script to verify that your organization (and servers) can support the enablement of EP, and even then, there are some caveats:
- If you have public folders on Exchange 2016 CU22 or older, Exchange 2019 CU11 or older, or any version of Exchange 2013: first, you should be ashamed of your lack of patching. Second, you cannot deploy EP anywhere or it will break public folder access everywhere; you need to move your public folders to Exchange 2016 CU23 or Exchange 2019 CU14 (and decommission any Exchange 2013 servers if they’re still around.)
- If you use SSL offloading on a load balancer, you must switch to using SSL bridging. Bridging will only work if you use the same TLS certificate on the IIS front end and the load balancer.
- If you have SSL offloading for Outlook Anywhere enabled, the CU14 installer will turn it off for you.
- If you use the Modern Hybrid agent to publish Exchange to the Internet, you need to disable EP on the Exchange servers that are also published.
If you just run the Exchange CU14 setup utility in GUI mode, or by using the command-line version of Setup with no defaults, the installer will enable EP on that server. This is a change from the ExchangeExtendedProtectionManagement script, which will enable EP on every Exchange server it can find on the network. You can disable EP for the entire server with the /DoNotEnableEP switch, or only for the EWS front-end directory with the /DoNotEnableEP_FEEWS switch. The only identified reason to use /DoNotEnableEP_FEEWS is when updating a server that’s published via the Modern Hybrid agent.
Validation and Checkout
Microsoft has a list of Exchange features that may break after enabling EP, but the list has not changed since the original introduction of EP support. If you pay attention to the bullets in the previous section, you are unlikely to run into problems. However, after updating all Exchange 2019 servers in the organization to CU14, you should run the ExchangeExtendedProtectionManagement script with the -ShowExtendedProtection switch to validate that all the updated servers are properly configured with appropriately enabled.
Enabling EP by default is a long-overdue security improvement; Microsoft has given its customers plenty of advance warning of this change, as well as ample documentation of why it’s important. Don’t postpone the upgrade.
