Microsoft released an out-of-band (OOB) patch on 3rd March, 2021 for several vulnerabilities affecting Microsoft Exchange Servers 2013, 2016 and 2019,  that are running on-premise. Microsoft has detected exploitation of these vulnerabilities in the wild and has urged everyone to patch it at the earliest.

A hacking group dubbed as ‘HAFNIUM’ has been seen abusing Exchange Server’s 0-day vulnerabilities in the wild. 

“HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.” — Microsoft 

In-the-wild exploitation of Exchange server vulnerabilities by HAFNIUM group  raised some eyebrows in the security community. The timing of this exploitation is something to ponder about. 

This blog is part one of a two-blog series, which talks about vulnerabilities in Microsoft Exchange Server.

Timeline of Events

• Jan 5th, 2021 – Devcore, a China based company which primarily works on Red Teaming and Pentesting, reported pre-auth SSRF & post-auth arbitrary write vulnerability to Microsoft 
• Jan 6th, 2021 – Microsoft acknowledged both the vulnerabilities
• Mar 3rd, 2021 – Microsoft releases OOB patch for 4 vulnerabilities related to Exchange Server
• Mar 8th, 2021 – Volexity, a US based company reported exploitation of SSRF vulnerability dated back to Jan 3rd, 2021 and multiple Exchange vulnerabilities exploitation from Jan 6th, 2021 in some of their customers’ servers

Introduction

Microsoft Exchange Server is a mail server offered by Microsoft and is one of the oldest core parts of Microsoft services dating back to 1994. Later on, Microsoft launched Exchange Servers online as a cloud service (SaaS). Microsoft has stated that the online Exchange service is not affected by this vulnerability.

Before we take a look at the vulnerabilities, we need to understand how the Exchange Server works. 

The Client Access protocol architecture diagram is shown in Figure 1. There are two parts in the Mailbox server :

 1.Client access services (also called Frontend services) 

 2. Backend services 

The HTTP(s) client applications like Outlook and Web Clients request resources from IIS. The request is then forwarded to the backend services via HTTP proxy. HTTP proxy  decides the destination route of the request to the available backend services. The vulnerabilities discussed here are in the HTTP Proxy and UMS component of the Client Access Services Layer of the Exchange Server.

As you can see from Figure 1, clients cannot connect to backend services directly.

These are the 4 vulnerabilities exploited as part of an attack chain by the HAFNIUM group.

• CVE-2021-26855
• CVE-2021-26857
• CVE-2021-26858
• CVE-2021-27065

Into the Details

HAFNIUM group used these vulnerabilities as a part of an attack chain to bypass authentication, gain privilege access and to plant and execute a web shell. 

During post exploitation, the adversaries were able to access mailbox contents like inbox, outbox, contacts and much more.

CVE-2021-26855

This is an unauthenticated Server Side Request Forgery (SSRF) vulnerability. It allows an adversary to send HTTP requests and authenticate themselves as an Exchange Server administrator or user. This vulnerability is dubbed as “proxylogon”. It is present in Exchange Proxy Architecture and in the Logon mechanism.

 What is SSRF?

SSRF is a web vulnerability wherein an attacker can cause a (remote) server side application to make connection requests to other network entities that the attacker chooses; sort of a proxy communication. Usually, requests sent using this vulnerability are requests to self or other back-end systems which are not directly exposed. Attackers also look for internal resources (like files and database HTTP interfaces) which sometimes may eventually lead to arbitrary command execution.

This vulnerability in Exchange Servers can be exploited to retrieve sensitive information like email contents, address book etc.

SSRF vulnerability has been reported in two different client interfaces under this CVE-2021-26855. One of them is straightforward (/owa/) and the other one needs some checks to be bypassed before it can be exploited (/ecp/).

Diffing revealed that a new function has been added in the namespace HttpProxy after the patch.

BEResourceRequestHandler handles the HTTP requests if it is a request for an allowed type of resource and if the return value of GetBEResourceCookie is not null.

Allowed Resource types include font, image, media, object, stylesheet and others. 

Let’s dive into the GetBEResourceCookie function

The function just checks whether cookie at Constants.BEResource, i.e. X-BEResource is present or not.

So, two things are clear from here.

1. Request has to be for an allowed resource type
2. Cookie X-BEResource should be set

So, where is this request parsed and where does our payload go in this request? Let’s look at the function call trace.

Once the request is passed through BeginProcessRequest(), it reaches ResolveAnchorMailbox() in BEResourceRequestHandler class, the place where we suspect our vulnerability is lying.

The function shown in Figure 8 does basic sanity checks on X-BEResource cookie and logging it. At the bottom of the function, it is returning serverinfo by passing our cookie to a FromString() function in BackEndServer class.

From the code (Figure 9), we can see that the cookie is split into two parts separated with a ‘~’.

Second part is parsed as a 32-bit signed integer. Both the args are sent to the BackEndServer constructor function, where first part is interpreted as Fully Qualified Domain Name (FQDN) and second part as version.

Our cookie looks something like this:

X-BEResource=FQDN~1923032134

So, let’s look at where this data from BackEndServer is used.

