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
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.
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.
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.
Thank you for contacting the Microsoft Security Response Center (MSRC). I have forwarded your report to an analyst and will respond with their findings.
- 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.
- 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.
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.
- 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.
At this time I still do not have anything fruitful to share. As soon as I get an update, I will let you know.
- 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:
Available live/virtual and on-demand!
November 2, 2016 @ 10:59 am
Good article, i think that you must wait a time before share and disclose this kind of vulns to fast, they gives to you a date response time to fix this vulns.
November 2, 2016 @ 1:27 pm
So..if an OWA instance was front-ended by a load balancer that redirects the initial http connection to a site presenting a 2FA screen to even get to the main OWA login….this vector would be closed? …and not until the intial 2FA occurs is the user then re-directed by the load blancer to the main OWA login…I’d think that would be suffice to mitigate.
November 2, 2016 @ 3:04 pm
FYI I believe Azure PowerShell also bypasses 2FA
November 2, 2016 @ 4:06 pm
Azure Powershell supports MFA (Modern Auth) , Exchange Online Shell does not support MFA.
November 2, 2016 @ 4:05 pm
Hi there, A few thoughts:
1. I don’t see this as a new exploit. It’s always been there because MFA has never been supported with “thick clients” on-prem. Your 2FA vendor states this also https://duo.com/docs/owa-faq Note: MFA can work on-prem. with ADFS 2016, Outlook 2013 SP1+, and Exchange 2016 ~CU4
2. If you enabled O365/Azure AD MFA and, then you would have been prompted to authenticate when you made your EWS call. Your user creds should have failed and the only way you should have been able to connect with EWS was to use an App Password. This is by design — App Passwords are used for clients that don’t support Modern Auth (MFA). see: http://bit.ly/2fwD2lk
3. I tested your code in a tenant where the user had MFA enabled. I got 401 authN errors each time unless I used an app password.
4. You can address the issue you raised by doing the following:
a. Enabling Modern Auth. on the Exchange Online tenant. http://bit.ly/2fwF050
b. Using Outlook 2013 SP1+ with Modern Auth. enabled. http://bit.ly/1G2pjr4
c. Enabling O365/AAD MFA for the user.
d. At this point Outlook 2013 SP1+ Office for Mac 2016, etc will prompt for MFA. You can then optionally disable the ability for users to create app passwords.
November 2, 2016 @ 4:21 pm
use on-premise version of Azure MFA, you could actually enable IIS authentication on your default web site/powershell. however you have no control of the cloud Azure MFA for such option. Remote session powershell will get bypassed…
November 2, 2016 @ 4:35 pm
It’s really not an issue of which MFA to use, rather whether the client will support the MFA authN prompt. So yes, you could configure MFA on the /EWS vDIR in IIS but you’ll break Exchange/Outlook client connectivity.
November 2, 2016 @ 7:13 pm
As I understand it, Outlook for Mac is the real problem here. When I complained to Microsoft directly about it a few months ago, the sales engineer claimed they themselves were exposing single-factor Exchange for their employees using Macs.
With Activesync I can whitelist devices, which is an adequate control for me. Outlook on Mac with EWS doesn’t support that. Too bad, because the client itself has finally gotten pretty usable.
November 2, 2016 @ 10:36 pm
Great write up man!
November 3, 2016 @ 4:54 am
The exposure is the same for outlook (for PC) and Outlook for Mac. The resolution I described in my earlier thread addresses this for both versions.
November 3, 2016 @ 10:14 am
1 month is not enough time. I do not agree this was responsible disclosure.
November 4, 2016 @ 8:07 am
One month may not enough time but Microsoft gave them no indication that they were actively working on a fix for this issue.
November 3, 2016 @ 12:52 pm
Regarding EWS On-premises: Have you read that DUO doesn’t protect EWS? So this is actually by design. https://duo.com/docs/owa-faq:
“Does Duo Security’s OWA application affect ActiveSync?
ActiveSync continues to work as it did prior to installing Duo. Duo’s OWA application does not add two-factor authentication to the EWS and ActiveSync endpoints. We recommend against exposing the ActiveSync endpoint to external access.”
Or did you perform a custom configuration?
Regarding Azure MFA + Exchange Online:
Did you use the same computer with PowerShell after successfully logging into OWA with MFA? Did you have to enter credentials in PowerShell? The screenshot doesn’t show.
Might want to retry with an InPrivate browser session or different computers and retest.
November 3, 2016 @ 12:55 pm
Mark – thanks for the clarification. I was the person who asked about this at Derby. I tested this on our environment, which uses modern auth. AD creds get a 401 Unauthorized. Creating and using an app password works perfectly.
So – if the O365 environment is set up in a specific way, the only MFA “bypass” is going to be an app password, under the assumption that most organizations cave in to whiny iPhone users who think native mail is the cat’s ass. Fortunately, those things are buried so deep in O365 portal, few phishing users are going to have the patience to do what the phish email says to retrieve it. Your better option is a Wi-Fi watering hole attack against iOS users, who typically use the native mail application, and get them to accept the SSL cert.
November 3, 2016 @ 1:05 pm
Generally speaking you’re correct. There are some exceptions to MFA bypass with customizations including, Azure AD Premium, ADFS claims rules, etc. but that’s outside of the scope of this article and testing.
The Outlook for Mobile app does support Modern Auth and therefore would support MFA. But, the native iOS mail/calendar/contact apps don’t support Modern Auth. So, if you have a business requirement for MFA AND your users want to use native iOS then app password for that single iOS connection is going to be required.
Michel de Rooij
November 3, 2016 @ 1:40 pm
Not telling the whole story here. When trying to repro, “The request failed. The remote server returned an error: (401) Unauthorized.” – didn’t check Duo (which as Dave mentions has en explicit exclusion mentioned). Getting a feeling of another security toko desperate for some media attention.
November 4, 2016 @ 8:08 am
Of course I didn’t try Duo – I didn’t have to, Beau did, and demonstrated the flaw, and then went on to demonstrate MFA bypass in one specific configuration of the O365 environment. The concern, naturally, is to determine if there’s a MFA configuration that doesn’t suffer from this flaw. So, the scope of what Mark was pointing out (and I validated – thanks Beau for the -Remote flag – real time saver!) was that not all MFA configurations in O365 suffer from this flaw. At least one 3rd party integration, and a specific configuration of Microsoft MFA, do.
It’s not unreasonable to assume that other 3rd party MFA integrations have the same underlying weakness as well. I presume other people will test the config they have, as standing this all up if you don’t already have an O365 tenant can be a pain in the ass, particularly when trying to procure enterprise-grade MFA to integrate.
November 3, 2016 @ 2:24 pm
This is nothing new really. But that doesn’t change the unfortunate fact that lots of organization do not have MFA/2FA enabled on their on-prem EWS virtual directory (usually because of Lync, Outlook Anywhere and Outlook for Mac). Not even in these security-centric times. Heck, this is even the case for OWA.
For security centric on-prem orgs and orgs that have moved to EXO and only use modern auth supported Exchange clients plus have Azure MFA enabled, the story is completely different though.
November 3, 2016 @ 9:46 pm
Agree with comments from Mark and Michel – from our testing the only way for this ‘vulnerability’ to work is by using authenticate as the user (who in our case has Azure MFA enabled) with an app password. To generate one of these you have to provide 2 factors of auth.
November 6, 2016 @ 12:38 am
I would not term this as a vulnerability. EWS is a leverage as a protocol for APPS. Some MDM solutions need to leverage this protocol for notifications to iOS, and so does it make sense that the Admins have to do the 2nd Factor Auth every few mins so that their solution works? 2FA authentication has a time out when the session is closed and so as to reduce load. MFA is all abt something u know, something you have and something you are.. But in this scenario it is not applicable as a vulnerability. If it is, then organizations that use Svc accounts are vulnerable as well. Security is definitely important but there are times we need to understand the balance of security and operational.
November 7, 2016 @ 8:18 am
Microsoft’s response to this discovery.
November 30, 2016 @ 1:05 pm
I found your techniques interesting especially since i’m the original author who discovered and developed several of these. Heres some more information you may have missed in your search. Let me know if you have any questions.
January 6, 2017 @ 1:21 am
I’m a student and I tested the ‘MailSniper’ in Exchange2010,and there are some problems every time I run the powershell script.
The problem is that I can’t create a folderid object with mbx and msgfolderroot,so the bind function will throw an exception that the folderid is null.
When I put the wellknownfoldername into root, it will prompt me 401 error, the problem has been mentioned above.
I am looking forward to your reply, THX!