The Proxyshell vulnerability was discovered by Orange Tsai, a security researcher at Devcore, in the Pwn2Own hacking contest, April 2021. ProxyShell is chained with three bugs – CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207.
- CVE-2021-34473: Pre-auth Path Confusion that leads to ACL bypass
- CVE-2021-34523: Elevation of Privilege on Exchange PowerShell Backend
- CVE-2021-31207: Post-auth Arbitrary-File-Write leads to Remote Code Execution
These three vulnerabilities can perform unauthenticated, and lead to remote code execution on Microsoft Exchange servers when chained together.
An unauthenticated attacker can execute arbitrary commands on Microsoft Exchange’s Client Access Service (CAS) through an only exposed port 443 in IIS.
At the Black Hat conference on August 5, 2021, Orange Tsai revealed some exciting and new information about ProxyShell vulnerability.
Two of them, CVE-2021-34473 and CVE-2021-34523, were patched by Microsoft in April with its KB5001779 cumulative update, while CVE-2021-31207 was patched about a month later.
With the help of newly revealed information, attackers are actively scanning for vulnerable instances of Microsoft Exchange servers to exploit.
According to Tsai’s information, one of the components of the ProxyShell attack chain targets the Microsoft Exchange auto-discover service that was introduced by Microsoft to provide a straightforward way for mail client software to auto-configure itself with minimal input from the user.
ProxyShell started with a Path Confusion bug on Microsoft Exchange Server. The Explicit Logon feature in Exchange Server is designed to enable users to open another mailbox or calendar and display it in a new browser window.
The Exchange Server parses the mailbox address and normalizes the URL internally and can extract the mailbox address from the URL.
By replacing the actual part with an Explicit Logon pattern we’ll get
Arbitrary Backend Access
Image Source: Orange Tsai Presentation
The Exchange PowerShell Remoting is built upon PowerShell API and uses the Runspace for isolation. All operations are based on WinRM protocol.
With the piece of code extract Access-Token from URL, we can elevate the privileges because the Exchange PowerShell backend can be accessed directly.
We can use this privilege escalation to “downgrade” from SYSTEM to Exchange Admin by specifying the Access-Token in X-Rps-CAT.
As the Exchange Admin, it is easy to exploit the Exchange PowerShell command New-MailboxExportRequest to export the user’s mailbox into a UNC path.
New-MailboxExportRequest –Mailbox email@example.com –FilePath \\127.0.0.1\C$\path\to\shell.aspx
We can embed the malicious payload into the exported file and deliver that encoded WebShell payload via Emails (SMTP)
Getting the Shell:
1. Deliver encoded WebShell payload by SMTP
2. Launch the native PowerShell and intercept the WinRM protocol
• Rewrite the /PowerShell/ to /Autodiscover/ to trigger the Path Confusion bug
• Add query string X-Rps-CAT with corresponding Exchange Admin Access Token
3. Execute commands inside the established PowerShell session
• New-ManagementRoleAssignment to grant ourselves Mailbox Import Export Role
• New-MailboxExportRequest to write ASPX file into the local UNC path
4. Enjoy the shell
Shortly after attending Tsai’s talk, a few security researchers were able to reproduce the ProxyShell exploit and shared a blog post detailing the vulnerability. Also, security researcher Kevin Beaumont confirmed that a threat actor was probing into his Microsoft Exchange honeypot against the server’s auto-discover service.
Threat actors were successfully able to detect a vulnerable system using the URL mentioned by Tsai, as it triggers the compilation of the ASP.NET web application.
Security researcher Beaumont advises administrators to use Azure Sentinel to check IIS logs for the “/autodiscover/autodiscover.json” or “/mapi/nspi/” strings.
W3CIISLog | where csUriStem == "/autodiscover/autodiscover.json" | where csUriQuery has "/mapi/nspi/"
If the targeted auto-discover URL is included in the results, it implies that threat actors have scanned your server for the vulnerability.
While patches have been available for months, many Microsoft Exchange servers are still vulnerable to ProxyShell attacks; so, it would not be surprising if multiple threat actors start exploiting the flaws in their operations. Hence, it is strongly advised that Microsoft Exchange admins install the latest cumulative updates, so they are protected from these vulnerabilities