Security Researchers Warn Hackers Can Easily Thwart Microsoft's Zero-Day Exchange Mitigations
Last month, researchers at the cybersecurity firm GTSC discovered cyberattacks actively exploiting two zero-day vulnerabilities in the Microsoft Exchange email system. The researchers reported these two vulnerabilities to the Zero Day Initiative (ZDI), which verified this report and passed it on to Microsoft. The Microsoft Security Response Center then published a blog post warning organizations about the vulnerabilities and stating that the company is currently working on a patch to fix the vulnerabilities. The blog post also laid out measures that Exchange Server administrators can implement to mitigate the possibility of an attack exploiting these vulnerabilities. Unfortunately, cybersecurity researchers have since shown that these mitigations can be easily bypassed.
The two vulnerabilities in question are listed in the National Vulnerability Database (NVD) as CVE-2022-41040 and CVE-2022-41082 and both bear high severity scores of 8.8 out of 10. The vulnerabilities also appear in the Cybersecurity & Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities Catalog, as a Chinese threat actor is leveraging these two vulnerabilities in combination to gain remote access to Exchange servers. The attacker chains the two vulnerabilities together, using the first vulnerability to perform privilege escalation, which enables the attacker to then exploit the second vulnerability to conduct remote code execution. From there, the attacker can collection information, create persistent backdoors, and access other servers on the local network.
The two vulnerabilities in question are listed in the National Vulnerability Database (NVD) as CVE-2022-41040 and CVE-2022-41082 and both bear high severity scores of 8.8 out of 10. The vulnerabilities also appear in the Cybersecurity & Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities Catalog, as a Chinese threat actor is leveraging these two vulnerabilities in combination to gain remote access to Exchange servers. The attacker chains the two vulnerabilities together, using the first vulnerability to perform privilege escalation, which enables the attacker to then exploit the second vulnerability to conduct remote code execution. From there, the attacker can collection information, create persistent backdoors, and access other servers on the local network.
The attack begins with the following request: autodiscover/autodiscover.json?@evil.com/ <Exchange-backend-endpoint> &Email=autodiscover/autodiscover.json%3f@evil.com. This request appears identical to the one used in the 2021 ProxyShell attack. However, this new attack requires authentication on the part of the attacker, prompting Kevin Beaumont to name the attack ProxyNotShell. Exchange servers with the Outlook Web App exposed to the open internet are vulnerable to this attack, and a quick search on Shodan shows that over 200,000 Exchange servers are currently configured this way. Exchange Server admins can block this specific attack pattern by performing the following steps, courtesy of Microsoft:
- Open IIS Manager.
- Select Default Web Site.
- In the Feature View, click URL Rewrite.
- In the Actions pane on the right-hand side, click Add Rule(s)…
- Select Request Blocking and click OK.
- Add the string “.*autodiscover\.json.*\@.*Powershell.*" (excluding quotes).
- Select Regular Expression under Using.
- Select Abort Request under How to block and then click OK.
- Expand the rule and select the rule with the pattern .*autodiscover\.json.*\@.*Powershell.* and click Edit under Conditions.
- Change the Condition input from {URL} to {REQUEST_URI}
Microsoft’s Exchange Emergency Mitigation Service (EEMS) is automatically applying the mitigation to Exchange servers with this service enabled. The company also created a script that will automatically apply this blocking rule. However, it turns out that this rule is too specific, blocking the exact URL pattern used by the attacker.
Less than a week after Microsoft published its blog post advising organizations to apply this mitigation, cybersecurity researcher Jang posted a tweet showing that a slight modification to the request featured in the ProxyNotShell attack bypasses the mitigation. Fortunately, a modification to the mitigation appears to block the bypass. Rather than creating a block rule with the string .*autodiscover\.json.*\@.*Powershell.*, administrators can broaden the effectiveness of this rule by instead using the string .*autodiscover\.json.*Powershell.*.
Less than a week after Microsoft published its blog post advising organizations to apply this mitigation, cybersecurity researcher Jang posted a tweet showing that a slight modification to the request featured in the ProxyNotShell attack bypasses the mitigation. Fortunately, a modification to the mitigation appears to block the bypass. Rather than creating a block rule with the string .*autodiscover\.json.*\@.*Powershell.*, administrators can broaden the effectiveness of this rule by instead using the string .*autodiscover\.json.*Powershell.*.
Microsoft’s blog post also states that “Exchange Online customers do not need to take any action,” but this statement isn’t entirely true. Some organizations run hybrid deployments that mix Exchange Online with on-site Exchange servers. Many of these hybrid deployments are exposed to the open internet, making them just as vulnerable to ProxyNotShell attacks as regular on-site Exchange servers. Thus, organizations running either configuration should make sure to implement the modified mitigation measure outlined above.
