Two Zero-Day RCE Vulnerabilities in Microsoft Exchange

UPDATE 10/5/2022 @ 8AM

Microsoft has released updated mitigation guidance for this vulnerability, which is officially known as ProxyNotShell, because the initial mitigation could be easily bypassed to exploit the vulnerabilities. The updated mitigation steps are below:

• Open IIS Manager
• Select Default Web Site
• In the Feature View, click URL Rewrite
• In the Actions pane on the right-hand side, click Add Rule(s)…
• Select Request Blocking and click OK
• Add the string “.*autodiscover.json.*Powershell.*” (excluding quotes)
• Select Regular Expression under Using
• Select Abort Request under 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 the Condition input from {URL} to {REQUEST_URI}

Microsoft has also provided Exchnage Mitigation tools in the form of pre-made PowerShell scripts that are available here: https://microsoft.github.io/CSS-Exchange/Security/EOMTv2/

There are still no patches available, so it is recommended that you update your mitigation to the above strings until the patches become available.

UPDATE 9/30/22 @ 9AM ET

Since our initial publication, Microsoft has publicly acknowledged these two vulnerabilities, assigned CVEs, and provided further details about the types of vulnerabilities. Most importantly, we are lowering the severity of this event from a 10 to an 8 because Microsoft has confirmed that an attacker would need to have authentication to successfully execute remote code on an on-premises Exchange server.

The first vulnerability is being tracked as CVE-2022-41040 and is a Server-Side Request Forgery. The second vulnerability is being tracked as CVE-2022-41082 and is a Remote Code Execution (RCE) vulnerability when PowerShell is accessible to the attacker. Microsoft has confirmed that the two vulnerabilities are stringed together as we initially published. An authenticated attacker uses the Server-Side Request Forgery to enable the arbitrary remote code execution through PowerShell.

Microsoft has confirmed that it will be accelerating the timeline to push a fix and urges on-premises Exchange customers to apply the mitigation below immediately as a temporary fix until the patches are available.

We have also identified YARA Rules that you can use to detect exploitation attempts in your environment if you are running YARA or a tool that can accept YARA rules.

https://github.com/Neo23x0/signature-base/blob/master/yara/expl_proxyshell.yar

ID: D3-2022-0007-1

Severity: 8 (HIGH)

Published: September 29th, 2022

EXECUTIVE SUMMARY

Vietnamese MSSP by the name of GTSC posted a blog article that they had detected exploit requests in a client’s IIS web server logs. Further investigation revealed that the attacker was able to execute commands on the server after exploitation. Additionally, Security Researcher Kevin Beaumont has confirmed that, “significant numbers of Exchange servers have been backdoored – including a honeypot.” GTSC identified these vulnerabilities three weeks ago and reported them, responsibly, to Microsoft so they could develop patches.

At the time of initial publication of this D3, there are no published CVEs for these vulnerabilities, no patches, and no publicly available proof of concept code. There is a manual mitigation for the vulnerability available below, which should be implemented on all Exchange servers immediately until Microsoft releases patches.

Dataprise is aware of the critical nature of this vulnerability and has completed a review of all available analysis of these vulnerabilities and the potential impact to our clients. This has been a major exercise as the investigation requires that a specific order of actions is taken to achieve the response objectives.  Right now, our teams are working to confirm whether the recommended mitigation steps can be applied without causing any customer-facing service interruptions.

If your organization’s Exchange Server is covered under a Dataprise Managed Service agreement, we will send a follow-up communication with details on our mitigation efforts.

Additionally, the Dataprise Cybersecurity team has implemented detection rules in our SIEM to identify any attempts to exploit any Microsoft Exchange servers that are being monitored by our SOC under a Managed Security Services plan.

IMPACT

The exploitation of these vulnerabilities can allow an attacker to execute remote code on the Exchange server which could lead to full compromise of the server and all data therein.

DETAILED ANALYSIS

Analysis shows that attackers are chaining two zero-day vulnerabilities together to deploy Chinese Chopper webshells on exploited Exchange servers. Based on the web shells’ code page, which is a Microsoft character encoding for simplified Chinese, it is suspected that a Chinese group is responsible for the attacks. Attribution for these types of exploits and code is difficult and may change once more is known about the attack and its origins.

GTSC’s Red Team has identified the following Webshell paths, that if present, indicates that the server has been exploited and compromised.

• C:ProgramFilesMicrosoftExchange ServerV15FrontEndHttpProxyowaauthRedirSuiteServiceProxy.aspx
• C:inetpubwwwrootaspnet_clientXml.ashx
• C:ProgramFilesMicrosoftExchange ServerV15FrontEndHttpProxyowaauthpxh4HG1v.ashx

GTSC’s Blue Team notes that the format used in the Webshell exploit is the same format used by the ProxyShell exploit.

autodiscover/autodiscover.json?

@evil.com/&Email=autodiscover/autodiscover.json%[email protected]

Exchange administrators can use the PowerShell command below to check for exploitation on their servers in the IIS logs.

Get-ChildItem -Recurse -Path -Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover.json.*@.*200

GTSC submitted the vulnerabilities to Microsoft privately three weeks ago through the Zero Day Initiative, which is tracking these two vulnerabilities as ZDI-CAN-18333 and ZDI-CAN-18802 once they were verified. The two vulnerabilities have CVSS scores of 8.8 and 6.3.

MITIGATION STEPS

Since Microsoft has not yet released security updates to address the two zero-days, GTSC shared a temporary mitigation that will block attack attempts by adding a new IIS server rule using the URL Rewrite Rule module:

1. In Autodiscover at FrontEnd, select tab URL Rewrite, and then Request Blocking.
2. Add string “.*autodiscover.json.*@.*Powershell.*“ to the URL Path.
3. Condition input: Choose {REQUEST_URI}

GTSC adds, “We recommend all organizations/enterprises around the world that are using Microsoft Exchange Server to check, review, and apply the above temporary remedy as soon as possible to avoid potential serious damages.”

SOURCES

• https://thehackernews.com/2022/09/microsoft-confirms-2-new-exchange-zero.html
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41040
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41082
• https://www.bleepingcomputer.com/news/security/new-microsoft-exchange-zero-day-actively-exploited-in-attacks/
• https://twitter.com/GossiTheDog/status/1425851771553992709
• https://www.huntress.com/blog/new-0-day-vulnerabilities-found-in-microsoft-exchange
• https://www.zerodayinitiative.com/advisories/upcoming/

CONTRIBUTING AUTHORS

• Stephen Jones, Vice President Cybersecurity