[German]It's becoming somewhat like a never-ending story. Two 0-day vulnerabilities (CVE-2022-41040, CVE-2022-41082) in Microsoft's on-premises Exchange Servers (2013, 2016, and 2019) have been known since late September 2022. The vulnerabilities, known as ProxyNotShell, are already being exploited in the wild. Since the vulnerabilities became known, Microsoft has been trying to publish workarounds for protection. During the night (on October 5, 2022), the URI rewrite rules were updated to protect against attacks because the original rules could be circumvented. But that's not sufficient, the new rule can be bypassed too. Here's an overview of the latest developments, and administrators should respond.
The ProxyNotShell 0-day vulnerabilities
As of Sept. 29, 2022, I had reported on the 0-day vulnerabilities CVE-2022-41040 (Server-Side Request Forgery) and CVE-2022-41082 (Remote Code Execution via PowerShell) in the blog post Exchange Servers are attacked via 0-day exploit (Sept. 29, 2022). Suspected state-sponsored attackers (from China) are using a combination of these vulnerabilities to attack on-premises installations of Microsoft Exchange Server 2013, 2016 and 2019 and install a web shell there.
The attackers do need authentication on the Exchange Server in question to successfully exploit either vulnerability. In addition, he must be able to execute PowerShell scripts (remotely), but then has the possibility of privilege elevation.
Microsoft updates it's mitigation
Microsoft had quite early proposed a URI rewrite rule ".autodiscover.json.*@.*Powershell." suggested by the discoverer of the vulnerability to intercept attack attempts as a workaround. In addition, this rule has also been deployed to appropriate Exchange servers via Emergency Mitigation Service (EMS).
In the blog post Microsoft's 0-day protection bypassed, new assessments (Oct. 3, 2022), however, I pointed out that security researchers have shown that Microsoft's mitigations using a URI rewrite rule can be bypassed. Security researchers like Will Dormann as well as the Vietnamese discoverers then proposed the URI pattern ".*autodiscover\.json.*Powershell.*" for the rewrite rule. As of October 5, 2022, German blog reader R.S. has reached out in this comment to report that Microsoft has responded:
By the way, Microsoft adjusted the Exchange Mitigation EM1 tonight, now it has the pattern .*autodiscover\.json.*Powershell.* in it.
This closes the gap in the original pattern.
The information can be found at Microsoft in the article Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server, where an update is noted for October 5, 2022:
Added under Mitigations section that Exchange Server customers should complete both recommended mitigations.
The Mitigations section then notes that Microsoft has made the following fixes:
- Exchange Server 2016 and Exchange Server 2019 with Exchange Emergency Mitigation Service (EEMS) enabled automatically receive the updated URI rewrite rule.
- Microsoft has also updated the EOMTv2 script that creates the mitigation steps per the URI Rewrite rule to include the URL Rewrite rule enhancement. The EOMTv2 script is automatically updated on computers with an Internet connection. The script should be re-run on any Exchange Server without EEMS enabled.
In addition, Microsoft has since modified the illustrated instructions for manually entering the URI rewrite rule. Administrators should therefore check whether the URI rewrite rule has been adapted accordingly.
MS URI Rewrite rule may be bypassed!
Unfortunately, the URI rewrite rule provided above by Microsoftalso falls short. Attackers could encode the strings in the printout – as Will Dormann points out in the following tweet (thanks to Stefan for the tip).
So you have to let the characters in the string decode with {UrlDecode:{REQUEST_URI}}.
What probably protects against ProxyNotShell
On-premises installations that are not accessible via the Internet should be protected against remote attacks. However, many Exchange installations are directly accessible via the Internet (see Microsoft's recommendations for Exchange Server 0-day vulnerability ZDI-CAN-18333). At this point, I would like to refer to the comment by German reader Byom, who writes:
A reverse proxy is the only means of choice to offer potentially vulnerable services on the Web in a reasonably secure manner.
From practical experience, the following have proven to be effective:1. deploy Nginx reverse proxy for Exchange (see).
2. reverse proxy only OWA and/or Microsoft Server ActiveSync through to Exchange.
3.enable Linux firewall and secure IP block lists, e.g. ipset-blacklist ipset blacklist
4. fail2ban monitors faulty accesses and block IP automatically.
In addition, Microsoft recommends disabling access to Remote PowerShell for the Exchange Server. Then one of the two vulnerabilities can no longer be exploited.
Currently, only isolated attacks on Exchange Server installations are known. All in all, this is a bad situation and Microsoft is again not really covering itself with glory. I expect a patch next Tuesday, October 11, 2022.
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
