[German]A 0-day vulnerability (ZDI-CAN-18333) in Microsoft's on-premises Exchange Servers (2013, 2016, and 2019) has been known since late September 2022. The vulnerabilities (CVE-2022-41040, CVE-2022-41082) are already being exploited in the wild. Microsoft did respond and published a workaround as well as rolled out URI rewrite rules via EMS for protection. But the URI rewrite expressions can be bypassed. In addition, the first (so far fake) exploits are being offered on the Internet. Here is an overview of the latest developments.
Advertising
The 0-day vulnerability ZDI-CAN-18333
As of Sept. 29, 2022, I had reported on the 0-day vulnerability ZDI-CAN-18333 in the blog post Exchange Server servers attacked via 0-day exploit (Sept. 29, 2022). Microsoft Exchange Server 2013, 2016 and 2019 are at risk from two unpatched zero-day vulnerabilities CVE-2022-41040 (Server-Side Request Forgery) and CVE-2022-41082 (Remote Code Execution via PowerShell).
The term ProxyNotShell is now used for the vulnerability because the vulnerabilities require a similar attack scenario to ProxyShell, but it is not the ProxyShell vulnerability.
Fortunately, an attacker needs authenticated access to the vulnerable Exchange Server to successfully exploit either vulnerability. In addition, he must be able to execute PowerShell scripts (remotely), but then has the option of elevating privileges. 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).
My gut feeling, however, is that the people behind the exploit (presumably based in China) have enough credentials from phishing attacks to attack numerous Exchange servers. The night I came across the above tweet from Sophos supporting this assessment. Sophos picked up on it here (see also above tweets)and writes that customers are protected with Sophos security solutions.
In the meantime, the first (but so far probably fake) exploits for the above vulnerabilities are being offered for sale on the Internet by fraudsters. The colleagues from Bleeping Computer have pointed out the situation in this article.
Microsoft's workaround can be bypassed
Last night I came across the following tweet from Kevin Beaumont on Twitter. A security researcher with the alias Jangggg looked at the URL pattern described by Microsoft in the blog post Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server. His conclusion: the URI blocking rule is not sufficient, and can be easily bypassed. Beaumont verified it and confirms this.
Advertising
Microsoft has added the following guidance to the articles Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server as of October 2, 2022:
- Added to the Mitigations section: we strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization. Guidance on how to do this for single user or multiple users is here.
- Updated Detection section to refer to Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082.
Administrators should prevent remote PowerShell access from running in their Exchange environment. Then a vulnerability can no longer be exploited and the attack vector no longer works in the previously known way. Problem: However, this could allow administrators to lock themselves out unintentionally in certain scenarios (see this warning from Beaumont). In the following YouTube video, security researcher Jang demonstrates his findings (just click the image and watch the video on YouTube).
(Source: YouTube)
The colleagues from Bleeping Computer have published some more details in this post. To summarize: Security researchers like Will Dormann as well as the Vietnamese discoverers had tested Jang's approach and found that the pattern ".autodiscover.json.*@.*Powershell." was not sufficient to prevent attacks. The @ character is too much of a restriction, they say. The security researcher suggested the URI pattern ".*autodiscover\.json.*Powershell.*". Looks like the issue will continue to keep Exchange administrators busy. Above all, customers with hybrid Exchange solutions should be aware that they may also be at risk. Colleagues at Bleeping Computer state that, according to Beaumont, hybrid Exchange installations from more than 1,200 companies are accessible via the Internet.
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
Similar articles
Exchange Server Security updates (August 9, 2022)
Microsoft Exchange Server: Remote Code Execution vulnerability CVE-2022-23277 exploitable despite patch?
Anatomy of a Hive Ransomware Attack on Exchange via ProxyShell
ProxyShell, Squirrelwaffle and a new PoC Exploit, patch your Exchange Server!
Exchange and ProxyShell: News from Microsoft and security experts
ProxyShell, ProxyLogon and Microsoft's contradictious Exchange doc for virus scan exceptions
Wave of attacks, almost 2,000 Exchange servers hacked via ProxyShell
Attacks on Exchange Server via ProxyShell vulnerability (8/13/2021)
Exchange Server: Update on ProxyShell vulnerabilities
Issues with Exchange March 2022 Updates
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
