New Workaround to Mitigate the ProxyNotShell, Two 0-Day Vulnerabilities in Microsoft Exchange Server

According to security researchers Jang and Will Dormann, advisories published to mitigate CVE-2022-41040 and CVE-2022-41082, two 0-day vulnerabilities in Microsoft Exchange Server earlier, are not sufficient. The published mitigations could be circumvented to install the Chopper web shell on Exchange servers. Microsoft has a new workaround to mitigate the ProxyNotShell vulnerabilities to lower the impact until the release of the percent fix. Let’s see what is included in the new workaround to mitigate the ProxyNotShell (CVE-2022-41040 and CVE-2022-41082), two 0-day vulnerabilities in Microsoft Exchange Server.

The term ProxyNotShell has been coined to represent the CVE-2022-41040 and CVE-2022-41082 vulnerabilities due to its similarities with another set of flaws called ProxyShell. If you remember, CVE-2022-41040 is a 0-day SSRF vulnerability in Microsoft Exchange Servers. It allows an attacker to trigger CVE-2022-41082 remotely. The flaw has got the CVSS score of 8.8 out of 10. The second flaw, CVE-2022-41082, is an RCE vulnerability that can be exploited remotely by an authenticated attacker. It resembles ProxyShell, discovered in 2021 by Orange Tsai. The CVSSv3 score for this vulnerability is 8.8. 

Jang tweeted , “The URL pattern to detect/prevent the Exchange 0day provided in MSRC’s blog post can easily be bypassed @GossiTheDog“

Will Dormann tweeted, “The ‘@’ in the Microsoft-recommended “.*autodiscover\.json.*\@.*Powershell.*” URL block mitigations for CVE-2022-41040 CVE-2022-41082 seems unnecessarily precise, and therefore insufficient.”

Microsoft has published mitigations for on-prime Exchange Servers as there is no official patch released. However, a week later publishing the mitigation steps, security researchers identified the provided steps were not sufficient. Following that, Microsoft shared a new workaround to mitigate the ProxyNotShell Vulnerabilities.

New Workaround to Mitigation the ProxyNotShell:

However, Microsoft has published a new workaround to mitigate the ProxyNotShell (CVE-2022-41040 and CVE-2022-41082) vulnerabilities on the ade to protect the customers using on-premise Microsoft Exchange servers. 

Microsoft has recommended enabling the URL Rewrite module on Exchange servers. Anyways, it doesn’t know to be impacted its functionality. Additionally, Microsoft recommends blocking these two HTTP, and HTTPS ports (5985 & 5986) used to run PowerShell remotely, which would also be considered to be in minimizing the attack surface.

The mitigation will be automatically enabled if you’re using Exchange Server EMS (2016 and 2019). However, the best practice to fix the problem is to add a blocking rule in IIS Manager -> Default Web Site -> URL Rewrite -> Actions, following the steps given below. It will block all the known patterns and protect your systems from external attacks. 

On October 4, 2022, Microsoft updated the new URL Rewrite rule. Users of Exchange Server are recommended to review and choose any one of the following three mitigation options:

Option 1: Enable the Exchange Emergency Mitigation Service (EEMS) on Exchange Server 2016 & 2019

For the users of Exchange Server 2016 and Exchange Server 2019 who have enabled the Exchange Emergency Mitigation Service (EEMS), Microsoft released the URL Rewrite mitigation enabled automatically with an improved URL Rewrite rule. Please see this blog post for more information.

Option 2: Connect the Exchange Server to the Internet and run the EOMTv2 script with the updated URL Rewrite rule

Microsoft has updated the improved URL Rewrite rule in the EOMTv2 script. The EOMTv2 script is set to auto-update on Internet-connected Exchange Servers, and the updated version will be shown as version 22.10.03.1829. We recommend running the EOMTv2 script upon connecting your Exchange servers to the Internet. Make sure that EEMS should be disabled. 

Option 3: Update the URL Rewrite rule in IIS Manager

Replace this new string “.*autodiscover\.json.*Powershell.*” with the old one “.*autodiscover\.json.*\@.*Powershell.*” in the URL Rewrite rule. 

How to Mitigate CVE-2022-41040 and CVE-2022-41082 Vulnerabilities

Step 1. Open IIS Manager on the Exchange server

In Server Manager and go to Tools –> Internet Information Services (IIS) Manager

Step 2. Open ‘URL Rewrite’ feature for ‘Autodiscover’ under ‘Default Web Site’ in IIS Manager

In IIS Manager, navigate to Hostname (This this sample – EXCH19) –> Sites –> Default Web Site –> Autodiscover.
Select ‘URL Rewrite‘ under ‘IIS‘.In the right-pane, click on ‘Open Feature‘ under ‘Actions‘.

Step 3. Add a rule under ‘URL Rewrite’

Under ‘URL Rewrite‘ feature, click on ‘Add Rule(s)‘ under ‘Actions‘ to create a new Inbound rule.

Step 4. Add a new Rule for ‘Request blocking’

In the Add Rule(s) window, select ‘Request blocking‘ under ‘Inbound rules‘.  This will create a rule to block client requests based on certain text patterns in the URL path, query string, HTTP headers, and server variables. Click on ‘OK‘ to proceed further.

Step 5. Update Pattern (URL Path) in Request Blocking Rule

In ‘Add Request Blocking Rule‘ window, update the string “.*autodiscover\.json.*Powershell.*” (excluding quotes). Select Regular Expression under Using. Select Abort Request under How to block and then click OK.

Step 6. Edit the Conditions for the Inbound Rule with the Pattern “.*autodiscover\.json.*Powershell.*”

In ‘URL Rewrite‘ page, expand ‘RequestBlockingRule1‘ and select the Rule with the Pattern “.*autodiscover\.json.*Powershell*” and click on ‘Edit‘ under ‘Conditions’.

Step 7. Update Condition input from {URL} to {REQUEST_URI}

Under ‘Edit Condition‘ page, change the ‘Condition input‘ from {URL} to {REQUEST_URI} and click on ‘OK‘

CVE-2022-41040 and CVE-2022-41082 vulnerabilities in Microsoft Exchange Server are chained to increase the attack surface; if an attacker exploits the former, they can also trigger the latter. The exploitation enables an attacker to process malware execution or even have complete control over the affected system. To avoid this exploitation, it is crucial to know about the new workaround to mitigate the ProxyNotShell vulnerabilities.

We hope this post would help you know about the new workaround to mitigate the ProxyNotShell, two 0-day vulnerabilities in Microsoft Exchange Server. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram and subscribe to receive updates like this. 

You may also like these articles: