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

Alt text

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

Alt text

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

Alt text

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.