, , , , , , , , , , , ,

Bypassing Two-Factor Authentication on OWA & Office365 Portals

Beau Bullock //

ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.

Full Disclosure: Black Hills Information Security believes in responsible disclosure of vulnerabilities. This vulnerability was reported to Microsoft on September 28th, 2016. As of the publication date of this post(November 2nd, 2016) Microsoft have not responded with any updates other than to say there are no updates. The full timeline of this disclosure can be found in a section at the end of the blog post.

UPDATE as of 3pm MST 11/2/16: This blog post demonstrates a two-factor authentication bypass technique against Microsoft Outlook Web Access where the third-party 2FA vendor was DUO Security. 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. 

UPDATE as of 11:15am EST on 11/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: https://youtu.be/Bb_T3ILfllU

Additionally, a very detailed post regarding the various protocols of Exchange has been put together here: http://exchangeserverpro.com/exchange-web-services-bypass-multi-factor-authentication/

_______

ORIGINAL POST: At DerbyCon 6.0 I released a tool called MailSniper for searching mailboxes for sensitive data in a Microsoft Exchange environment. MailSniper utilizes Exchange Web Services (EWS) when connecting to an Exchange server to retrieve messages from a user’s inbox. EWS is a web-based API enabled on Exchange servers that Microsoft recommends customers use when developing client applications that need to interface with Exchange. The API allows for applications to have the ability to interact with email messages, contacts, calendar, and more from user’s mailboxes.

While at DerbyCon I sat in on a talk called “Outlook & Exchange for the Bad Guys” by Nick Landers. It was an awesome talk that I highly recommend checking out. During his talk Nick received a question from the audience in regards to whether two-factor authentication (2FA) would stop the attacks he mentioned during the talk. Nick replied with a statement I found very interesting. He said “I’ve seen some organizations lockdown 2FA on OWA. So when you go to the Outlook Web Access you have to supply a token before you can finish logging in. That wouldn’t stop a lot of these attacks because two-factor auth doesn’t apply to EWS or the NTLM auth on the Autodiscover page.”

I thought to myself if 2FA on OWA doesn’t apply to EWS, then it should be possible to read emails using EWS with MailSniper, completely bypassing the 2FA security control.

To test this theory I set up an Internet-facing Outlook Web Access portal, and installed a popular 2FA software (DUO for Outlook) on it. I setup the DUO mobile application on my phone, and logged into our OWA portal using a test user account called ‘[email protected]’.

Standard OWA Login Page

After syncing DUO with my phone I could now receive push notifications upon logging in to confirm my second factor during authentication. At this step, if I was a remote attacker and did not have the phone synced with the DUO 2FA software, I could not proceed any further with logging into the OWA portal.

DUO 2FA Screen

Previously, with MailSniper it was only setup to work on an internal domain. I modified the code slightly to add in a “-Remote” switch that will allow the Invoke-SelfSearch function to work remotely across the Internet. A few things are needed in order to access a mailbox remotely. First, an external email server for the target organization needs to be located. In many cases these can be discovered using Autodiscover or by brute forcing subdomains like mail.domain.com, owa.domain.com, webmail.domain.com, etc. The mail server needs to be specified with the ‘-ExchHostname’ option. If no ‘-ExchHostname’ option is specified Invoke-SelfSearch will attempt to Autodiscover the mail server. Secondly, a valid set of user credentials must be gathered. For some ideas on doing this remotely see this blog post.

Once the Exchange server hostname, and credentials of the target user are obtained the following command can be used to search an exchange mailbox remotely over the Internet:

Invoke-SelfSearch -Mailbox [email protected] -ExchHostname mail.domain.com 
-Remote

Once this command is run a credential box will pop up requesting the credentials of the target user. Depending on how the organization setup internal User Principal Names (UPN’s) the target user’s email address or domain\username can be entered into the username box.

After the credentials have been entered MailSniper will attempt to connect to the EWS URL at https://mail.domain.com/EWS/Exchange.asmx and search the user’s inbox for key terms (by default “*pass*”, “*creds*”, and “*credentials*”).

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.

To further validate that this is not simply a problem with the DUO 2FA software, BHIS set up an Office365 instance and utilized Microsoft’s own Azure Multi-Factor Authentication (MFA) to protect a user account from accessing the “Outlook Mail” portion of Office365.

To demonstrate this I first logged in to my test user’s account at the standard Office365 login portal.

After entering the correct password the additional Microsoft Azure Multi-Factor authentication portion is necessary. In this case I had it send me a text message to deliver the verification code.

After the MFA verification code has been entered the test user was now able to access the inbox at Outlook.Office.com.

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.

Demo Video

Recommendations

I wish the easy answer for fixing this would be disabling Exchange Web Services but that could break many things. For example, from what I can tell Outlook for Mac utilizes Exchange Web Services exclusively to connect to Exchange. So if you have Macs in your environment disabling EWS probably isn’t an option. The same would go for any custom apps that utilize it. So, in the short term lockdown OWA to only be accessed from an internal network, and require users VPN in to access it. It appears that it is possible to lockdown Exchange Web Services manually for specific user accounts or even for the entire organization. But, keep in mind any users that are using applications that utilize Exchange Web Services to connect to Exchange will likely break.

Conclusion

In conclusion, it appears that Outlook portals that are being protected by two-factor authentication might not be covering all of the authentication protocols to Microsoft Exchange. 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. Exchange has other services that might have a similar problem such as MAPI over HTTP, and Autodiscover. I tested against one third-party 2FA software, and Microsoft’s own Azure Multi-Factor authentication but I’d imagine others likely have the same problem.

Timeline of Disclosure

  • September 28, 2016 at 1:51 PM Eastern – Reported it to Microsoft via [email protected]
  • September 28, 2016 at 10:01 PM Eastern –  Received confirmation email from Microsoft that they forwarded the report to an analyst.

Hello,

Thank you for contacting the Microsoft Security Response Center (MSRC). I have forwarded your report to an analyst and will respond with their findings.

Thank you,

REDACTED

MSRC

  • October 3, 2016 at 11:15 AM Eastern – Sent a follow up email requesting status.
  • October 3, 2016 at 7:41 PM Eastern – Received email saying they’ve opened a case.

Thank you very much for your report.

I have opened case 35494 and the case manager, REDACTED will be in touch when there is more information.

In the meantime, we ask you respect our coordinated vulnerability disclosure guidelines and not report this publicly until users have an opportunity to protect themselves.

You can review our bulletin acknowledgment policy at http://www.microsoft.com/technet/security/bulletin/policy.mspx and our general policies and practices at http://www.microsoft.com/security/msrc/default.mspx 

If at any time you have questions or more information, please respond to this message.

REDACTED

MSRC

  • October 11, 2016 at 8:55 AM Eastern – Sent a follow up email requesting status.
  • October 11, 2016 at 4:07 PM Eastern – Received email saying they are still waiting on the product team to review the issue.

Hello,

We are still waiting on the product team to review the issue. I will let you know when I hear back from them and have information I can share.

Thanks,

REDACTED

MSRC

  • October 21, 2016 at 3:37 PM Eastern – Sent a follow up email requesting status.
  • October 24, 2016 at 4:46 PM Eastern – Received email saying still no updates.

Hello,

At this time I still do not have anything fruitful to share. As soon as I get an update, I will let you know.

Thanks,

REDACTED

MSRC

  • November 2, 2016 – Disclosed publicly on the Black Hills Information Security blog.

*Psst* If you liked this blog, we think you’d enjoy Beau’s class:

Breaching the Cloud 

Available live/virtual and on-demand!