Microsoft Updated Recommendations for Protecting against ProxyNotShell Vulnerabilities

Microsoft engineers have updated their recommendations for protecting against 0-day vulnerabilities in Exchange (CVE-2022-41040 and CVE-2022-41082), which are known as ProxyNotShell. The problem is that there are still no patches for these problems, and security researchers have shown that the company’s original protective recommendations could be easily bypassed.

As Microsoft soon confirmed, hackers have already exploited these problems with the execution of the arbitrary code. According to experts, at least one group has already used these bugs against about 10 companies around the world.

For now, experts keep the technical details of the vulnerabilities secret so that even more attackers do not take advantage of them. But when the bugs became known, Microsoft issued recommendations to mitigate the problem. Alas, the URL blocking rule proposed by the engineers turned out to be too specific, and, as information security specialists soon demonstrated, it can be easily bypassed.

Since the experts suggested their workarounds, Microsoft reviewed them and provided an updated version of recommendations for protecting against ProxyNotShell. The screenshot below shows the main differences between the improved recommendation and the original one.

At the same time, security researchers quickly noticed that the {URL} to {REQUEST_URI} condition in the URL rewrite rule still allows attackers to bypass security measures. For example, analyst Peter Hyle points out that the condition for filtering strings in a URI does not take into account the character encoding, and this, in essence, makes the rule ineffective.

Well-known information security expert and former CERT/CC analyst Will Dormann agrees with Hyle and explains that {REQUEST_URI} is useless when encoding characters. According to him, it’s better to use {UrlDecode:{REQUEST_URI}}.

Another well-known information security specialist, Kevin Beaumont, who named the vulnerabilities ProxyNotShell, writes that his colleagues are right: ProxyNotShell continues to be exploited, with hackers bypassing both the previous and newer protection method proposed by Microsoft.

As a result, Microsoft was forced to once again revise its recommendations for protecting against ProxyNotShell. For example, customers with Exchange Emergency Mitigation Service (EEMS) enabled automatically receive updated URL rewrite protection for Exchange Server 2016 and Exchange Server 2019.

The EOMTv2 custom script (version 22.10.03.1829) now also includes an improved URL rewrite rule. It is automatically updated on computers connected to the Internet and should be run again on any Exchange server that does not have EEMS enabled.

The third option is to manually delete the previously created rule and add an improved one:

1. open IIS manager;
2. select a default site;
3. in Feature View click on URL Rewrite;
4. in the Actions panel on the right click on Add Rule(s)…;
5. select Request Blocking and click OK;
6. add the line “.*autodiscover\.json.*Powershell.*” (without quotes);
7. in Using, select Regular Expression;
8. in the How to block section, select the Abort Request item, and then click OK;
9. expand the rule and select the rule with the pattern: .*autodiscover\.json.*Powershell.* and click on Edit in the Conditions section;
10. change {URL} to {UrlDecode:{REQUEST_URI}}.

Additionally, Microsoft strongly recommends disabling PowerShell remote access for non-admin users.

Let me remind you that the resonance around these vulnerabilities is so great that they are already trying to sell fake exploits for ProxyNotShell on GitHub. Researchers from the Flashpoint company even report that an exploit for fresh vulnerabilities was recently sold on the Russian-speaking forum for $250,000. Whether this exploit was real, experts could not figure out.