In not altogether unexpected news, a new Exchange vulnerability has been disclosed this week known as ProxyToken that allows someone who can access an Exchange 2013, 2016 or 2019 server over HTTPS to perform configuration actions against mailboxes of their choosing, such as setting forwarding rules.
To save unnecessary worry, I’ll get straight to the point – If you have patched your Exchange Servers fully including the July Security updates, then you don’t need to patch again today to resolve this.
The July updates included the patch for CVE-2021-33766 which represents the report of the vulnerability. What’s changed is that it has been publicly disclosed, and it has been exploited in the wild.
Make sure to join my session at TEC on 9/2 that explores Exchange on-prem security concerns
If you haven’t patched yet, patch now
I cannot stress this enough. If you are running Exchange Server on-premises, then patch your servers now. Microsoft have made it easy to understand what you need to do at an easy-to-remember site, aka.ms/ExchangeUpdateWizard – so if you aren’t sure what to do, use this as a starting point to guide you on what is a reasonably routine journey.
If you are running an Exchange Server for Hybrid management, this also applies to you. There may not be a mailbox on-premises to exploit with this particular vulnerability, but it is not the only one that you should be concerned about. After you have patched your last Exchange Servers then there are other things you can do to reduce your risk until the last Exchange Server can be removed.
Perhaps you don’t publish Exchange (or the Hybrid server) to the Internet and don’t think you need to patch quickly? If you do believe that, then you are (I’m sorry to be blunt) naïve. Your environment might not be on a list of scanned targets, but if an attacker is looking for another way in via a compromised account or device that does have access to your network, then they’ll still find these vulnerabilities useful. Patch your servers.
In my recent Practical 365 Live YouTube stream, and on the latest podcast, I discussed with Microsoft MVP, Michael Van Horenbeeck other actions you should take. In particular, Michael points out that increasing logging is essential as most organizations do not log enough information to understand whether they have been comprised, how they were compromised and the extent of damage.
How ProxyToken works and what an attacker can do
Firstly, as a quick refresher, Exchange Server 2013 includes a Client Access role and a Mailbox Role. Exchange 2016 and 2019 combine these two roles together as just the Mailbox role. Client Access services listen on normal HTTPS, port 443, and the Mailbox components run HTTPS on port 4443 to fulfil requests from the server on which a user’s mailbox is currently active.
This is why you’ll sometimes see the Client Access services referred to a “CAFE” or Client Access Front End – it acts as a proxy back to the Mailbox services, and forms a foundation to allow simply load balancing and scaling of Exchange 2013 and higher.
Requests are intended to be authenticated by the Client Access services first, and then after the user’s mailbox location is determined, are proxied by the Client Access services on behalf of the user to the back end HTTPS services.
An exploit using ProxyToken bypasses the authentication stage to Mailbox configuration options in /ecp, allowing an attacker to set options of their choosing for a mailbox.
A good example of what an attacker can do is to set forwarding to either an internal mailbox (that they’ve already compromised and have access to) or to an external address. The most obvious scenario for this would be to get access to new email for high value targets, such as your finance teams or executives.
The attack itself is based upon the SecurityToken cookie sent in the HTTP POST request being the method that the Client Access services determine that the request has previously been authenticated and that it should send it to the back-end service; but the back-end is not always aware it must validate the request. This is used to allow an attempt to send a request to the back-end /ecp virtual directory. The back-end does do some additional validation though, and expects a valid ticket to be sent using a cookie known as msExchEcpCanary. Without it, the back-end service returns a HTTP 500 error.
The fatal flaw appears to be that in the HTTP 500 response, a valid msExchEcpCanary value is sent to the requester – which can then be used to perform an malicious action, such as setting a forwarding address.
The Zero Day Initiative provide more detail in a blog post by Simon Zuckerbraun and it’s worth a read if you have time.
Understanding if you’ve been compromised due to this
According to cyber security experts, attempts to compromise servers have been seen as far back as August 10th (at least) which means that if you were patching your Exchange Servers mid-August then you almost certainly were at risk.
These requests won’t show up in your IIS log files, as they require the ability to capture the HTTP POST request including the cookie sent, not just the URL attempted.
If you are using Azure Sentinel, then you will find a Hunting Query for this exploit on GitHub.
If you are concerned that Mailbox Rules have been created to forward email (for example) outside the organization or to a suspicious, compromised account, then remember you can export Mailbox Rules. An Exchange Management Shell one-liner like this one will give you a rapid idea of whether there is an extremely serious situation to manage:
Get-Mailbox -ResultSize Unlimited |% { Get-InboxRule -Mailbox $_.UserPrincipalName | Where {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo} | Select Name,Identity,ForwardTo,ForwardAsAttachmentTo,RedirectTo}
Frustrating as this is – the attention Exchange is getting at the moment will only make it a more secure product, and responsible disclosure giving you time to patch is better than finding a threat in the wild that you can’t protect against easily. So once again – please make sure you are keeping up to date with patches.
