New 0-day vulnerabilities in Microsoft Exchange Server actively exploited

Two reported 0-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019 (on-prem) tracked as CVE-2022-41040 and CVE-2022-41082 are being actively exploited in the wild. Conscia Threat Intelligence experts (NIL is part of Conscia Group) explain how critical these are and how to mitigate them.

How to mitigate Microsoft Exchange Server 0-day vulnerabilities CVE-2022-41040 and CVE-2022-41082

On 29^th September 2022, Microsoft published new Customer Guidance for two reported 0-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019 (only on-premises deployments). Tracked as CVE-2022-41040 Server-Side Request Forgery (SSRF) and CVE-2022-41082 Remote Code Execution (RCE), both vulnerabilities are being actively exploited in the wild. Microsoft confirmed that SSRF can only be exploited by authenticated attackers – only then is it possible to exploit the RCE vulnerability.

Upon publishing this article, we already found one public report of a successful cyber-attack based on these vulnerabilities by the Chinese Threat Actor group that deployed Chinese Chopper web shells for persistence and data theft and to move laterally through victims’ networks.

Vulnerabilities only affect on-premises deployments, while Microsoft Exchange Online customers do not need to take any action.

Who is affected, and how do they work

Two 0-day vulnerabilities are tracked as:

• CVE-2022-41040 (Server-Side Request Forgery)
• CVE-2022-41082 (Remote Code Execution)

 The SSRF can only be exploited by authenticated attackers and is a prerequisite for successful exploitation of RCE vulnerability. The SSRF vulnerability is exploited similarly to those used in attacks targeting the ProxyShell vulnerabilities.

The exploit works in two stages:

• Requests with a similar format to the ProxyShell vulnerability: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com.
• The use of the link above to access a component in the backend where the RCE could be implemented.

The vulnerabilities affect on-premises deployments of Microsoft Exchange Server 2013, 2016, and 2019.

NIL (part of Conscia Group) Cyberdefense Guidelines

We currently recommend our customers to follow the mitigations suggested by Microsoft in their Customer guidance report.

Microsoft Exchange Online Customers do not need to take any action. On-premises Microsoft Exchange customers should review and apply the following URL Rewrite Instructions and block exposed Remote PowerShell ports.

The current mitigation is to add a blocking rule in “IIS Manager -> Default Web Site -> Autodiscover -> URL Rewrite -> Actions” to block the known attack patterns.

Microsoft has confirmed that the following URL Rewrite Instructions, which are currently being discussed publicly, successfully break current attack chains.

1. Open the IIS Manager.
2. Expand the Default Web Site.
3. Select Autodiscover.
4. In the Feature View, click URL Rewrite.
5. In the Actions pane on the right-hand side, click Add Rules.
6. Select ‘Request Blocking’ and click ‘OK.’
7. Add String “.*autodiscover\.json.*\.*Powershell.*” (excluding quotes) and click ‘OK’.*
8. Expand the rule and select the rule with the Pattern “*autodiscover\.json.*\@.*Powershell.*” and click ‘Edit’ under ‘Conditions.’
9. Change the condition input from {URL} to {REQUEST_URL}

*[04.10.2022] UPDATE: According to further analysis, the ‘@’ sign in the 7th step proved to be too specific, since it focuses on the known attacks. Removing it should make the rule more prone to other attacks. However, we at Conscia have not been able to test it yet whether it would have any implications on normal operations.

*[05.10.2022] UPDATE: Removed the ‘@’ sign in the 7th step.

There is no known impact on Exchange functionality if the URL Rewrite module is installed as recommended.

Authenticated attackers who can access PowerShell Remoting on vulnerable Exchange systems will be able to trigger RCE using CVE-2022-41082. Blocking the ports used for Remote PowerShell can limit these attacks.

• HTTP: 5985
• HTTPS: 5986

1. Using Exchange Emergency Mitigation Service
2. Using provided PowerShell Script