Update 9Mar2021: Re-added PDF link, break-down mitigation addressing and link to Krebson article.
Another month, another set of security updates for Exchange Server 2016 and 2019, including an out-of-band update for Exchange 2013 CU23 and Exchange 2010 SP3 (Rollup 32) as well. According to the related Exchange team blog, these exploits are seen being used as part of an attack chain. The security update is critical, as the vulnerability exists on all recent versions of Exchange, and which is why updates for Exchange 2013 and 2010 were made available as well.
These fixes address the following Remote Code Execution vulnerabilities:
- Exchange 2013/2016/2019
- Exchange 2010/2013/2016/2019
The exploit can be fixed by security update, or in case of Exchange 2010 SP3 by applying a Rollup, which you can find in the table below per current Exchange version.
Exchange Build | Download | Build | Article | Supersedes |
Exchange 2019 CU8 | Download | 15.2.792.10 | KB5000871 | KB4602269 |
Exchange 2019 CU7 | Download | 15.2.721.13 | KB5000871 | KB4602269 |
Exchange 2016 CU19 | Download | 15.1.2176.9 | KB5000871 | KB4602269 |
Exchange 2016 CU18 | Download | 15.1.2106.13 | KB5000871 | KB4602269 |
Exchange 2013 CU23 | Download | 15.0.1497.12 | KB5000871 | KB4593466 |
Exchange 2010 SP3 RU32 | Download | 14.3.513.0 | KB5000978 |
Notes:
- You may not be prompted for a reboot, but one is required.
- When manually installing the update use an elevated command prompt, don’t just double-click the .msp. To apply an .msp from an elevated prompt, e.g.
msiexec.exe /p <Full Path to File>
. - When you need to update to a more current Cumulative Update first, update using an elevated command prompt, e.g.
setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms
- Per product group feedback, Exchange 2010 is not vulnerable to the same attack chain as Exchange 2013/2016/2019, hence the Rollup mentioning a single CVE.
- When running product levels earlier than the ones patched, i.e. Exchange 2016 CU17, you are at risk. There are no patches for earlier product levels, so you need to update to a recent CU after which you can install the security update.
- When installing a recent CU first in order to be able to install the security update, reboot after installing the CU, then install the security update. This prevents issues caused by files being locked or updating files pending replacement during reboot.
- When you are significantly behind regarding keeping your Exchange servers up to date, the blog Upgrade Paths for CU’s and .NET might help in determining an update strategy.
- The statement to stay up to date with at most CU n-1 is not some random adage; apart from features and fixes, it also allows you to quickly respond to these type of emergencies.
- Make sure you have configured proper Anti-Virus/Malware exclusions for Exchange server, as documented here for Exchange 2016/2019. I’ve seen significant delays or even hangs during setup of Cumulative Updates because of paths and processes not being excluded. When running Exchange virtually, any I/O inspection running on top of your hypervisor is also considered anti-virus/malware software, such as Trend Micro Deep Inspection on VMWare.
- When deploying CU(n) on top of CU(n-1) when an interim update already has been installed, it is recommended to uninstall the IU prior to deploying CU(n). While it might go through, an abort is likely with mention of detecting an IU (INTERIMUPDATEDETECTED) in Exchange Setup log.
- Security Updates are Cumulative Update level specific. You cannot apply the update for Exchange 2016 CU18 to Exchange 2016 CU19. Note that the security update file has the same name for different Cumulative Updates; I would suggest tagging the file name with the CU level, e.g. Exchange2016-CU18-KB5000871-x64-en.msp.
You may want to look for signs that your Exchange server might have been compromised (Indicators of Compromise or IOC). The article HAFNIUM targeting Exchange Servers with 0-day exploits explains this process.
Microsoft also published an official communication to support this update, including steps to remediate issues with updates and steps to perform analysis (many people overlook the recommendation to run the update elevated for some reason). This deck can be found here: March 2021 Exchange Server Security Update – v1.2.65 – EN.pdf (thanks Chris Lehr).
I would also recommend the official follow-up post, which not only has been updated since the original post, but also includes mitigations for organizations which cannot deploy the update yet:
- A script to configure IIS rewrite rules to block cookies used in the attack (mitigates CVE-2021-26855).
- Disabling UM Services (mitigates CVE-2021-26857).
- Disabling ECP application pool (mitigates CVE-2021-27065).
- Disabling OAB application pool (addresses CVE-2021-26858).
Needless to say, steps like disabling ECP or OAB impacts client functionality. The post also contains a reference to the MS Emergency Response Tool which you can run to detect and remediate vulnerabilities on systems which are not covered by Defender.
Since some people are discovering artifacts of HAFNIUM dating before Microsoft’s official communication, people have been wondering how long this has been going on. For those interested, Krebson Security has published an article with a concise timeline of the events related to this attack. Reports are an estimated 10,000 to over 30,000 Exchange on-premises servers have been hit.