Ross Mitchell 7 October, 2022

Exchange Zero Day - CVE-2022-41040 and CVE-2022-41082

Background

Microsoft Exchange is one of the most popular enterprise email products and runs on Windows Server operating systems. In August 2022, researchers at GTSC discovered a flaw in Exchange which allows attackers to obtain remote code execution on affected systems. Critically, this vulnerability affects fully patched Exchange Servers which renders this exploit as a zero-day vulnerability. These vulnerabilities have recently been confirmed by Microsoft as CVE-2022-41040 and CVE-2022-41082.

Attack Details

Fundamentally, it was found that the exploit is executed by attackers masquerading themselves as an Exchange EWS (Exchange Web Services) which allows them to construct a backdoor and subsequently gain a foothold on to the underlying system. The initial attack uses SSRF (Server-Side Request Forgery) to access the backend server, which is identified as CVE-2022-41040. The SSRF attack is executed by a specially crafted request to the Autodiscover service, similar in format to that of the well-known ProxyShell vulnerability:

autodiscover/[email protected]/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%[email protected]

A successful SSRF attack then allows an attacker to remotely trigger the RCE (Remote Code Execution) attack, labelled as CVE-2022-41082, when PowerShell is available to an attacker and from an authenticated position to the system.

Following an attack, it has been reported that the IIS logs in an affected system contained requests in the same format as the previously mentioned ProxyShell vulnerability which exists in the Client Access services. However, it was noted the affected systems in the case described, were patched against this vulnerability.

Mitigation

According to Microsoft (updated 30/09/22), no action is needed for users using Microsoft Exchange Online/Office 365. However Microsoft have produced an interim measure for on premises Exchange deployments, where administrators can mitigate against the attack by adding a URL rewrite rule in the associated IIS Server. In addition, PowerShell access for non-administrators should be disabled.

The steps to apply the URL rewrite rule include:

  1. Open the IIS Manager. 
  2. Expand the Default Web Site. 
  3. Select Autodiscover. 
  4. In the Feature View, click URL Rewrite.

Figure 1: Autodiscover URL Rewrite setting
Figure 1: Autodiscover URL Rewrite setting
  1. In the “Actions” pane on the right, click “Add Rules”.

Figure 2: Add Rule(s)
Figure 2: Add Rule(s)
  1. Select “Request blocking” and then confirm OK

Figure 3: Add Rule(s) dialogue box
Figure 3: Add Rule(s) dialogue box
  1. Add string .*autodiscover\.json.*\@.*Powershell.* to Pattern and click OK.

Figure 4: Request blocking pattern
Figure 4: Request blocking pattern
  1. Expand the rule and select the rule with the Pattern: .*autodiscover\.json.*\@.*Powershell.* and click Edit under Conditions.

Figure 5: Editing the condition
Figure 5: Editing the condition
  1. Change the condition input from {URL} to {REQUEST_URI}

Figure 6: Condition input
Figure 6: Condition input

Checking For Compromise

Microsoft is aware of limited targeted attacks using these two vulnerabilities. However, an initial check for any indicators of compromise using the PowerShell command below can be used to scan the IIS logs and therefore determine if further investigation is warranted.

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

Improve your security

Our experienced team will identify and address your most critical information security concerns.

Contact us About Cyberis