Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

  1. Kemp Support
  2. Knowledge Base
  3. Security

Zero-day RCE vulnerability on Microsoft Exchange Servers (CVE-2022-41040 & CVE-2022-41082)

Updated: 

 

Information

 

Summary: It was recently reported by Microsoft and other outlets that a Zero-day vulnerability on Exchange Servers 2013, 2016, and 2019 has been exploited by malicious threat actors. This is a rapidly evolving exploit, but here is the latest information and guidance available.
Environment:

Product:  Any

Version: Any

Platform: Any

Application: Microsoft Exchange 2013, 2016, and 2019
Question/Problem Description:

This Exchange Server exploit allows malicious threat actors to gain remote access to internal systems by performing Remote Code Execution (RCE) on the compromised system using PowerShell.
Steps to Reproduce:  
Error Message:  
Defect Number:  
Enhancement Number:  
Cause: The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker.
Resolution:

Microsoft has provided some mitigations via the Microsoft Security Response Center Blog post below. It involves creating a URL Rewrite block rule on the Exchange server via IIS Manager under the Autodiscover virtual directory to block the specific PowerShell URL syntax used for gaining remote access over Autodiscover. This can also be achieved on the LoadMaster. Please see the Workaround section below.

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Workaround:

Alternatively, the URL Rewrite block rule can be created as a Content Rule on the LoadMaster and applied to the Exchange Virtual Service. Here are some steps on how to achieve this on the LoadMaster:

  1. Navigate to Rules & Checking > Content Rules > Create New.
  2. For the syntax of this Content Rule, please see below: mceclip0.pngMatch String Syntax:    /(?=.*autodiscover)(?=.*powershell)/              
  3. Create this rule as per step 2 above, and then navigate to and click Modify on the Exchange Virtual Service on the LoadMaster. This rule should be applied on the parent Virtual Service level to apply to all relevant Exchange Sub Virtual Service directories (Autodiscover, API, PowerShell etc).
  4. Go to Advanced Properties on the parent Virtual Service level, then go to HTTP Selection Rules and click on Show Selection Rules. Here, add the "Zero_day_block" Content Rule that was created in step 2 above. This would be the result once the rule has been added successfully:mceclip1.png
  5. Click Back to return to the Advanced Properties section and go to Not Available Redirection Handling. Here, set the Error code as "403" and enter an Error Message such as "Blocked Access". Please see the attached screenshot below as an example of this configuration:mceclip2.png
  6. With these steps in place, now attempt to navigate to the Fully Qualified Domain Name (FQDN) of the Exchange Virtual Service using the blocked string syntax. As a result, a 403 Forbidden response should be returned with the "Blocked Access" error message in the web browser. Example malicious FQDN: https://mail.domain.com/autodiscover.json@Powershell
Notes:

Microsoft Security Response Center blog post:

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Additional Content Rules Information:

https://support.kemptechnologies.com/hc/en-us/articles/6600356067341-Content-Rules

Regex101 for building and testing PCRE Content Rules:

https://regex101.com/
Was this article helpful?
0 out of 1 found this helpful

Comments

Avatar

Ty cook

Hi,

Is it recommended we change our rule to 

.*autodiscover\.json.*Powershell.*

per the other blogs such as: Microsoft Exchange server zero-day mitigation can be bypassed (bleepingcomputer.com) ?

Thank you for the great article.

0
Avatar

Jake Whelan

Hello Ty,

Thank you for the feedback.

I have made the recommended changes to this article to reflect the new URL string, designed to cover a wider range of attack possibilities.

Best regards,

Jake

0
Avatar

Norbert Fehlauer

Hi,

how to implement the latest changes into this rule?

MS writes: Change the Condition input from {URL} to {UrlDecode:{REQUEST_URI}} and then click OK. 

Can you please advice?

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

0
Avatar

Jake Whelan

Hi Norbert,

The Condition input recommendation would only be relevant to Microsoft's mitigation on the Exchange/IIS server side. On the LoadMaster side, the Content Rule syntax would not change as a result. The latest recommended String syntax is:  /.*autodiscover\.json.*Powershell.*/

Best regards,

Jake

1
Avatar

Norbert Fehlauer

Hi Jake,

thanks for the info.

regards

Norbert

0
Avatar

Jan Haferlach

Hello,

MS changed the pattern again to: (?=.*autodiscover)(?=.*powershell)

Do we have to change it on KEMP? Is it possible to use this pattern?

Best regards

Jan

1
Avatar

Jake Whelan

Hi Jan,

Thank you for bringing this to our attention.

I have now updated this article to reflect Microsoft's recommended changes. The new string can be modified on the LoadMaster Content Rule to match the following:

/(?=.*autodiscover)(?=.*powershell)/

Best regards,

Jake

 

1
In this document