ProxyShell: Deep Dive into the Exchange Vulnerabilities

ProxyShell is a new attack surface on Microsoft Exchange server discussed back in 2021 Black Hat USA conference [1]. According to Unit 42 analysis [3] by Palo Alto, ProxyShell was used 55% of the time out of the 6 CVEs which were most exploited for Initial Access (Image below). Due to the popularity of Exchange and the fact that attackers are exploiting it the most, CISA has added ProxyShell to the 2021 Top Routinely Exploited Vulnerabilities [2] list.

Exploitation of ProxyShell is easy and it gives the attacker a shell running as Windows NT Authority user. Thus, it is worth to revisit the ProxyShell vulnerability and analyse how the vulnerability works.

Vulnerabilities Involved

ProxyShell works by chaining 3 CVEs which are mentioned below –

CVE-2021-34473 Exchange EwsAutodiscoverProxyRequestHandler SSRF
CVE-2021-34523 Elevation of Privilege on Exchange PowerShell Backend
CVE-2021-31207 Exchange MailboxExportRequest Arbitrary File Write

CVE-2021-34473

This is a server-side request forgery (SSRF) vulnerability that means the attacker can force the vulnerable server to make requests to internal resources on his behalf. No authentication is needed in this case since the requests are made by the endpoints to the backend servers, so trust is already there. The vulnerability occurs due to a path confusion issue where the URI is parsed incorrectly.

To exploit, the URI needs to be of the following format -
/Autodiscover/[email protected]/mapi/nspi/?&Email=Autodiscover/[email protected]
OR
/Autodiscover/[email protected]/mapi/nspi/? with Email=Autodiscover/[email protected] provided as a cookie.

Here /mapi/nspi is the URI that is queried to the backend server and can be replaced by some other URIs which can do a variety of function for us.
This vulnerability enables the attacker to execute the other 2 CVEs by sending their payload to the backend server which normally requires authentication. The requests are made as NT Authority/System user which has the highest privilege in Windows. We will mention this CVE as the SSRF vulnerability in the rest of the blog.

CVE-2021-34523

Using the SSRF vulnerability, we can access the PowerShell remoting agent of Exchange which is available at /PowerShell/. This is a very restrictive PowerShell environments that permits only certain PowerShell cmdlets [4] enabling the automation of Exchange tasks. Although the sent requests use the System user, we can’t use that with this PowerShell endpoint as there is no mailbox belonging to that user. So, we need to be one of the users of Exchange, e.g. Exchange Admin. That is what this CVE-2021-34523 enables us to do. Due to this vulnerability an access token provided as the X-Rps-CAT parameter in the query is deserialized and added as X-CommonAccessToken header in the final request which lets the attacker impersonate that user.

CVE-2021-31207

This vulnerability lets an attacker export mailbox content to a path and extension of their choosing when it should only be letting them export in certain mail extensions. So, an attacker can save a WebShell embedded mail as draft by using the SSRF vulnerability and then export it using the cmdlet New-MailboxExportRequest in .NET formats like Active Server Pages (ASPX) in appropriate directories using this vulnerability and get code executed through that.

Proof Of Concept

There are a bunch of publicly available POCs in GitHub [5] as well as a Metasploit module [6]. Executing them requires a vulnerable environment setup.

Vulnerable Environment Setup

We need an OS which can run any of the vulnerable exchange server. According to Microsoft advisory [7], these are the vulnerable versions
- Microsoft Exchange Server 2019 Cumulative Update 9
- Microsoft Exchange Server 2013 Cumulative Update 23
- Microsoft Exchange Server 2019 Cumulative Update 8
- Microsoft Exchange Server 2016 Cumulative Update 19
- Microsoft Exchange Server 2016 Cumulative Update 20\
We used a Microsoft Windows Server 2016 with Microsoft Exchange Server 2016 Cumulative Update 20 running on top which downloadable from here [8].
You need to have AD Domain setup for installing Exchange. You can find plenty of tutorials online to do the same or follow the tutorial here [9].
Once Exchange is setup, the default configuration should be exploitable.
You need to disable Windows Defender Real time monitoring as Defender has signatures for detecting some of the common web shells used in the vulnerability. But we can’t depend on that since those signatures can be bypassed by attackers. Here is the single PowerShell command to disable Real time monitoring - Set-MpPreference -DisableRealtimeMonitoring $true

