ProxyShell or ProxyNotShell? Let’s Set The Record Straight

Before diving into ProxyNotShell, we will start by giving some context regarding the original ProxyShell vulnerabilities.

On BlackHat USA 2021, Orange Tsai (a 0-day researcher focusing on web/application security) revealed the three CVEs affecting Microsoft Exchange that chained together can result in arbitrary code execution on the server. They dubbed these vulnerabilities ProxyShell.

CVE-2021-34473 – Pre-auth Path Confusion leads to ACL Bypass 

CVE-2021-34523 – Elevation of Privilege on Exchange PowerShell Backend 

CVE-2021-31207 – Post-auth Arbitrary-File-Write leads to RCE

In the ProxyShell attack, ​​an unauthenticated attacker can execute arbitrary commands on on-premises Microsoft Exchange Server versions 2013, 2016 and 2019 through an exposed 443 port.

Even though Microsoft released security updates for the affected Exchange Servers versions 2013, 2016, and 2019 Active exploitation attempts were soon identified targeting affected servers that did not apply the patch yet.

A year later, at the beginning of August 2022, a Security Operations Center (SOC) team from the cybersecurity company GTSC found an attack on their Microsoft Exchange servers which, upon initial investigation, was presumed to be a zero-day. 

During the investigation, they found requests in the logs that use the same format as ProxyShell requests and can allow the attacker to execute commands on the victim… interesting… sounds like ProxyShell?

Well, after additional research was conducted, it turned out that the released patch of ProxyShell did not properly fix the issues, and the 2022 vulnerabilities now dubbed ProxyNotShell came from bypassing the unfixed patch.

What is ProxyShell?

As mentioned above, ProxyShell are three different CVEs, affecting Microsoft Exchange servers versions: 2013, 2016, and 2019, that can be chained together to perform a Remote Code Execution attack from an unauthenticated user.

The ProxyShell vulnerabilities were classified by Microsoft as critical vulnerabilities for a few reasons.

1. Every Remote Code Execution gets a high score.
2. The vulnerabilities are relatively easy to exploit.
3. The exploitation flow was explained in detail by the researchers in the 2021 Black Hat USA conference.

We’ll briefly explain each one of the ProxyShell vulnerabilities in more detail.

CVE-2021-34473

Path confusion bug on the Microsoft Exchange Explicit Logon feature.

Explicit Logon feature is a legitimate feature that enables users to open a new browser window of mailbox/calendar only under these conditions:

1. The user’s permissions are required to be ‘Full Access’.
2. The mailbox or calendar is configured to publish.

When opening the new window, the Exchange Backend server reads the URI and parses it for receiving the mailbox address.

In order to exploit this vulnerability, the attacker just needs to replace the mailbox address with the following string: /autodiscover/autodiscover.json

When the Exchange Backend server reads this string, it does not perform the checks on the address like usual, the string leads the server to access all backend URLs with the NT AUTHORITY/SYSTEM permissions.

CVE-2021-34523 

Downgrade Privilege on Exchange in order to access the PowerShell backend.

After achieving access to all Exchange Backend server URLs with the NT AUTHORITY/SYSTEM, the next step is to find a way to execute commands. 

Microsoft Exchange has a built-in feature called PowerShell Remoting aimed to assist with administrative activities and enable the automation of Exchange tasks.

However, the NT AUTHORITY/SYSTEM user does not have a mailbox and can not access the PowerShell command line interface, so the attacker needs to change his privilege level.

When the PowerShell backend receives requests it checks the X-CommonAccessToken. 

If the header does not exist, it uses another method that checks the CommonAccessToken in the X-Rps-CAT parameter.

So, the attacker just needs to pass the X-Rps-CAT with the information he collected from the victim mailbox or from the default information from built-in mailboxes (to which he has access).

This is how the attacker can downgrade his NT AUTHORITY/SYSTEM privileges to Exchange Admin. 

CVE-2021-31207

Export user’s mailbox to receive Remote Code Execution

At this point when the attacker has access to the PowerShell with the Exchange Admin, he just needs to make sure that the required ‘Import Export Mailbox’ role is set to the impersonated user.

If the role is not set, the attacker will need to execute the New-ManagementRoleAssignment cmdlet.

Then, the attacker needs to use the PowerShell command New-MailboxExportRequest in order to export the user’s mailbox to a specific desired path.

Payload Delivery

In order to create a WebShell on the Microsoft Exchange server when exporting the user’s mailbox, the attacker needs to deliver the payload via SMTP.

However, when the payload arrives, it is encoded. 

So when sending the payload, the attacker needs to write the decoder in it and decode it. 

The Full Exploitation Flow

1.Send an email with the encoded WebShell payload via SMTP.

2. Launch PowerShell with a privileged PowerShell admin user.

• Path confusion to receive the NT AUTHORITY/SYSTEM privileges and access all Exchange Backend server URLs (CVE-2021-34473).
• Set the X-Rps-CAT parameter with the Exchange admin access token (CVE-2021-34523).

3. Execute commands inside the PowerShell session (CVE-2021-31207).

• New-ManagementRoleAssignment to set the ‘Import Export Mailbox’ role to the impersonated user.
• New-MailboxExportRequest to export the user’s mailbox to a specific desired path.

4. Execute commands on the shell.

ProxyNotShell

ProxyNotShell is identified with the following CVEs: CVE-2022–41040 and CVE-2022–41082.

The vulnerabilities affect Microsoft Exchange on premises, with an Outlook Web App facing the internet. 

In early August 2022, a SOC team from the cybersecurity company GTSC found an attack on their Microsoft Exchange servers. An investigation by the blue team led to the submission of two vulnerabilities to the Zero Day Initiative (ZDI) which verified and acknowledged the two issues.

During the investigation they found requests in the logs that use the same format as ProxyShell requests and can allow the attacker to execute commands on the victim machine:

The requests look exactly the same as the requests from proxyShell

GTSC did not associate the vulnerabilities to ProxyShell due to the fact that all victim servers were patched and had the latest updates, meaning they should also be patched for ProxyShell.

CVE-2022-41040 and CVE-2022-41082

The vulnerabilities affect Microsoft Exchange server versions 2013, 2016, and 2019.

CVE-2022-41040 is a server-side request forgery (SSRF) vulnerability.

SSRF is a web vulnerability that allows an attacker to control the server-side application to send requests to unintended locations.

CVE-2022-41082 is a remote code execution (RCE) when Exchange PowerShell is accessible to the attacker.

CVE-2022-41040 can enable an authenticated attacker to trigger CVE-2022-41082 (can also be used separately).

Attack Surface

Currently, there are over 200,000 publicly facing Exchange servers with an exposed Outlook Web App According to Shodan.io, which means that the potential attack surface for these vulnerabilities is significant.

Source: shodan.io

Affected Systems

On-premises Microsoft Exchange Server versions 2013, 2016 and 2019

Remediation

There is currently no remediation available.

The Mitigation Journey

September 30th

On September 30th Microsoft released a blog post revealing information about the new vulnerabilities.

Microsoft mitigations were:

• Add a blocking rule in “IIS Manager -> Default Web Site -> Autodiscover -> URL Rewrite -> Actions” to block the known attack patterns.
• Blocking the ports used for Remote PowerShell can limit these attacks:

HTTP: 5985 

HTTPS: 5986 

October 1st

On October 1st, Microsoft removed the SECOND recommended mitigation (ports used for Remote PowerShell).

The reason Microsoft decided to remove this mitigation was that researchers were able to show that this mitigation strategy is too specific and does not cover all the attack exploit methods.

October 3rd

On October 3rd, Microsoft added the following mitigation:

• We strongly recommend Exchange Server customers to disable remote PowerShell access for non-admin users in your organization.

October 6th

On October 6th, Microsoft recommended to do both- URL Rewrite rule mitigation and the Disable remote PowerShell for non-admins mitigation.

Next Steps

As can be seen above, since the vulnerabilities came out, Microsoft is constantly updating their mitigation recommendations. We recommend staying up to date with the latest guidance from Microsoft in their security updates page.

However, keep in mind that even the latest recommendation might not be 100% bullet proof as attackers keep trying to come up with payloads that bypass them.

It is advised to keep an eye out for any suspicious activity (any Exchange servers with unknown processes under IIS, and any Exchange servers with PowerShell Remoting processes) and make sure to update your organization’s Exchange servers as soon as a patch is released.