Introduction of proxyshell vulnerability (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207)

Introducing the exploit

Proxy Shell A general term for 3 Exchange Server vulnerabilities, with the identifiers:

CVE-2021-34473: Microsoft Exchange Server Remote Code Execution

CVE-2021-34523: Microsoft Exchange Server Elevation of Privilege

CVE-2021-31207: Microsoft Exchange Server Security Feature Bypass Vulnerability

Vulnerable platform: Microsoft Exchange servers

Exchange 2013 CU23 < 15.0.1497.15

Exchange 2016 CU19 < 15.1.2176.12, Exchange 2016 CU20 < 15.1.2242.5

Exchange 2019 CU8 < 15.2.792.13, Exchange 2019 CU9 < 15.2.858.9

The severity of vulnerability:

CVE-2021-34473: 9.8

CVE-2021-34523: 9.8

CVE-2021-31207: 7.2

Introduction

The mentioned vulnerabilities reside in the Microsoft Client Access Service (CAS), which typically runs on port 443 in IIS (Microsoft Web Server). CAS is usually exposed to the public Internet so that users can access their email via mobile phones and browsers. This allows attackers to widely exploit the vulnerabilities to deploy webshells to execute remote code on vulnerable systems. ProxyShell refers to a chain of proposed vulnerabilities used to gain remote pre-authenticated access (RCE).

Vulnerability details

Vulnerability CVE-2021-34473 (the pre-auth path confusion)

The first proxyshell vulnerability is similar to the SSRF attack in the ProxyLogon vulnerability. (proxylogon vulnerability link)

This vulnerability allows an attacker to send requests to a vulnerable server with forged signatures that are recognized as authentic by said server.

MS Exchange has a feature called Explicit Logon that legally allows users to open that user’s email or calendar in a new browser window by entering a user’s email address in a URL. This feature is only designed to provide access where the user has Full Access and the target email or calendar is configured to publish. The aforementioned vulnerability, by using the normalization process in sending the Autodiscover/Autodiscover.json string in the URL, causes the arbitrary URL that is sent to the backend to have the same access as the exchange system; In fact, in this vulnerability, Exchange does not perform sufficient checks on the entered address and through its normalization process, it results in granting access to backend URLs as NT AUTHORITY/SYSTEM.

Examples of requests that can be sent by an attacker:

Vulnerability CVE-2021-34523 (Elevation of Privilege on Exchange PowerShell Backend)

 

The Exchange PowerShell Remoting feature built into Microsoft Exchange is designed to help administrative activities through the command line. The previous exploit allowed the attacker to communicate with arbitrary backend URLs as NT AUTHORITY/SYSTEM, but since the attacker does not have mail on the target server, he cannot directly communicate with the PowerShell backend (/Powershell) with elevated access level.

The PowerShell backend checks the X-CommonAccessToken header in incoming requests. If there is no header, another method is used to get the CommonAccessToken. This method checks the X-Rps-CAT parameter in the received request and, if present, converts it to a valid CommonAccessToken. With previously collected information about the target email or default information from internal emails, sending a valid X-Rps-CAT value is not required.

The following request allows the impersonation of a valid user using the X-Rps-CAT parameter:

POST /autodiscover/autodiscover.json?a=abcde@evil.com/PowerShell/?X-Rps-CAT=[Base64 encoded data]

 

Vulnerability CVE-2021-31207 (Post-auth Arbitrary-File-Write Leads to RCE)

If the previous two vulnerabilities are successfully exploited, CVE-2021-31207 allows an attacker to write to a file on the target system.

As an example, in the following command, you can use the New-MailBoxExportRequest command to export the payload in the target system:

Security patch

CVE-2021-31207:

CVE-2021-34473, CVE-2021-34523:

∗ Security recommendation: If an organization is not able to patch the mentioned vulnerabilities immediately, it is necessary to block incoming TCP/80 and TCP/443 traffic to Exchange servers from the Internet or define an internal vpn for the relevant ports.

Reference link:[1]