SafeBreach Coverage for #ProxyNotShell Vulnerabilities CVE-2022-41040 and CVE-2022-41082

In early August 2022, researchers from a cybersecurity company GTSC discovered and reported an attack campaign that leveraged a new 0-day Remote Code Execution (RCE) vulnerability on Microsoft Exchange Server. This 0-day was very similar to previous ProxyShell vulnerabilities (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207). Microsoft Security further investigated this report and their research revealed that this vulnerability (CVE-2022-41040) could be used gain privileged access and could be chained to another Exchange vulnerability (CVE-2022-41082) to perform remote code execution via PowerShell. This enabled the attacker to remotely install the Chopper web shell on the server.

Additionally, the research also revealed that while these vulnerabilities did need authentication to gain access, they could do so by stealing the credentials of a standard user. CVE-2022-41040 which has been tagged critical is a server-side request forgery (SSRF) vulnerability, while CVE-2022-41082 (tagged as important) allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker. As this attack is targeted against Microsoft Exchange Mailbox server, the attacker can potentially gain access to other resources via lateral movement into Exchange and Active Directory environments.

Mitigation Guidance Provided by Microsoft

While Microsoft has not yet released a patch for these vulnerabilities, they have provided detailed mitigation guidance in their blog post. Highlights of this mitigation include –

• Exchange Server customers should complete both the URL Rewrite rule mitigation for CVE-2022-41040 and the Disable remote PowerShell for non-admins mitigation for CVE-2022-41082.
  • URL Rewrite Rule – Microsoft asks exchange administrators to create a rule that would block URLs that match the following pattern- .*autodiscover\.json.*Powershell.*. This will prevent known variants of the #ProxyNotShell attacks.  Additionally, it was also advised that the Condition Input should be changed from {URL} to {UrlDecode:{REQUEST_URI}} to ensure all encoded variations are evaluated before being blocked.
  • Disable remote PowerShell – customers should disable remote PowerShell access for non-admin users in your organization.
  • 3^rd Party Web Application Protection – Exchange Administrators who use third-party Web Application Firewall (WAF) products can implement the recommended URL filters and blocks as part of their WAF policy.
  • Exchange Administrators can limit the outgoing connection from the Exchange Mailbox server using a specific allowed list on an outgoing proxy to limit suspicious web requests.
• It is important to note that Microsoft Exchange Online has detections and mitigations to protect customers and current Microsoft Exchange Customers do not need to take any action.

Important Note for SafeBreach Customers – Coverage for CVE-2022-41040 and CVE-2022-41082

The SafeBreach Labs and the SafeBreach product team have updated Breach Method #6577- Remote exploitation of Microsoft Exchange ProxyShell (CVE-2021-34523) to incorporate coverage for #ProxyNotShell vulnerabilities CVE-2022-41040 and CVE-2022-41082. The overall goal of this breach method is to determine whether it is possible to execute arbitrary code on the Microsoft Exchange Server. The breach method replicates the following RCE actions –

• The attack simulator sends malicious HTTPS GET that would trigger the elevation of privilege on the Exchange PowerShell backend for exploiting the CVE-2021-34523 vulnerability.
• The attack simulator sends malicious HTTPS GET that would trigger remote code execution on the Exchange PowerShell backend for exploiting CVE-2022-41082 & CVE-2022-41040 vulnerabilities.

SafeBreach also recommends the following additional mitigations to ensure protection against the #ProxyNotShell vulnerabilities –

• Harden Intrusion Prevention Systems’ Security Configuration – Ensure network Intrusion Prevention System (IPS) is deployed on the network and configured with a policy to block known attack signatures. E.g., Apply a policy on the inspected traffic and set critical and high-confidence attack signatures to block and prevent the payload over the network. IPS signatures update policy should be set to update as promptly as possible and in accordance with the requirements set by the business.
• Enforce Inspection of Encrypted Traffic Flows – Identify encrypted traffic inspected by the network IPS and determine if the risk of having the encrypted traffic left uninspected is acceptable or if it should be inspected to identify malicious payloads, traffic anomalies, and known attack signatures. Encrypted traffic can be inspected by installing the private keys used for the creation of the SSL\TLS communication or by implementing SSL offload and inspecting the clear traffic. The IPS vendor may suggest additional product-specific approaches to inspect encrypted traffic.
• Web Application Firewall – If applicable, implement and configure a Web Application Firewall to inspect the traffic and apply a policy to block malicious payload.

If you are a SafeBreach customer and would like assistance with protecting your enterprise against #ProxyNotShell vulnerabilities, please contact your customer success manager.  If you would like to gain insight into your security control performance so you can configure wisely, protect more, and risk less, please contact us.