Last month, researchers at cybersecurity firm GTSC discovered cyberattacks actively exploiting two zero-day vulnerabilities in the Microsoft Exchange email system. The researchers at the Zero Day Initiative (ZDI) reported these two vulnerabilities, which verified this report and forwarded it 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 presented measures that Exchange Server administrators can implement to reduce the possibility of an attack that exploits these vulnerabilities. Unfortunately, cybersecurity researchers have now shown that these measures can be easily circumvented.
The two vulnerabilities in question are listed in the National Vulnerability Database (NVD) as CVE-2022-41040 and CVE-2022-41082 and both have a high severity score of 8.8 out of 10. The vulnerabilities also appear in the Cybersecurity & Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog as a Chinese threat actor uses these two vulnerabilities in combination to gain remote access to Exchange servers. The attacker chains the two vulnerabilities together by using the first vulnerability to perform privilege escalation, which then allows the attacker to exploit the second vulnerability to perform remote code execution. From there, the attacker can gather information, create persistent backdoors, and access other servers on the local network.
Location and number of Exchange servers where Outlook Web App is exposed to the internet (click to enlarge)
The attack begins with the following request: autodiscover/[email protected]/&Email=autodiscover/autodiscover.json%[email protected]. This request appears to be identical to the one used in the 2021 ProxyShell attack. However, this new attack requires authentication on the part of the attacker, leading Kevin Beaumont to name the attack ProxyNotShell. Exchange servers running Outlook Web App exposed to the open internet are vulnerable to this attack, and a quick search on Shodan reveals that over 200,000 Exchange servers are currently configured in this way. Exchange Server administrators can block this specific attack pattern by following these steps, courtesy of Microsoft:
Open IIS Manager.
Select Default website.
In the feature view, click URL Rewrite.
In the action pane on the right, click Add rule(s)…
Select Request blocking and click OK.
Add the string “.*autodiscover\.json.*\@.*Powershell.*‘ (without quotation marks).
Select Regular expression under Use.
Under select Cancel request 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 that condition input from {URL} to {REQUEST_URI}
Microsoft’s Exchange Emergency Mitigation Service (EEMS) automatically applies mitigation to Exchange servers when this service is enabled. The company also created a script that automatically applies this blocking rule. However, it turns out that this rule is too specific and blocks 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 a tweet This shows that a slight change in the ProxyNotShell attack’s requirement bypasses the mitigation. Luckily, a change to the debuff seems to be blocking the bypass. Instead of creating a blocking rule with the string .*autodiscover\.json.*\@.*Powershell.*Administrators can extend the effectiveness of this rule by using the string instead .*autodiscover\.json.*Powershell.*.
Exchange server hybrid deployments exposed to the internet (click to enlarge) (Source: Kevin Beaumont)
Microsoft’s blog post also states that “Exchange Online customers don’t need to take any action,” but that statement isn’t entirely true. Some organizations run hybrid deployments that mix Exchange Online with on-premises Exchange servers. Many of these hybrid deployments are exposed to the open internet, making them just as vulnerable to ProxyNotShell attacks as regular on-premises Exchange servers. Therefore, organizations running either configuration should ensure they implement the modified mitigation measure outlined above.
Leave a Comment