ProxyShell Exploitation Analysis 1 - CVE-2021-34473

Onedaysec
4 min read
2 views
docx image 1770017255072 0 59708678a5

0x00 Preface

---

Orange introduced the Microsoft Exchange attack chain used in Pwn2Own 2021 during this year's BlackHat presentation. His content provided me with great inspiration.

This article only records the details of my research on ProxyShell and analyzes exploitation ideas from a technical research perspective.

0x01 Introduction

---

This article will cover the following:

  • Setting up the debugging environment
  • Vulnerability analysis
  • Exploitation ideas

0x02 Setting up the debugging environment

---

1. Disable debugging optimization in Visual Studio

Set the environment variable COMPLUS_ZapDisable=1

Restart the system

2. View the corresponding processes in Exchange

Execute the command:

C:\Windows\System32\inetsrv\appcmd list wp

All Exchange processes and their corresponding PIDs can be obtained, as shown in the figure below

2. View the corresponding processes in Exchange — technical illustration 1

3. Debug using dnSpy

Open the relevant DLL file, set breakpoints at the desired debugging locations, and select Attach Process to begin debugging

If unsure about the Exchange process to debug, select all w3wp.exe

0x03 Vulnerability Debugging

---

Open the file C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\bin\Microsoft.Exchange.FrontEndHttpProxy.dll using dnSpy

Navigate sequentially to Microsoft.Exchange.Clients.Owa.Core -> Microsoft.Exchange.HttpProxy

For the vulnerability principle of the SSRF vulnerability (CVE-2021-34473), refer to the following article:

https://peterjson.medium.com/reproducing-the-proxyshell-pwn2own-exploit-49743a4ea9a1

0x04 Vulnerability Analysis

---

1. Determine if the vulnerability exists

Using the method provided in Orange's original text:

Access: https:///autodiscover/[email protected]/mapi/nspi/?&Email=autodiscover/autodiscover.json%[email protected]

If the vulnerability exists, the following result is returned:

As shown in the figure below

1. Determine if the vulnerability exists — technical illustration 2

Privileges are System

The "/mapi/nspi" in the URL is the final address accessed by the Exchange server

The "?&Email=autodiscover/autodiscover.json%[email protected]" in the URL serves as a parameter to meet the vulnerability trigger conditions. The same effect can also be achieved by setting the Cookie content to "Email=Autodiscover/autodiscover.json%[email protected]", as shown in the source code below

1. Determine if the vulnerability exists — technical illustration 3

2. Invoke Exchange Web Service (EWS) via SSRF vulnerability

Exchange Web Service (EWS) corresponds to the email content of mailbox users. For usage of EWS, refer to the previous article "Exchange Web Service (EWS) Development Guide 2 – SOAP XML message". By sending XML requests, the email content of corresponding users can be obtained

Since the default privilege of SSRF is System, we need to find a method to impersonate any mailbox user in order to read the email content of corresponding users

After a period of debugging, I did not find a method to specify the EWS authentication user via parameters. However, here we can use a technique from the Exchange privilege escalation vulnerability (CVE-2018-8581). By utilizing SerializedSecurityContext in the Header and specifying the SID, identity impersonation can be achieved, allowing EWS calls to be made as the specified user.

Code location:

https://github.com/thezdi/PoC/blob/master/CVE-2018-8581/serverHTTP_relayNTLM.py#L48-L64

Header format is as follows:





'''+VICTIM_SID+'''


'''+VICTIM_SID+'''








To obtain the user's SID, we can use the technique from the Exchange SSRF vulnerability (CVE-2021-26855). By accessing /autodiscover/autodiscover.xml to get the legacyDn, and then using it as a parameter to access /mapi/emsmdb, we can obtain the corresponding SID for the user.

At this point, the entire exploitation chain is complete, with the process as follows:

1. Access /autodiscover/autodiscover.xml to obtain the legacyDn.

2. Access /mapi/emsmdb to obtain the corresponding SID for the user.

3. Use SerializedSecurityContext in the Header to specify the user identity for EWS call operations.

3. Enumerate the mailbox user list.

As mentioned in my previous article 'Penetration Techniques - Methods to Obtain Exchange GlobalAddressList': 'The Exchange GlobalAddressList contains the email addresses of all mailbox users in the Exchange organization. By obtaining the credentials of any mailbox user within the Exchange organization, you can export the email addresses of other mailbox users through the GlobalAddressList.'

This can also be exploited here. We only need to use the FindPeople operation, perform a traversal, and deduplicate the results.

For implementation details, refer to the previously open-sourced script: a certain open-source project.

4. Default mailbox users.

To read the Exchange GlobalAddressList, we need to obtain the credentials of any mailbox user within the Exchange organization. In the context of this vulnerability, we only need the mailbox user name.

The following four default users exist in Exchange and can be used:

  • SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
  • SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
  • SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}(Exchange 2016 CU8 and later)
  • SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}(Exchange 2016 CU8 and later)

Reference:

https://docs.microsoft.com/en-us/exchange/architecture/mailbox-servers/recreate-arbitration-mailboxes?view=exchserver-2019

0x05 Summary

---

CVE-2021-34473, as the foundation of the ProxyShell attack chain, is easy to verify and poses significant risks. From a defensive perspective, it is recommended that users apply patches as soon as possible.

Related Questions & Answers

How can an attacker enumerate all mailbox users in an Exchange organization using this vulnerability?

Once the attacker has impersonated a valid mailbox user via the SSRF and SID technique, they can use the FindPeople operation in EWS to enumerate the GlobalAddressList. This list contains the email addresses of all mailbox users in the Exchange organization. The attacker simply needs to traverse and deduplicate results. The article references open-sourced scripts for implementation, and notes that default system mailboxes (e.g., `SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}`) can be used as the impersonated user since they exist in every Exchange environment.

How can attackers use the SSRF vulnerability to access mailbox data of other users?

After triggering the SSRF, the attacker can call the Exchange Web Service (EWS) to read email content. However, because EWS requires authentication, the attacker leverages a technique from CVE-2018-8581 (privilege escalation) by embedding a `SerializedSecurityContext` in the SOAP header with a target user's SID. This allows the attacker to impersonate any mailbox user. To obtain the SID, the attacker first fetches the user's legacyDn via `/autodiscover/autodiscover.xml`, then queries `/mapi/emsmdb` with that legacyDn to retrieve the SID, as detailed in the [ProxyShell exploitation analysis](/news/proxyshell-exploitation-analysis-1-cve-2021-34473).

What is the core vulnerability in CVE-2021-34473 and how does it function?

CVE-2021-34473 is a Server-Side Request Forgery (SSRF) vulnerability in Microsoft Exchange that serves as the foundation of the [ProxyShell attack chain](/news/proxyshell-exploitation-analysis-1-cve-2021-34473). It allows an unauthenticated attacker to make the Exchange server send requests to internal resources, such as the Exchange Web Service (EWS) or the /mapi/nspi endpoint, by crafting a specially formatted URL to the /autodiscover/autodiscover.json endpoint with a parameter like `Email=autodiscover/autodiscover.json%[email protected]`. The SSRF runs with SYSTEM privileges, enabling further exploitation.

Continue Reading