Can Exchange Web Services be Accessed by Bypassing Multi-Factor Authentication?

Please read the updated notes at the end of this post.

This week an information security company published their findings that Exchange Server and Exchange Online (Office 365) do not enforce two-factor authentication (2FA) for Exchange Web Services. For the most of this article I’m just going to refer to Exchange in general, and will only specify Exchange Server (on-premises) or Exchange Online (Office 365) when needed for clarity.

The report is interesting, if a little difficult to read due to mixed terminology. This happens sometimes with security reports about Exchange-related issues, so to try and clarify I will summarize their conclusion as follows:

When two-factor authentication is enabled for a mailbox user, the 2FA requirement can be bypassed for some services.

Which services are claimed to be impacted by this? After all, there are many ways to access an Exchange mailbox:

• Outlook – the desktop application that is part of the Office suite, that connects using Outlook Anywhere (aka RPC-over-HTTP) or MAPI/HTTP (both over HTTPS).
• Outlook Web App (aka Outlook Web Access, or Outlook on the web) – this is basically “webmail” for Exchange, and is accessed over HTTPS.
• Exchange Control Panel (ECP) – this is effectively the “options” section of OWA, and is accessed over HTTPS.
• ActiveSync – this is for mobile access, such as from iPhone/Android native mail apps, and mobile apps like the mobile version of Outlook, and is accessed over HTTPS.
• Exchange Web Services (EWS) – this is generally used for programmatic access to mailbox content, such as Outlook accessing calendar free/busy information, but can also be used as the primary access protocol by clients such as Outlook for Mac, the deprecated OWA for Devices mobile app, various Office 365 migration tools and mailbox backup products, etc. EWS is accessed over HTTPS.
• POP/IMAP – legacy protocols that are disabled by default for Exchange Server, but enabled by default for Exchange Online. POP and IMAP use the standard ports for those services.
• REST APIs – another programmatic method of accessing mailboxes, again over HTTPS. The REST APIs are expected to replace EWS in future.
• Autodiscover – this is a means of discovering configuration options and service endpoints for a mailbox, and is accessed over HTTPS.

In addition to those mailbox access methods, an Office 365 user can access other services such as SharePoint Online, OneDrive for Business, the Office 365 portal, Yammer, Planner, etc.

The report claims that Exchange Web Services (EWS) is the vulnerable protocol. So is the report correct? No, not according to my understanding of the technical aspects, and not according to my testing using the researcher’s own published tool.

Enabling Two-Factor Authentication (Multi-Factor Authentication)

An important point to be made here is that 2FA (or MFA, as Office 365 refers to it) can be implemented in many different ways. For Exchange Server on-premises, 2FA is not a native capability but can be implemented using third party products.

Some products, like Duo (which is mentioned in the report linked at the beginning of this article), install directly on the Exchange server, while others are integrated as a reverse proxy that sits in front of Exchange (and any other remote access method that the organization might want to protect, such as Citrix). When you use a third party product your 2FA protection is limited to the capabilities of the product itself (e.g. Duo protects OWA and ECP, but not ActiveSync, EWS, or Outlook Anywhere), and how you choose to implement it (e.g. do you enable 2FA for Exchange remote access, but not for internal Active Directory authentication).

For Exchange Online, 2FA can be implemented using the free capability included in all Office 365 plans. Depending on your identity model and requirements there’s other options as well, but for this article I’m going to just demonstrate with the Office 365 MFA features. When you enable MFA for an Office 365 user, when the user logs on to the portal or to OWA they are prompted to set up their second factor of authentication.

There’s a choice to use authenticator apps, or a phone number. And after setting MFA up, the user is also provided with an app password that can be used to login from apps that don’t support MFA. The app password is different from the bypass that has been referred to in the security report linked at the beginning of this article.

On subsequent logins with the user’s password (not the app password, just their regular password) they are prompted to enter the verification code when logging in to Office 365 services, depending on which MFA option they chose to use.

If you implement 2FA/MFA for Exchange Server on-premises, the mechanics might be slightly different but the overall experience is basically the same – the user is enabled for 2FA/MFA, prompted to set up their additional factor at next login or by some other process, and prompted at each login thereafter. For anything that doesn’t support 2FA/MFA (e.g. a POP client, mobile app, or an older Outlook client), the app password can be used.

