ProxyToken: Another nail-biter from Microsoft Exchange

Had I known this season of Microsoft Exchange was going to be so long I’d have binge watched. Does anyone know how many episodes there are?

Sarcasm aside, while ProxyToken may seem like yet another episode of 2021’s longest running show, that doesn’t make it any less serious, or any less eye-catching. The plot is a real nail-biter (and there’s a shocking twist at the end).

This week’s instalment is called ProxyToken. It’s a vulnerability that allows an unauthenticated attacker to perform configuration actions on mailboxes belonging to arbitrary users. For example, an attacker could use the vulnerability to forward your mail to their account, and read all of your email. And not just your account. The mail for all your co-workers too. So there are multiple possible themes for this episode, including plain old data theft, industrial espionage, or just espionage.

Background and character development

Before we can explain this week’s plot, it’s important to catch up on some background information, and meet some of the principal players.

Exchange Server 2016 and Exchange Server 2019 automatically configure multiple Internet Information Services (IIS) virtual directories during installation. The installation also creates two sites in IIS. One is the default website, listening on ports 80 for HTTP and 443 for HTTPS. This is the site that all clients connect to for web access.

This front end website for Microsoft Exchange in IIS is mostly just a proxy to the back end. The Exchange back end listens on ports 81 for HTTP and 444 for HTTPS. For all post-authentication requests, the front end’s job is to repackage the requests and proxy them to corresponding endpoints on the Exchange Back End site. It then collects the responses from the back end and forwards them to the client.

Which is all good, if it weren’t for a feature called “Delegated Authentication” that Exchange supports for cross-forest topologies. An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, users, computers, and group policies. A single Active Directory configuration can contain more than one domain, and we call the tier above domain the AD forest. Under each domain, you can have several trees, and it can be tough to see the forest for the trees.

Forest trusts reduce the number of external trusts that need to be created. Forest trusts are created between the root domains of two forests. In such deployments, the Exchange Server front end is not able to perform authentication decisions on its own. Instead, the front end passes requests directly to the back end, relying on the back end to determine whether the request is properly authenticated. These requests that are to be authenticated using back-end logic are identified by the presence of a SecurityToken cookie.

The plot

For requests where the front end finds a non-empty cookie named SecurityToken, it delegates authentication to the back end. But, the back end is sometimes completely unaware that it needs to authenticate these incoming requests based upon the SecurityToken cookie, since the DelegatedAuthModule that checks for this cookie is not loaded in installations that have not been configured to use the special delegated authentication feature. With the astonishing end result that specially crafted requests can go through, without being subjected to authentication. Not on the front end nor on the back end.

The twist

There is one additional hurdle an attacker needs to clear before they can successfully issue an unauthenticated request, but it turns out to be a minor nuisance. Each request to an Exchange Control Pane (ECP) page is required to have a ticket known as the “ECP canary”. Without a canary, the request will result in an HTTP 500 response.

However, imagine the attacker’s luck, the 500 error response is accompanied by a valid canary! Which the attacker can use in his next, specially crafted, request.

The cliffhanger

This particular exploit assumes that the attacker has an account on the same Exchange server as the victim. It installs a forwarding rule that allows the attacker to read all the victim’s incoming mail. On some Exchange installations, an administrator may have set a global configuration value that permits forwarding rules having arbitrary Internet destinations, and in that case, the attacker does not need any Exchange credentials at all. Furthermore, since the entire ECP site is potentially affected, various other means of exploitation may be available as well.

Credits

The ProxyToken vulnerability was reported to the Zero Day Initiative in March 2021 by researcher Le Xuan Tuyen of VNPT ISC. The vulnerability is listed under CVE-2021-33766 as a Microsoft Exchange Information Disclosure Vulnerability and it was patched by Microsoft in the July 2021 Exchange cumulative updates.

Other “must watch” episodes

Microsoft Exchange has been riveting viewing this year, and with four months of the year to go it seems unlikely that ProxyToken is going to be the season finale. So here’s a list of this season’s “must watch” episodes (so far). If you’ve missed any, we suggest you catch up as soon as possible.

• ProxyToken
• ProxyShell
• ProxyLogon
• ProxyOracle

And remember, Exchange is attracting a lot of interest this year. Everyone’s a fan. All of these vulnerabilities are being actively scanned for and exploited by malware peddlers, including ransomware gangs.

The post ProxyToken: Another nail-biter from Microsoft Exchange appeared first on Malwarebytes Labs.