Exploitation

We will use the Metasploit module that is available. Metasploit is a framework which comes pre-installed in distros like Kali Linux. It can also be installed in other Linux distros (instructions here [10]).

Here are the steps to exploit using Metasploit.

Launch Metasploit and search for the term ProxyShell. We get a search result as shown below. Interact with the module by entering use 0
If we look at the options for this module, we see that only required parameters are the target server IP (RHOST) and the IP where you want to listen for the reverse shell (LHOST). All the other information is optional and can be enumerated automatically by the module.
After plugging in the values, we hit run and after waiting a bit we see that we got a meterpreter session back and its running as NT Authority\System. NEAT!\

We see that lot of things happened before we got the shell, we will break it down. As, when possible, I will try to replicate the requests sent via the Metasploit module using the curl command for better understanding and visibility.

Breakdown

First the module checks whether the exchange instance is vulnerable to ProxyShell or not. This is detected by checking for the SSRF vulnerability (CVE-2021-34473) where the URL being pinged is /mapi/nspi/. Getting a response like the following image confirms the server being vulnerable to ProxyShell. Also notice user the being used is NT Authority/System as mentioned previously
Next the FQDN of the server can be enumerated by sending a normal request to /rpc/rpcproxy.dll without exploiting any vulnerability as shown below -
Once we have the FQDN, we enumerate a list of email addresses from the backend server using SSRF by querying the endpoint /ews/exchange.asmx with the appropriate payload. We can see in the following image that a few email addresses have been returned.
Using that email address in the payload we send a request to /Autodiscover/autodiscover.json. The response contains the legacy DN (distinguished name) which helps us get the Server ID (SID). The SID with a few other hardcoded values in TLV format when base64 encoded forms the common access token which will be used to impersonate the Exchange Admin user with email [email protected]
Now that we have the access token, this can be used to access the PowerShell backend. Whether the token works or not can be verified by sending the following request. Getting a 200 OK means the token is accepted
Communication with the PowerShell endpoint needs to be done over Windows Remote Management (WinRM), Microsoft’s implementation of WS-Management Protocol (Web Services for Management aka WSMan) which is based on HTTP with SOAP XML messages. There are a few libraries in various programming language which implements this. We have to send the requests to our PowerShell endpoint with the token instead of the default URI used by the library. Following images shows snippets of code from the Metasploit module which executes the PowerShell cmdlet New-ManagementRoleAssignment which gives mailbox role to our user.
After mailbox capability has been assigned to the user, once again the SSRF vuln is used to save a draft email in the user’s mailbox with the attachment of a WebShell. Following is the request being sent and we can see if we investigate the mailbox, a draft has been saved with the WebShell as attachment.
If we try to look at the WebShell being saved, we see that it’s a JavaScript code executing the eval statement on whatever is passed to it as a request. The WebShell is also doubly encoded first in PST format then is Base64 as that is what is expected.
Next the New-MailboxExportRequest cmdlet is executed which due to CVE-2021-31207 can be exported in any format of choosing. So, the mail containing the WebShell is exported as aspx .NET file to a directory from where aspx files are automatically executed.
Lastly the WebShell is triggered which ultimately gives a meterpreter session back completing the exploit where attacker has full privileges control over the system.

The following flowchart summarizes the steps discussed above and mentions the vulnerability exploited in each step :\

Mitigations

Microsoft has released patches for ProxyShell back in May 21 as part of Windows Updates, so be sure to update your system to be protected against the vulnerabilities.
You can also use the Keysight test platforms with ATI subscription to safeguard your network against such attacks. Keysight Threat Simulator or BreakingPoint products can help you assess your network security controls and determine whether you can be protected before the patch. This kind of assessment is valuable as it can let you know if you have protection during the time before a change management window will open.

Leverage subscription service to stay ahead of attacks

Keysight's Application and Threat Intelligence (ATI) Subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Centre continuously checks threats as they appear in the wild and has coverage for all the 3 CVEs in ProxyShell with multiple variations of the attack (as part of releases 2022-17 and 2022-18) to help keep your network secure. More information is present here.

The following images shows screenshots of the 3 CVEs as a strike in BreakingPoint System: