Microsoft warned that two zero-day vulnerabilities ( CVE-2022-41040 and CVE-2022-41082 ) are being used against Exchange Server without a patch. CVE-2022-41040 is a Server-Side Request Forgery (SSRF) vulnerability, and CVE-2022-41082 allows remote code execution when PowerShell is accessible to the attacker, Microsoft explained. Microsoft has not released the patch for these vulnerabilities yet.
Microsoft is currently aware of targeted attacks utilizing these two flaws. These attacks allow an authenticated attacker to remotely trigger CVE-2022-41082 thanks to CVE-2022-41040. It should be highlighted that in order to exploit either vulnerability properly, authenticated access to the vulnerable Exchange Server is required.
Researchers claim that CVE-2022-41082 and CVE-2021-34473, the 2021 ProxyShell vulnerability, are closely connected. The new exploit’s request string was made public, and it is the same as the one from the previous year’s vulnerability, as is Microsoft’s mitigation.
These vulnerabilities are reported by the Vietnamese cybersecurity company GTSC as part of its response to a customer’s cybersecurity incident in August 2022; it said the two zero-days had been used in attacks on their customers’ environments dating back to early August 2022.
A Chinese threat group is suspected to be responsible for the ongoing attacks as the webshell codepage uses character encoding for simplified Chinese. The attackers have also deployed the China Chopper webshell in attacks for persistent remote access, a backdoor commonly used by China state-sponsored hacking groups.
At this time, GTSC has NOT released any technical details regarding this new zero-day vulnerability.
Affected Products
- Microsoft Exchange Server 2016 Cumulative Update 23
- Microsoft Exchange Server 2019 Cumulative Update 12
- Microsoft Exchange Server 2019 Cumulative Update 11
- Microsoft Exchange Server 2016 Cumulative Update 22
- Microsoft Exchange Server 2013 Cumulative Update 23
Impact
Successful exploitation of the vulnerabilities allows remote attackers to execute arbitrary code.
Solution
Presently there’s no solution available to fix the vulnerabilities, but Microsoft has provided the mitigation steps that prevent the attack. Please refer to the below “New Mitigation” section for mitigations.
Exchange Online customers do not need to take any action.
The current Exchange Server mitigation is to add a blocking rule in “IIS Manager -> Default Web Site -> URL Rewrite -> Actions” to block the known attack patterns. Reviewing and choosing only one of the following mitigation options is recommended.
Option 1: For Microsoft Exchange users with the Exchange Emergency Mitigation Service (EEMS) enabled, Microsoft released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. The mitigation will be enabled automatically.
Option 2: Run the Exchange On-premises Mitigation Tool v2 (EOMTv2), available on Microsoft Github
Option 3: Exchange users can follow the below instructions, which are currently being discussed publicly, and successfully break current attack chains.
1. Open IIS Manager.
2. Select Default Web Site.
3. In the Feature View, click URL Rewrite.
4. In the Actions pane 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 {REQUEST_URI}
NOTE: If it is needed to change any rule, it is best to delete and recreate it.
Impact: There is no known effect on Exchange functionality if URL Rewrite is installed as recommended.
Microsoft strongly recommends Exchange Server users disable remote PowerShell access for non-admin users in their organization.
Updates: Initial Mitigation is ByPassed
The present URL rewrite mitigation is easily bypassed as the proposed URL blocking rule was too specific, and attackers could still exploit the Exchange vulnerabilities in new attacks.
Pieter Hiele, the freelance hacker noticed that the condition for filtering strings in the URI did not account for character encoding, which renders the rule inefficient. The former analyst Will Dormann at CERT/CC confirmed that Hiele’s bypass works explaining that {REQUEST_URI} is useless when characters are encoded.
Microsoft is aware of these mitigation bypass techniques and provided new mitigations to prevent further attacks. we strongly advise applying new mitigation as provided below.
New Mitigation:
- The regular expression string in steps 6 and 9:
Steps 6 and 9: Remove @.* and escape the dot in .json with \.
“.*autodiscover.json.*@.*Powershell.*” changes to “.*autodiscover\.json.*Powershell.*” (excluding quotes) - The Condition input in step 10
Step 10: Update {REQUEST_URI} to {UrlDecode:{REQUEST_URI}}
{REQUEST_URI} changes to {UrlDecode:{REQUEST_URI}}
SanerNow Remote Scanner detects these vulnerabilities. Use SanerNow and keep your systems updated and secure.