Two-factor authentication protecting Outlook Web Access and Office 365 portals can be bypassed-and the situation likely cannot be fixed, a researcher has disclosed.

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.

A design weakness has been exposed that can allow an attacker to easily bypass 2FA and access an organization’s email inboxes, calendars, contacts and more.

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. 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.

The issue was publicly disclosed on Wednesday by researcher Beau Bullock of Black Hills Information Security, a consultancy based in South Dakota. Bullock privately disclosed his findings to Microsoft on Sept. 28, and after an initial acknowledgement, repeated follow-up emails failed to produce a patch or mitigation. Bullock went public yesterday, but shortly thereafter, Microsoft contacted him with a mitigation that would likely break some services that rely on Exchange Web Services, such as thick clients like Outlook for Mac.

Bullock told Threatpost that it’s likely Microsoft cannot fix this without re-architecting some parts of the affected infrastructure.

“The biggest thing is that Outlook Web Access is on the same webserver as Exchange Web Services and they’re both enabled by default. I think the biggest problem is that most people don’t seem to understand that’s the thing that’s happening,” Bullock said. “A lot of people think they have this Exchange server on the Internet and they have it there just for OWA, but the biggest problem is they don’t understand EWS is enabled by default as well. The fix is more widespread awareness that it’s actually there.”

Bullock, a penetration tester, believes that there isn’t a lot of awareness that this configuration exists and that organizations aren’t aware that this second protocol is running alongside OWA and is not covered by 2FA.

“That’s not inherently clear in the documentation that if you enable two-factor authentication on OWA, you have to be careful that you have this other protocol right here that is still only single factor,” Bullock said. “It talks to same backend infrastructure.”

Bullock pointed out that it’s not unusual to have different protocols, such as RDP and SMB, running on the same server where, for example, RDP is covered by two-factor authentication and SMB is not. The two services, however, are not running on the same port, and Bullock points out that an enterprise could create firewall rules to curtail access.

“That’s why this is more of a serious issue,” Bullock explained. “When you expose a server externally, you allow access only to that port. If you don’t know a completely separate protocol is operating on same port, you’re potentially opening up another way to communicate to that infrastructure.”

Bullock described in a report published yesterday how he carried out the attack against OWA protected by Duo for Outlook 2FA.

By targeting EWS with his test account’s credentials and a pen-testing tool called MailSniper, which connects to Exchange and searches an inbox for sensitive data, Bullock was able to bypass the 2FA protecting OWA. An attacker in a real-world scenario could gain access to a user’s credentials, for example, from any of the tens of millions of credentials dumped online this summer.

To confirm that this wasn’t an issue with Duo for Outlook, Bullock ran a similar test against Office 365 with Microsoft Azure Multifactor Authentication enabled. Using the same attack, he was able to bypass that 2FA as well, Bullock said.

“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.

“I think in the end, the best solution would be to re-architect it,” Bullock said. “In the short term, how hard would it be for Microsoft to disable it by default and if an organization actually needed to use EWS for a thick client, then they could enable it. They’re trying to keep all the protocols open and make it easier for deployment.”