User Expectations of Two-Factor Authentication

So that’s the user experience of MFA in general, but what are the users’ expectations for MFA? Or perhaps more importantly, what is the organization’s expectations for MFA?

When I turn on 2FA/MFA for something like Facebook or Dropbox, I expect that I am enabling MFA for my account. And that is what most users and organizations would expect when enabling MFA for Office 365 using the method above. For on-premises Exchange Server, expectations should be aligned with the capabilities of the product that has been chosen to enforce MFA, and there should be no surprises about what is and isn’t protected. It is in fact quite normal for an organization to implement MFA for OWA, but not for other remote mailbox access. That is a deliberate decision, or at least you would hope so if they understand the features and limitations of their chosen MFA implementation.

So in short, if you protect Exchange Server on-premises OWA with MFA, but not other services, then yes of course the other services can be logged into without MFA. And that means an attacker can gain access, if they’ve managed to acquire some valid credentials.

For Exchange Online, if you enable Office 365’s MFA then EWS can’t be accessed unless it is by a supported client or by using the app password. Therefore, Office 365 MFA does protect EWS.

If you implement some other MFA solution for Exchange Server or Exchange Online, it’s up to the capabilities of the solution and your implementation of it to determine which services are protected and which are not.

Dissecting the Report and News Coverage

There’s a few pieces of the security researcher’s report and news coverage that are worth calling out, just for clarity.

From the report:

I tested this against the account that was setup to be protected by DUO 2FA. MailSniper was able to successfully read and search through emails of this account completely bypassing the two-factor protection.

Correct, because Duo does not protect EWS, which they have documented.

Using the method described previously to bypass 2FA it is still possible to read emails of the allegedly protected account through Exchange Web Services. By directing MailSniper to authenticate to outlook.office365.com as the ExchHostname the mailbox of the target user can still be accessed bypassing the two-factor protection.

The report doesn’t actually demonstrate that. There is a screenshot of Mailsniper being used to access the account, but it’s not demonstrated in the video whether that is before or after MFA was enabled, and whether it is using the normal password or an app password. When I repro the scenario (MFA-enabled Office 365 account, and running Mailsniper to connect), I get a “401 unauthorized” response unless I use the app password (which is designed to bypass MFA).

In this post it was demonstrated that Exchange Web Services is not being protected by a popular two-factor authentication software, and it was possible to still read emails of a user after only obtaining their login credentials.

Yes, this literally matches the advertised capabilities of Duo.

From Threatpost:

Enterprises running Exchange Server have been operating under a false sense of security with regard to two-factor authentication implementations on Outlook Web Access (OWA) adding an extra layer of protection.

This is a human error, not a technology flaw.

The problem lies in the fact that Exchange Server also exposes the Exchange Web Services (EWS) interface alongside OWA and it is not covered by two-factor authentication.

Not covered by Duo’s 2FA product. Other implementations of 2FA/MFA including Office 365 MFA do protect EWS and other services.

EWS is enabled by default and shares the same port and server as OWA, meaning an attacker with [stolen] credentials can remotely access EWS, which talks to the same backend infrastructure as OWA, and would enable access a user’s inbox.

Yes, there are multiple HTTPS services available for mailbox access. If you choose to protect one and not others, that’s not a flaw in the Exchange product itself, it’s a flaw in your security strategy.

“This does not affect Office 365 with multi-factor authentication (MFA) fully enabled. What the blog describes is not a software vulnerability and does not work without user account credentials/stolen passwords,” a Microsoft spokesperson told Threatpost.

Correct!

From Microsoft:

Microsoft has evaluated recent reports of a potential bypass of 2FA. We have determined that the technique described is not a vulnerability and the potential bypass does not exist on properly configured systems.

Summary

The report is only partially correct, in that 2FA/MFA implementations using third party products with limited capabilities may not protect all Exchange mailbox access. However, it is not correct to take one example of limited 2FA/MFA protection and draw a conclusion that Exchange Server or Office 365 is vulnerable, has a design flaw, or that 2FA/MFA can simply be bypassed for EWS.

