Security Advisory Regarding ProxyToken

As we rapidly approach the end of August, another advisory regarding Exchange and OWA rears its ugly head. Microsoft Exchange has had a really rough go of it this past year–ProxyLogon (used by the threat group HAFNIUM much earlier this year), ProxyShell, and now, ProxyToken. 

As the names sort of imply, they are all somewhat related. The relationship between these three named sets/chains of vulnerabilities has to do with how Exchange and Outlook Web Access are configured and installed on Windows Servers–they are installed on top of the Internet Information Services web service (IIS), and consist of two IIS sites–generally referred to as the “front-end” (containing the login page and static assets that users request via their web browser) and the “back-end” (consisting of, well, basically everything else that enables users to access their inbox and e-mail related functions over the web). 

The front-end services listen on ports 80 and/or 443, while the back-end services listen on ports 81 and/or 444, respectively. Requests for access or configuration changes to a user’s mailbox, etc. are “proxied” from the front-end to the back-end portions of Exchange transparently. The problem is there are a number of assumptions occurring between that front-end and the back-end communication, which is where these vulnerabilities have been cropping up.

This latest vulnerability (CVE-2021-33766) is an authentication bypass. It is triggered using the SecurityToken cookie, and the msExchEcpCanary URI parameter. The heart of this vulnerability lies in the fact that the user can set the SecurityToken cookie, then retrieve a valid msExchECPCanary, and with those two pieces of information, perform actions against a targeted inbox, such as setting up Inbox Forwarding Rules to forward email to either an internal or external email address as a means of data exfiltration. More details about the vulnerability have been covered by Zero Day Initiative here. 

If customers have already applied the Microsoft Exchange cumulative patches from July 2021, then there is no concern. You’re already patched against this vulnerability.

For customers who have not, or cannot, patch against this vulnerability and need a means of detection, IIS web logs are going to be the best method of detecting this issue. The exploit relies on specific criteria in order to work:

• HTTP method: POST
• URL contains: “/ecp/victim@domain.test/*”
• URL contains the parameter: “msExchEcpCanary=*
• Cookie contains: “SecurityToken=”

In most customer deployments, the field cs_method contains the HTTP method used to interact with IIS. Then there are the fields cs_uri_stem that contain the URL requested up to the first parameter, at which case parameters requested are contained in cs_uri_parameter. However, in some Splunk deployments, I’ve seen the field msExchECPCanary separated out as its own field, instead of being a value of the cs_uri_parameter. Finally, there is the cs_cookie field for find the SecurityToken value. Using this information, I came up with the following query that can be used to detect general attempts at tampering with a user’s inbox rules:

Please note that this query does not utilize the cs_cookie field if that has been extracted. In which case, it might be a good idea to modify the query like so: