Fixing a Multi-Protocol Exchange Server Vulnerability
Last week’s revelation of an Exchange Server vulnerability certainly created quite a stir. Anything to do with security and a potential flaw that might be exploited by attackers has to be dealt with seriously. I’m pretty sure that this is exactly what the Exchange development group are doing as they figure out how to solve the problem. The vulnerability exists in all versions of Exchange on-premises servers, so the solution must work across a large combination of Exchange and Windows versions. This complicates testing to validate any fix and it’s why we haven’t heard Microsoft report much progress to date.
The Ninety Per Cent Question
In the interim, I spoke to several experienced Exchange administrators about the issue. Many questioned the assertion that the attack is feasible in “probably 90% of the organisations … that use Exchange “
Although it’s true that the statement is based on a single person’s experience, most of the administrators I spoke to said that they had already enforced LDAP signing and channel binding for Windows domain controllers, as per Microsoft’s security baseline. Some had also disabled NTLM and use Kerberos or modern authentication; others had disabled SMB V1 and implemented SMB2 signing using the RequireSecuritySignature registry key. Restrictions might also be in place to block some or all application access to the URLs used by EWS.
Considering the number of mailboxes migrated to Office 365, I think most of the “Exchange server in the closet” type of installation has moved to the cloud and now run happily as an Office 365 tenant. The remaining on-premises deployments are, by and large, solid implementations run by experienced and competent people who know both Exchange and Windows well. These administrators are likely to have paid attention to security and made sure that their domain controllers are locked down.
This doesn’t mean that some organizations do not run Exchange in a poorly configured manner. In any large population there will be both good and bad examples (including where office politics stops the Exchange and Active Directory and network teams working together as well as they should). But some doubt must be cast on the assertion that 90% of organizations running on-premises Exchange might be vulnerable to the reported flaw.
I don’t want to downgrade the seriousness of the vulnerability in any way. It is a problem that Microsoft must fix. I merely point out that some mitigation might already exist in production environments.
Although Exchange and Active Directory are usually tightly coupled in terms of management, a split permissions model can be used to divide responsibilities for management of the two entities. If you use split permissions, you have mitigated the attack. The problem is that relatively few organizations use split permissions today and it’s not easy to switch an organization into split permissions mode, so another solution is needed..
The Loopback Check
Some interesting suggestions to block the exploit were discussed in different forms. One is to disable the loopback check, which is suggested in the FAQ in the MSRC note (CVE-2018-8581) describing the vulnerability. The fix involves setting a registry value called DisableLoopbackCheck. The registry change is made for you in the latest Exchange cumulative update for Exchange 2016 (and the last roll-up update for Exchange 2010). You need to make the change manually on Exchange 2013 and Exchange 2019 servers.
Making the registry change is recommended by the author of the blog reporting the latest vulnerability. Keep in mind that this only blocks loopback on the same server and doesn’t solve cross-server communications. Another problem is that disabling loopback checks might affect other products (like SharePoint) that run on the same server, so you should test after making the change.
Block EWS Subscriptions
Another innovative idea was suggested by Benjamin Delpy. His idea is to create a new Exchange throttling policy to block the ability of Exchange Web Services to use subscriptions (Figure 1). Again, while this will do the job on the server, it has some side-effects in that clients use subscriptions to know when data changes in a folder. Some testing is necessary across the full suite of Outlook clients to know whether the block stops other features working (for instance, Outlook for Mac uses these notifications to know when new mail arrives), but it’s certainly a way to block the attack stone dead.
Update February 5: The Microsoft Security Response Center suggests that if you feel your system is at risk, you can use the workaround to block EWS subscriptions. The same advisory says that “A planned update is in development.” Unfortunately, the command to back out is incorrect as shown. Use Remove-ThrottlingPolicy AllUsersEWSSubscriptionBlockPolicy instead.
Vulnerabilities to be Fixed
Microsoft has not yet released a patch for this vulnerability. As I understand it, driving to a fix is a high priority activity for the Exchange team, but they must create a solution that works across all versions of Exchange on-premises in use today and all the Windows servers/domain controllers that run Active Directory.
The bottom line is that the vulnerability exists, and some innovative work was done to figure out and prove that it is possible for an attacker to use Exchange gain control over a domain controller. Microsoft will fix the underlying issues and close off the holes, but this won’t stop people probing for weaknesses, usually in the dark corners of protocols like NTLM and SMB V1 that we designed for use in a different threat regime. The likelihood is that other vulnerabilities will be found and exploited. Stay tuned here for more information as it becomes available.