Two Zero-Day Vulnerabilities Hit Exchange Server

Issue Affects Exchange 2013, 2016, and 2019

First picked up by Vietnamese company GTSC and described in a September 28 blog post, a new day-zero attack on Exchange Server is in the wild. According to GTSC, the origin of the attack appears to a Chinese group based on the code page used and the presence of Antsword, a Chinese-based cross-platform website administration tool. Two vulnerabilities are involved, neither of which affect Exchange Online. This is solely an on-premises problem.

Update November 8, 2022: Microsoft has released security updates for Exchange 2019, Exchange 2016, and Exchange 2013 to address the vulnerabilities discussed here and other issues. Customers do not have to remove the mitigation released earlier. The advice to block non-admin accounts from using remote PowerShell remains as it serves to reduce the available attack surface.

Microsoft Response

GTSC reported the exploit to Microsoft. On September 29, the Microsoft Security Response Center (MSRC) acknowledged the vulnerabilities and documented recommendations for customers running Exchange 2013, 2016, and 2019 servers. The two vulnerabilities are:

• CVE-2022-41040: A server-side request forgery (SSRF) vulnerability.
• CVE-2022-41082: A remote code execution (RCE) vulnerability. The SSRF vulnerability can enable an attacker to remotely trigger this vulnerability. According to some researchers, this vulnerability is like the ProxyShell vulnerability reported in July 2021 (CVE-2021-34473).

Microsoft says that they have seen evidence of “limited targeted attacks using the two vulnerabilities” to access servers. The MSRC emphasizes that an attack must gain authenticated access to a vulnerable Exchange server before they can exploit either of the vulnerabilities. The authenticated account can be a standard user. It does not need to be an administrator account. Microsoft says that they’re working on a fix that will be released through the normal security update mechanism.

Mitigations Available

In the meantime, the MSRC post documents step-by-step directions for a mitigation that administrators can apply to servers. The mitigation adds a request blocking rule to the URL rewrite feature to detect a string matching what an attack might use and change it to a harmless response. Microsoft says that adding the rule will not affect Exchange server functionality.

Microsoft also says that blocking the ports used for Remote PowerShell can limit attempts launched by authenticated attackers to trigger the RCE exploit (CVE-2022-41082). The important point here is that the attacker must be able to authenticate before they can do damage.

The Exchange team published a note to bring the MSRC information to the attention of customers. If you have questions about what to do, ask it there. It will help Microsoft hear and appreciate the voice of the Exchange community. The comments contain some good information, including how to apply the URL rewrite rule.

Microsoft’s Mitigation Strategy

The Microsoft Security Threat Intelligence team has also posted their analysis of the limited attacks that have been observed in the wild. As a response, Microsoft has released an update for the Exchange Mitigation service to deal with the URL rewrite. This applies to Exchange 2019 and Exchange 2016. (October 3 Update). Some security researchers consider Microsoft’s fix to be insufficient because it can be easily worked around, so this issue might still have some distance to go before it’s finally closed off.

The latest (October 2) MSRC advice is to disable remote PowerShell for non-admin users to block an attacker that gains access to a server with a normal account from exploiting the vulnerability. This is easily done by running the Set-User cmdlet to block the protocol. There’s a good argument for removing Remote PowerShell from non-admin accounts as standard operating procedure because “normal” users don’t need to interact with Exchange Server via PowerShell. Be careful when disabling Remote PowerShell to ensure that administrator and service accounts (those used to run PowerShell batch jobs) are not affected.

Overall, Microsoft’s mitigation strategy so far is to break the attack chain observed in the wild by closing the gap revealed by CVE-2022-41040. Although this leaves CVE-2022-41082 as an unaddressed vulnerability (except by removing Remote PowerShell access from as many users as possible), the logic is that if you stop attackers penetrating to a point where they can exploit the Remote PowerShell vulnerability, you’ve stopped the attack chain. However, if attackers compromise accounts in another way, CVE-2022-41082 remains a possible route to an attack. Obviously, a complete solution won’t be available until Microsoft has the time to develop a full-blown security update for Exchange Server.

Never Good News in Exchange Day-Zero Vulnerabilities

Obviously, no day-zero vulnerability is good news. Getting two at the one time is even worse. However, mitigations are available and should be applied to servers while we wait for Microsoft to issue a security update.

On-premises administrators might ask why these kind of problems never affect Exchange Online. Well, similar code might run on the 300K physical mailbox servers running inside Exchange Online, but the difference is the layers of protection Microsoft applies to stop attackers from getting anywhere near an Exchange Online server. That, and the way that Microsoft is constantly updating servers to make sure that they’re completely up-to-date with the latest operating system and application software, is why a vulnerability discovered in Exchange Server is seldom noted in Exchange Online. Depressingly, many on-premises servers are not maintained well and you can’t expect the FBI to step in and fix problems on servers as they did following the Hafnium attack in 2021.

Attackers might discover the golden lode if they found a way into Exchange Online, but the sad fact is that on-premises servers are a much easier target to go after. My advice continues to be that if an organization can move email to the cloud, they should. And if you really must continue to run on-premises Exchange servers, make sure that the servers are as up-to-date as possible. Hard work and constant vigilance are the only way to secure on-premises servers.