The call trace follows this way, 

BeginProxyRequest() Prepares URL through GetTargetBackEndServerUrl() and proceeds for KerberosAuthentication.

The GetTargetBackEndServerUrl() prepares the URI and does a check on version, checking that its less than E15MinVersion.

So, as long as your second part of the cookie is greater than this number, the exploit works.

From Figure 11 we can see that, if the number is less than the specified number, then, the ClientUrlForProxy port becomes 443, else it will be 444. This is intended for managing down-level and up-level proxy. It is used when the proxy requests are between two different versions of the Exchange Server. Leveraging this and SSRF here, we can put a higher version and force the forwarding request port to be 444. So, we can access the backend server without authentication.

Only while requesting backend resources or authenticating to backend services, should we mention the higher version value.

Since, we’ll eventually request core services for sensitive information, we have used a lower version number in the cookie as the resources we need are available in client access services and soon after that, we have used the version numbers higher than the hardcoded E15MinVersion to change the control flow towards backend services..

 As a thumb rule, we can set the version value to be higher. While requesting for basic information from FrontEndProxy, we can use /owa/auth/ endpoint and for the rest of the exploit chainuse /ecp endpoint with higher version in the cookie.

Now, the ClientUrlForProxy will be sent to the backend. The host in this request is the FQDN, set by FromString() earlier. Now, this method directly works without any authentication.

Authentication checks for ProxyRequests happen at PrepareServerRequest() in ProxyRequestHandler class.

Look at the highlighted section above, the if & else if code block has multiple checks to test. Let’s take a look at them.

ProxyKerberosAuthentication is already set False before preparing this request. So, the control flow jumps to else if block. The else if block determines if the request is authenticated or not.

The last condition in the else if block fails as we do not pass headers with that name, also  TestBackEndUrl and ShouldBackendRequestBeAnonymous() returns False.

So, this forces the control over the else block after bypassing the authentication check.

Microsoft has patched the vulnerability at several places, one of them includes overriding the function ShouldBackendRequestBeAnonymous() and making the return value for the function as “True” in the ProxyRequestHandler. Thus, changing the control flow away from unauthenticated requests.

Let’s try to query some information using this vulnerability.

Similarly, we can pull any information from the mailbox including inbox, drafts, outbox, contact addresses etc.

Wait a sec, didn’t I tell you that there is one more SSRF that isn’t complex. This one lies in X-AnonResource-Backend cookie. It just doesn’t have that version check. 

This further can be abused to bypass authentication mechanisms as the request is forged and run as an Exchange Server. One can retrieve Security Identifiers (SID) for this user and use that in post-auth file write for a complete RCE.

Recommendations 

• Use VPN or limit access to your Exchange Server by placing it behind a firewall in your internal network. Also, do not expose your Exchange Server to the internet unless absolutely necessary
• Turn on your firewall at all times
• Avoid using the administrator account as the main account on critical machines
• Ensure your systems are up-to-date for OS patches and allow updates to install by default
• Use a reputed security product like K7 Endpoint Security and K7 Total Security to stay protected from the latest threats

Mitigations 

• Install the patches if you haven’t already done from here
• Investigate your server for IoCs and exploitation
• If you’d like to scan your servers for the vulnerability, Microsoft has released an nmap script to detect any vulnerable Exchange Servers in your network : 
• Disable Unified Messaging service, if not in use
• Disable OAB Virtual Directory, if not in use

We at K7 Computing constantly monitor for such malware and vulnerabilities and ensure that we provide proactive protection against such attacks. Also our Generic Anti-Ransomware feature in our security product flags it before the ransomware can execute. As always, we recommend our customers to use the K7 security products to protect their data and keep it updated to stay protected from the latest threats. 

Indicators Of Compromise (IOCs)

Authentication Bypass and RCE Indicators

• /owa/auth/Current/themes/resources/…
• /ecp/default.flt
• /ecp/main.css
• /ecp/<single char>.js

WebShell Indicators

\inetpub\wwwroot\aspnet_client\ (any .aspx file under this folder or sub folders)

\<exchange install path>\FrontEnd\HttpProxy\ecp\auth\ (any file besides TimeoutLogoff.aspx)

\<exchange install path>\FrontEnd\HttpProxy\owa\auth\ (any file or modified file that is not part of a standard install)

\<exchange install path>\FrontEnd\HttpProxy\owa\auth\Current\<any aspx file in this folder or subfolders>

\<exchange install path>\FrontEnd\HttpProxy\owa\auth\<folder with version number>\<any aspx file in this folder or subfolders>

The above indicators are courtesy of Volexity found in-the-wild exploitation by the Hafnium group.

Further Readings 

1. https://docs.microsoft.com/en-us/exchange/architecture/architecture?view=exchserver-2019#client-access-protocol-architecture
2. https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/
3. https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
4. https://proxylogon.com/
5. https://www.recordedfuture.com/redecho-targeting-indian-power-sector/
6. https://www.reuters.com/article/health-coronavirus-india-china-idUSKCN2AT21O
7. https://cobalt.io/blog/a-pentesters-guide-to-server-side-request-forgery-ssrf

to Part 2…