Microsoft has updated the mitigations for the most recent ProxyNotShell zero-day Exchange vulnerabilities, tagged as CVE-2022-41040 and CVE-2022-41082.
Researchers demonstrated that the initial recommendations can be easily overridden to allow new attacks that take use of the two flaws, therefore they were insufficient.
The proposed mitigation could still open the door to ProxyNotShell attacks, hence the second modification was still insufficient.
Rewrite URL rule improvements
Reported privately to Microsoft three weeks ago, CVE-2022-41040 is a server-side request forgery (SSRF) that enables privilege escalation and works with CVE-2022-41082 to trigger remote code execution on on-premise Exchange server deployments.
Both security issues come with a high-severity score mainly because exploiting them requires authentication.
In August, a threat actor was discovered installing China Chopper webshells and using the bug chain to do Active Directory reconnaissance and data exfiltration.
Microsoft issued mitigations to stop these well-known threats on October 3. Because of how narrowly focused the proposed URL filtering rule was, attackers may still use the Exchange vulnerabilities in fresh attacks.
This was noted by numerous security researchers, who suggested a less stringent short-term fix until fixes were ready.
Microsoft carefully considered the advice and included it in the revised mitigations. The key distinction between the revised advice (green) and the original guideline is seen here (red).
Security researchers discovered that the URL Rewrite rule’s “URL to REQUEST URI” condition still enables attackers to go around the mitigation.
Freelance hacker Pieter Hiele discovered that character encoding was not taken into account in the condition for filtering strings in the URI, making the rule ineffective:
Hiele’s bypass is effective, according to Will Dormann, a former analyst at CERT/CC, who also explained that REQUEST URI is worthless when characters are encoded.
The more advantageous option is UrlDecode:REQUEST URI, which decodes the URL-encoded input string and enables a match to a given pattern, in this example.
*autodiscover\.json.*Powershell.*
According to security researcher Kevin Beamont, who gave the two flaws the name ProxyNotShell, it only takes one letter to go beyond Microsoft’s original better defence.
Microsoft changed the condition to “UrlDecode:”REQUEST URI” and revised the mitigation to take URL-encoded scenarios into account.
Beaumont also keeps an eye on ProxyNotShell attacks and discovered that threat actors were using both the old and new methods of getting around Microsoft’s mitigation measures.
Additionally, 24 IP addresses were detected scanning for the ProxyNotShell vulnerable system, with 22 of them being flagged as malicious by research firm GreyNoise.
Three ways to reduce risk
Microsoft stated on Tuesday that it had updated its advisories with the enhanced URL Rewrite rule and advised Exchange Server users to study it and use one of the three offered mitigation measures.
The new URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019 is immediately available to customers that have Exchange Emergency Mitigation Service (EEMS) enabled.
The URL Rewrite rule improvement is now included of the EOMTv2 script (version 22.10.03.1829). On computers with internet access, it is updated automatically, and any Exchange Server without EEMS turned on needs to execute it once more.
The third choice is to manually add the improved rule and remove the old one by following the steps below:
Launch IIS Manager.
Choose the default web page
Click URL Rewrite in the Feature View.
Click Add Rule(s) in the Actions pane on the right side of the screen.
Click OK after selecting Request Blocking.
The phrase “.*autodiscover.json.*Powershell.*” should be added (excluding quotes).
Under Using, choose Regular Expression.
Click OK after selecting Abort Request in the How to block section.
Click Edit under Conditions after expanding the rule and choosing the rule with the pattern:.*autodiscover.json.*Powershell.
Replace the input for Condition with UrlDecode:REQUEST URI.
Microsoft also advises blocking non-admin users’ access to remote PowerShell. The restriction can be applied to one or more people, and the procedure should not take more than five minutes.
Given that Microsoft offers these protections to clients who use on-premise Exchange servers, organisations that use a hybrid setup are equally at risk.
Additionally, firms who expose their Exchange servers to the public web run the danger of being attacked. Some of them work in the public, private, and educational sectors, making them desirable targets for both cybercriminals and nation-state hackers.
Update [October 5, 12:19 EST]: This article has been updated to reflect new information that has come to light regarding Microsoft’s current mitigation measures’ inadequacy to prevent ProxyNotShell attacks.
Updated at 2:52 EST on October 6: Microsoft revised its ProxyNotShell mitigation once more to address the URL-encoding issue. To reflect this change, we updated the article.