If you do need to lock down your Exchange Web Services configuration, you can actually do so using the EWS allow/block list capabilities that exist in both Exchange Server and Exchange Online.

Updated 5/11/2016 with Microsoft’s response. There’s also a Reddit discussion about the report.

Updated 5/11/2016: Black Hill Infosec has updated their article with the following statement.

UPDATE as of 11:15am EST on 9/4/16 BHIS has retested the portion of this article detailing a bypass against Office365 Multi-Factor Authentication and it does indeed appear to not work. Some individuals have pointed out that they were getting 401 Unauthorized error messages when connecting in via EWS with MFA fully enabled on a user. When testing against the initial test user BHIS tested against EWS on O365 it now produces the same 401 error results when using a password to authenticate. BHIS believes that the results obtained previously were due to a delay in which Office365 MFA was denying access to Exchange Web Services after recently enabling it for a user. A video demonstrating this has been put together here.

That aligns with the guidance from Microsoft:

Office 365 users may experience a small delay in activation of MFA on all protocols due to propagation of configuration settings and credential cache expiration.

Updated 22/11/2016: Black Hill Infosec is running webinars on this topic now, without acknowledging that their test was inaccurate, nor that it was the Duo product itself that lacks the ability to apply 2FA to all Exchange services. Here’s their webinar description:

Lately we released an attack where an evil bad guy (or tester) could easily bypass Outlook Web Access Two Factor Authentication to gain access to sensitive emails. We were hoping to see a change in the way OWA handled authentication. Instead, we we got an email from Microsoft stating this is not an issue anyone should worry about. We also saw several posts from exchange experts saying the same thing…

But we think worrying is probably in order.

This vulnerability is built on a year of work at BHIS. From OWA domain enumeration, to user enumeration, to password enumeration to bypass it has been a slow steady build on this attack. Well, now we will do a full, step-by-step walk through of the attack, from beginning to end, to demonstrate the risk. We will also re-enforce and highlight why the OWASP top 10 are still relevant and so key to this attack.

I’ve highlighted the sections in bold to call them out specifically. First, the problem isn’t in how OWA handles authentication. OWA is just one access method for Exchange Server or Exchange Online. The problem, if one exists, is that the Duo product chosen by the researchers only protects OWA with 2FA, and not any other access method. Meanwhile, Microsoft’s own Office 365 MFA capability does protect OWA, EWS, and others just fine, hence the advice from Microsoft that this is not vulnerability in Exchange or Office 365. In their original article, BHI states:

It should be stated that this is NOT a vulnerability in DUO Security’s product. It is a problem in which Microsoft Exchange server exposes the Exchange Web Services interface unprotected by 2FA alongside OWA.

That statement is false. What they demonstrated by bypassing Duo 2FA is entirely a weakness of the Duo product when you are trying to protect all protocols with 2FA.

Secondly, yes those enumeration risks exists (I don’t see any Exchange experts denying that). Let me save you the trouble of sitting through their webinar.

• OWA domain enumeration is possible because most customers standardize on URLs like “mail.contoso.com” or “webmail.contoso.com”, or even have a link to OWA prominently placed on their website. The reason being, it’s easier for end users to remember or find the OWA URL when they need it. There’s not much point trying to obfuscate an OWA URL these days.
• User enumeration is possible because most Exchange/Office 365 usernames align with the primary SMTP address, which is the recommended practice these days. Again, that’s easier for end users to remember, and makes authentication with cloud services a lot smoother. Email addresses are not secret.
• Password enumeration is possible because customers aren’t monitoring for suspicious login activity. Account lockout policies don’t prevent this. Microsoft offers services like Advanced Threat Analytics and Advanced Security Management to help detect and prevent these types of attacks. Password exposure is mitigated by 2FA/MFA (a properly implemented system, not a half-measure that doesn’t protect all your access methods).

Security is important, and there are real issues that customers need to consider and take action on. There are many fine security experts that can help you with these matters. But it’s hard to respect a security company that tries to double down on an embarrassing mistake of their own by running with misleading statements.