A look at the ProxyLogon Microsoft Exchange vulnerability (CVE-2021-26855)
Multiple PoCs and write-ups on the notorious “ProxyLogon” Microsoft Exchange Server vulnerabilities have been made public. Although full chain exploits are still kept away from the wider audience, chances are that we’ll see more and more attacks in the wild, so the best things you can do are patching and verifying whether your servers have been compromised.
In this article, we’ll provide a brief description of CVE-2021-26855, the vulnerability that opens the door for other three vulnerabilities initially used by the group known as HAFNIUM to fully compromise servers.
Exchange servers have a building block architecture designed to handle high loads and provide availability and communication between different server versions. Multiple servers running the same version can be configured to work together in a database availability group (DAG) to provide database-level recovery from failures.
To accommodate these scenarios, each server operates multiple layers of protocols that are used to provide access for various clients and communications between servers. Hence, external clients do not communicate directly with the backend services but through frontend APIs (Client Access Services), such as the Outlook Web App (OWA).
Because of this segregation between the backend and client layers, a proxy is used to pass requests between OWA, which listens on port 443/TCP, and the Exchange Back End, which is bound to port 444/TCP. The functionality is provided by the library ‘Microsoft.Exchange.FrontEndHttpProxy.dll’ that operates as an IIS module.
The authentication bypass vulnerability results from having to treat requests to static resources as authenticated requests on the backend, because files such as scripts and images must be available even without authentication. This mechanism is accomplished by using a cookie named ‘X-BEResource’ that has the following format:
X-BEResource=<host/fqdn>~<server_version>
The proxy then takes the host part and concatenates it to the request path to form the full URL request to the backend, so for the request depicted below, the final URL would be:
WIN-65F9JFV4L58.ati.local/ecp/15.1.2106.2/scripts/flurry.js
During the concatenation, however, no check is in place to validate whether the host/FQDN contains additional characters that may be used to manipulate the request to the backend. An attacker may alter its value to access non-static resources or pages. For example, the up-mentioned cookie value can be changed as follows, to send authenticated requests to EWS (a SOAP-based API for the backend):
X-BEResource=<host/fqdn>/EWS/Exchange.asmx#~<server_version>
The proxy will split the cookie value by tilde (‘~’) character, extract the host part, and the final URL would be:
<host/fqdn>/EWS/Exchange.asmx#/ecp/15.1.2106.2/scripts/flurry.js
Because the URL string after the hash character acts as an HTTP anchor, it does not interfere with the altered request. Alternatively, parameters may be used to achieve the same function.
X-BEResource=<host/fqdn>/EWS/Exchange.asmx?a=~<server_version>
From this point on, an attacker is free to send arbitrary requests to obtain a valid (authenticated) OWA session.
A typical attack flow can be comprised of the following steps:
1. Send a GET request to leak the host value. Because the Exchange server embeds it in a header, it is not required for the ‘X-BEResource’ cookie to be set.
2. Use the flaw to send an auto-discovery request to the backend to leak a user’s LegacyDN.
3. Use the flaw to send a request to the MAPI endpoint to retrieve the user’s SID.
4. Finally, use the flaw to send a request to ‘/ecp/proxyLogon.ecp’ endpoint to obtain a valid session.
From this point on, the valid session can be used by malicious actors to exploit other authenticated vulnerabilities, such as CVE-2021–27065, to obtain remote code execution, deploy ransomware, or proceed with double extortion tactics.