Exchange 0-days: CVE-2022-41040 & CVE-2022-41082

Update (Oct5, 2022): Updated URL Rewrite Rule to filter on URL decoded URI.

End of last week, the Exchange world was made aware of a 0-day vulnerability and exploit through the following tweet by security researcher Kevin Beaumont. The tweet referenced a write-up by GTSC Cyber Security, which published their discovery on a what looked like a variation on ProxyShell, allowing for Remote code execution. The vulnerabilities have been registered by the Common Vulnerabilities and Exposures program as CVE-2022-41040 (ZDI-CAN-18333 at Zero Day Initiative) and CVE-2022-41082 (ZDI-CAN-18802).

The 0-day impacts current versions of Exchange Server 2019, Exchange Server 2016 as well as Exchange Server 2013 when published externally. If you have Exchange Hybrid deployed only for recipient management or mail-flow (i.e. no inbound traffic for https/443), you should be OK. Similar to ProxyShell, the vulnerability consists of sending manufactured requests to Exchange server, e.g.

Read the full of this article on ENow here.

Update (Oct3): The (original) filter to mitigate the situation, specified by the GTSC as well as various websites, is too specific. The filter can easily be circumvented by – but effectively identical – variations on the manufactured request. A more broad rule to filter requests is:

.*autodiscover\.json.*Powershell.*  

Update any existing mitigation IIS URL Rewrite Rules with this Regular Expressions filter for {UrlDecode:{REQUEST_URI}} blocking any matching request. If you depend on the EEMS rules, I recommend manually configuring this rule as EEMS might overwrite its own managed URL Rewrite rules with the outdated rule.

Microsoft updated their advisory, and is now also recommending organizations to disable Remote PowerShell for non-administrators roles (instructions here). For those wanting to hunt for indicators of compromise, check the end of the Security blog.

Update (Oct4): Microsoft updated the rules pushed via EEMS, which now also reflects the more broader filter. Vendors are also offering solutions to filter these requests using their network components, e.g.

Update (Oct5): The filter works pre-URL decoding, meaning one can simply replace any character in the URI with its %<code> counterpart, rendering the filter ineffective. To counter this, explicitly state you want to filter on the URL Decoded string of the request’s URI – see instructions above for updated guidance.

At the time of writing, Microsoft has not publish a security fix yet.

The Last Exchange Server

In the announcement of the most recent set of Cumulative Updates for Exchange Server 2019 and 2016, Microsoft introduced some changes – features if you will – as well, which were received with enthusiasm. An overview of these Cumulative Updates and the features introduced was given in an earlier article. In this article however, I would like to zoom in on one of those features, which also happens to be a popular topic among customers running Exchange Hybrid deployments, “The Last Exchange Server”.

Up to Exchange 2019 CU12 (2022 H1), customers that migrated to Exchange Online were still required to leave Exchange-related components running on-premises. Even today, with all the information published around this topic, I am surprised this still surprised customers. This Exchange server running on-premises is to be used for managing recipients which have their source of authority in Active Directory, leveraging Active Directory Connect to propagate objects to Azure Active Directory and thus Exchange Online. Also, when there is a need to relay messages from applications or multi-functional devices, customers often need to have an Exchange server on-premises to accept these messages, as Exchange is the only supported mail relay product for hybrid deployments.

Click here to read the full article on ENow Solutions blog.