Microsoft updates mitigation for ProxyNotShell Exchange zero days

Microsoft has updated the mitigations for the latest Exchange zero-day vulnerabilities tracked as CVE-2022-41040 and CVE-2022-41082, also referred to ProxyNotShell.

The initial recommendations were insufficient as researchers showed that they can be easily bypassed to allow new attacks exploiting the two bugs.

The second improvement was still not enough as the proposed mitigation could still allow ProxyNotShell attacks.

Improved URL Rewrite rule

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.

A threat actor was detected exploiting the bug chain in August to install China Chopper web shells and engage in Active Directory reconnaissance and data exfiltration.

Microsoft on October 3 released mitigations to prevent these known attacks. Since the proposed URL blocking rule was too specific, adversaries could still exploit the Exchange vulnerabilities in new attacks.

Multiple security researchers pointed this out and recommended a less restrictive temporary solution until patches become available.

Microsoft reviewed the suggestion and adopted it in the updated mitigations. Below is the main difference between the improved recommendation (green) and the initial one (red).

However, security researchers found that the '{URL} to {REQUEST_URI}' condition in the URL Rewrite rule still allows attackers to bypass the mitigation.

Freelance hacker Pieter Hiele noticed that the condition for filtering strings in the URI did not account for character encoding, which renders the rule inefficient:

Will Dormann, former analyst at CERT/CC, confirmed that Hiele's bypass works explaining that {REQUEST_URI} is useless when characters are encoded.

The better variant is {UrlDecode:{REQUEST_URI}} that decodes the URL-encoded input string, thus allowing for a match to a provided pattern, which in this case is .*autodiscover\.json.*Powershell.*

Security researcher Kevin Beamont, who named the two vulnerabilities ProxyNotShell, notes that it is enough to encode one letter in the filtering pattern to bypass the initial improved mitigation from Microsoft.

Update: Microsoft updated the mitigation to consider URL-encoded scenarios and switched to the {UrlDecode:{REQUEST_URI}} condition.

Beaumont also monitors ProxyNotShell attacks and noticed that threat actors used both the previous and the current bypass for the mitigation variants from Microsoft.

Furthermore, research company GreyNoise observed scans for ProxyNotShell vulnerable system from 24 IP addresses, 22 of them being marked as malicious.

Three mitigation options

On Tuesday, Microsoft announced that it updated its advisories with the improved URL Rewrite rule, recommending Exchange Server customers review it and adopt one of the three mitigation options provided.

Customers with Exchange Emergency Mitigation Service (EEMS) enabled benefit automatically from the updated URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019.

The EOMTv2 script (version 22.10.03.1829) now includes the URL Rewrite rule improvement. It is automatically updated on internet-connected machines and should be run again on any Exchange Server without EEMS enabled.

The third option is to manually delete the previously created rule and add the improved one by following the instructions below:

1. Open IIS Manager
2. Select Default Web Site
3. In the Feature View, click URL Rewrite
4. In the Actions pane on the right-hand side, click Add Rule(s)…
5. Select Request Blocking and click OK
6. Add the string “.*autodiscover\.json.*Powershell.*” (excluding quotes).
7. Select Regular Expression under Using.
8. Select Abort Request under How to block and then click OK.
9. Expand the rule and select the rule with the pattern: .*autodiscover\.json.*Powershell.* and click Edit under Conditions. 
10. Change the Condition input from {URL} to {UrlDecode:{REQUEST_URI}}

Additionally, Microsoft recommends disabling remote PowerShell access for non-admin users. The operation should take less than five minutes and the restriction can be enforced for only one or multiple users.

It is worth noting that Microsoft provides these mitigations for customers with on-premise Exchange servers, which means that companies with a hybrid deployment are also at risk.

Furthermore, organizations that expose Exchange server over the public web face a higher risk of attacks. Some of them are in the government, financial, and education sectors, making an attractive target for both nation-state hackers and cybercriminals.

Update [October 5, 12:19 EST]: Article updated with new information that emerged after publishing about Microsoft's new mitigation not being enough to block ProxyNotShell attacks.

Update [October 6, 02:52 EST]: Microsoft updated once more the ProxyNotShell mitigation to cover the URL-encoding scenario. We updated the article to reflect this change.