[German]One more addendum regarding On-Premises Exchange Server (2016-2019) and the two 0-Day vulnerabilities (CVE-2022-41040, CVE-2022-41082) known since the end of September 2022. As of the weekend (October 8, 2022), Microsoft had again tweaked its articles to mitigate these vulnerabilities. In addition, a blog reader came forward to point out errors in the fixed PowerShell script. I'm just getting around to writing an addendum on the state of affairs today. With any luck, there will be a patch in a few hours.
Advertising
The ProxyNotShell vulnerability
In on-premises installations of Microsoft Exchange Server 2013, 2016 and 2019, 0-day vulnerabilities CVE-2022-41040 (server-side request forgery) and CVE-2022-41082 (remote code execution via PowerShell) were publicly disclosed in late September 2022. Suspected state-sponsored attackers (from China) used a combination of these vulnerabilities to attack on-premises installations of Microsoft Exchange Server 2013, 2016 and 2019 and install a web shell there.
These attacks had come to the attention of security researchers, who then issued a public warning. I had addressed the issue on September 29, 2022 in the blog post Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022). And subsequent blog posts (see links belos) covers further changes in Microsoft's mitigations (see the next section).
Currently, there are no known major waves of attacks on Exchange Server via these vulnerabilities. Possibly also because the attackers need authentication on the Exchange Server in question to exploit both vulnerabilities. In addition, the attacker must be able to execute PowerShell scripts (remotely), but then has the possibility of privilege elevation.
Microsofts Workarounds
Since the announcement of the 0-day vulnerabilities, Microsoft has also published guidance on how to prevent attacks via these vulnerabilities. In addition to a URI rewrite rule that administrators can set, it has suggested disabling Remote PowerShell for user accounts (though this should be done with caution so as not to inadvertently lock out an administrator remotely).
Exchange Server 2016 and Exchange Server 2019 with Exchange Emergency Mitigation Service (EEMS) enabled will automatically receive the updated URI rewrite rule. Administrators don't actually need to take action here. Microsoft also provided the EOMTv2 script for PowerShell, which administrators can use to automatically execute the relevant protection measures. This is helpful, for example, for all Exchange servers that do not support Exchange Emergency Mitigation Service (EEMS), as it saves the manual creation of the URI rewrite rule.
Advertising
New enhancements as of October 8
The only problem with this approach is that Microsoft has had to adjust this pattern several times since the first URI rewrite rule was released (see links at the end of the article). Then, as of October 8, 2022, the URI rewrite rule was adjusted a second time. The information can be found at Microsoft in the article Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, which states:
October 8, 2022 updates:
A correction was made to the string in step 6 and step 9 in the URL Rewrite rule mitigation Option 3. Steps 8, 9, and 10 have updated images.
In step 6, the URL rewrite rule is now (?=.*autodiscover)(?=.*powershell), and Regular Expressions must be selected for Using. In addition, How to block must be set to the value Abort Request (see the following screenshot).
The Condition input field has to be changed from {URL} to {UrlDecode:{REQUEST_URI}}. Blog reader Stefan A. had already mentioned this in this German comment on October 8, 2022 and also provided the information that the EOMTv2 script has also been updated and the new URI rewrite rule is being rolled out via EEMS – thanks for that. Further, blog reader Andy M. emailed me again today to point out these fixes (thanks).
At least nothing went wrong with the EOMTv2 script during the October 8, 2022 revision. In the previous version, a buggy EOMTv2 script was released – as German blog reader cram points out in this comment.
German blog reader Andy M. pointed me to a German article from heise on the same topic in his today's mail. Interesting in this context is this German comment. A user reports that after setting the above URI rewrite rule, various customers are having issues importing new profiles. Anyone from the readership who has also noticed this?
The develompment has become a bit of a "groundhog day" – the topic has probably become too complex – also due to the regular expressions. I'm assuming that today, Tuesday, October 11, 2022 (Patchday) security updates will be rolled out with Microsoft Exchange 2013 – 2019, which will then also close the 0-day vulnerabilities listed under the name ProxyNotShell. Then the "mitigation orgy" via a URI rewrite rule should come to an end.
Until then, Exchange administrators can only keep themselves informed about the fixes of the workaround and check the entries for the URI rewrite rules. If after the patchday and installed security updates a manual intervention regarding the set URI rewrite rule has to be done is currently unknown to me.
Article series:
Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022)
Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333
Update on Exchange Server 0-day Vulnerability ZDI-CAN-18333: Fixes, Scripts and EMS Solution
Exchange Server: Microsoft updates it's mitigation for the 0-day ProxyNotShell vulnerability (October 5, 2022)
Exchange Server: Microsofts improves solutions for 0-day mitigation again (October 8, 2022)
Similar articles:
Exchange Update errors and information (April 13, 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange 2016/2019: Outlook problems due to AMSI integration
Exchange Server September 2021 CU comes Sept. 28 with Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Custom attributes in ECP no longer updatable after CU installation (July 2021)
Exchange Server 2013: Microsoft's tips on decommissioning the systems
Update for Exchange Extended Protection script, but still error
Tip: Exchange Health Checker – Script extensions by Frank Zöchling
Advertising