It wasn’t so long ago that the press was filled with reports about the HAFNIUM family of attacks against Exchange Server installations around the world. It was bad enough that this vulnerability was exploited by a number of very capable nation-level advanced persistent threat (APT) groups, but it got worse when exploit tools began to spread widely. That triggered a frenzy of patching, and it probably helped accelerate at least some migration to Exchange Online, which wasn’t affected.
One thing that came out of the ProxyShell/ProxyWeb attacks was a better understanding of what other hardening measures might usefully be applied to enterprise Exchange Server installations. The US Department of Defense already maintains hardening guides for Exchange 2010, Exchange 2013, and Exchange 2016, and the US National Security Agency even makes recommendations for securing PowerShell. Ultimately, however, Microsoft has both the most knowledge about what mitigations and defenses might be applied and the most to gain from implementing them. That brings us to the recent release of a new capability for Exchange: support for Windows Extended Protection.
What Extended Protection protects against
Security professionals talk about a whole class of attacks collectively known as man-in-the-middle (MITM) attacks. These attacks include those where a passive eavesdropper (let’s call her Eve) intercepts communications between two endpoints and those where a malicious attacker (let’s call him Mallet) intercepts but also changes traffic to mount an attack. This kind of attack might be done at small scale (perhaps stealing user credentials for online banking sites over a coffee shop or airport lounge WiFi) or at large scale, such as by eavesdropping on all Internet traffic to or from a specific country.
In general, MITM attacks work like this:
- Mallet establishes himself in the middle of a communications network. There are lots of ways to do this, including spoofing WiFi or cellular endpoints, playing tricks with network routing so that all traffic on a subnet goes to Mallet, or subverting a network proxy or other appliance.
- The user requests a service of some kind, perhaps logging into Microsoft 365. Mallet allows this request to pass without altering it.
- The service asks the user to authenticate. Mallet either captures the authentication credentials and replays them to the service or captures the response token from the service and keeps a copy to replay separately.
Once the user’s authenticated, Mallet may inspect and/or modify traffic, and at any time Mallet can use either the captured credentials or the captured token to imitate the user. Of course, there are various ways to protect against these attacks—for example, Microsoft 365 and Windows Server Kerberos both have protections against replay attacks. But these attacks in part are possible because the network layer and application layer don’t have any way to verify each other—by design, the application isn’t supposed to know or care how the network layers are satisfying its requests, and the network isn’t able to interpret application-specific authentication traffic.
How Extended Protection works
Extended Protection helps protect against MITM attacks by adding two items to the communications channel:
- The channel binding token (CBT) ties together the network-layer secure channel (in our case, usually TLS) with the application-layer authentication; it identifies either the network channel or the service endpoint that’s to be used.
- A set of zero or more service principal name (SPN) objects that specify what network endpoint the client is actually trying to communicate with. The SPNs are passed from the client to the server—think of it like a tamperproof ticket that says “User A is trying to talk to service B.”
The CBT and SPN are both cryptographically signed so that Mallet can’t tamper with either of them. The receiving server can verify both CBT and any provided SPNs to ensure that it’s the correct target. For example, a client that is requesting access to a destination server through a proxy (as might be the case in a large enterprise network) can include SPNs both for the proxy and the destination endpoint. Both the proxy and the target server can verify that the traffic came from the expected partner; that is, the target server will only accept traffic sent to the server and coming from the proxy. Even if Mallet manages to compromise the network path and insert his own device into the path, he can’t tamper with the SPNs, and he can’t sign his own in a way that the server will accept.
It’s important to note that full support for Extended Protection is only possible when every device in the network path supports it. Microsoft currently warns in their documentation that some customers who are using SSL offloading devices, load balancers, or other devices that need to interpose themselves in legitimate network traffic, will not be able to enable Extended Protection support in Exchange.
The Microsoft 365 Kill Chain and Attack Path Management
An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!
Extended Protection support in Exchange
Extended Protection support in Exchange is possible because Exchange uses Windows IIS, which implemented support for Extended Protection in IIS version 7.5. However, Exchange support wasn’t introduced until the August 2022 Exchange security updates, which are available for Exchange Server 2013, 2016, and 2019. Microsoft added Extended Protection support to Exchange to help mitigate some specific vulnerabilities, including some that allow privilege escalation and are rated as “critical.”
To deploy Extended Protection on Exchange, you’ll first need to install the August 2022 security updates. This just makes it possible to enable Extended Protection; it doesn’t change your security configuration, so you should immediately patch your Exchange servers instead of waiting until you’re ready to enable Extended Protection. Once the August 2022 update is deployed to all your Exchange servers, the next step is to read the Exchange Extended Protection documentation very carefully, then have a nice hot cup of coffee and read it again. That’s for two reasons. First, when you enable Extended Protection, you’re telling Exchange that it should reject certain network traffic, and you need to understand the limitations and exceptions (such as incompatibility with some load balancers) that the documentation outlines. For example, if you’re using public folders with Exchange 2013, you have to choose between Extended Protection support and public folder access, as enabling Extended Protection will break PF access. Second, the best way to enable Extended Protection support is by using a script that Microsoft provides to enable it on all your servers… something you don’t want to do until you are sure you understand the impact.
Enabling Extended Protection
This article can’t possibly be long enough to cover all the ins and outs of setting up Extended Protection in an even moderately complex environment, but we can at least walk through the major steps.
- Go read the documentation.
- Ensure that all your servers have the latest Exchange cumulative update (Cu23 for Exchange 2013, CU22 for Exchange 2016, and CU11 for Exchange 2019) plus the August 2022 security updates.
- Review the documentation again for limitations. In particular, if you’re using public folders or have Modern Hybrid configured with Office 365 using the Hybrid Agent, be sure you understand Microsoft’s guidance on what to do.
- Verify that all your Exchange servers are configured with the same TLS configuration. Microsoft’s recommendation is to enable TLS 1.2 everywhere and to ensure that the SchUseStrongCrypto registry value is set to 1 on all servers. Your goal in making these changes is to minimize the risk that client connections will fail because of TLS or crypto provider configurations.
One pro tip from Microsoft: use LogParserStudio to query all your Exchange server’s W3Clog files to find what clients are connecting to them and what TLS versions they’re using. Ideally, you’ll do this before changing your TLS configuration to make sure you don’t break anything important. - Run the Exchange Health Checker script and fix any problems you find.
- Run the ExchExtendedProtectionManagement.ps1 script to do the actual deed.
The Exchange Extended Protection scripts
Technically, the Exchange Health Checker script isn’t part of the Extended Protection package. However, you should run it as part of your Extended Protection deployment. It is a comprehensive tool that will report on the overall health and configuration of your Exchange servers—your goal is to fix anything that the health check report shows in red before proceeding with Extended Protection deployment.
The script that actually applies the Extended Protection changes is called ExchangeExtendedProtectionManagement.ps1. You’ll need to run it from an elevated Exchange Management Shell prompt, using an account that has the Organization Management role. When you do, its default behavior will be to find every Exchange server in your organization, verify that it has the correct CU and security updates, and make a couple dozen changes to the virtual directory configuration. You can pass parameters to the script to either target or exclude specific servers. For example, you’ll need to skip any servers that have the Hybrid Agent on them.
Microsoft has promised that they’ll be updating and improving the script in the future, too. For now, perhaps the most important feature is the script’s default behavior of backing up the IIS application settings for each server—you can use the –RollbackType flag to undo any changes made by the script to any server that’s not working properly after the update.
Troubleshooting
The documentation has a good section on troubleshooting errors that the Extended Protection script may throw. Realistically, a better resource is probably the original blog post announcing Extended Protection, where many early adopters posted their initial results, not all of which were good. If you run into a problem when enabling Extended Protection, that’s probably the best place to see if others have had a similar problem and, if so, how they fixed it. Extended Protection is fully supported by Microsoft, so you can always open a support case if you encounter trouble and they’ll help you with it.
Extending protection into the future
The appearance of Extended Protection support for Exchange is both good and worrisome. It’s good because it shows that Microsoft is able to quickly act to improve the security of their products by using platform capabilities that already exist in Windows and IIS. This is supposed to be one of the benefits of the integration that Microsoft has long touted. It’s worrisome because it highlights the fact that attackers are continuing to search for, discover, and exploit vulnerabilities in Exchange—the clock in this game never stops. For now, Extended Protection support is an effective protection against a whole class of MITM attacks that were possible before, and that’s reason enough for you to speedily deploy the fixes.
