Security operations · 5 MIN READ · ANDREW PRITCHETT AND ANTHONY RANDAZZO · OCT 2, 2019 · TAGS: Get technical / How to / SOC / Vulnerability
Remember the good ol’ days when you used to run your own email servers? Well, maybe they weren’t good days (I’m looking at you, Exchange) …
More and more orgs are transitioning from using traditional on-premise email solutions to cloud-based solutions like Microsoft’s Office 365 and Google’s G Suite. (Fun fact: Microsoft Office 365 had 155 million business users as of last year.) And it’s easy to see why: you no longer have to support all of the required infrastructure or employ a team of individuals to service complicated Exchange deployments. The data is now hosted by a third party who is responsible for encrypting the data at rest, system availability, global delivery and developing and maintaining state of the art security protocols and services.
While cloud-based email comes with some security benefits like hosted unified audit logging and modern authentication protocols — they’re still pretty new and heavily targeted by attackers. Cloud-based email systems are an easy way for the bad guys (or gals) to gain initial access into new environments or conduct other criminal activities.
You’ve probably heard that if you just enable a multi-factor authentication (MFA) solution, then everything will be sunshine and rainbows. And while MFA is a good step toward securing cloud-based email systems, it’s not a silver bullet. The reality is that MFA can be defeated by an attacker given the right resources and persistence. MFA should only be considered as one of the several security measures an organization should employ rather than the end-all-be-all.
Regardless of whether you have MFA enabled or not, it is important to layer your security controls to strengthen your overall security posture. Even if your organization doesn’t have the means to enable MFA, we highly recommend reading further to understand some additional risks to your cloud email environment and ways to reduce that risk.
Disable legacy email protocols
There are a bunch of email protocols and services in use today: Exchange Web Services (EWS), Messaging Application Programming Interface (MAPI), Exchange ActiveSync (EAS) … the list goes on. While most of these common email services and applications support MFA, some of the legacy email protocols don’t.
For example, the IMAP and POP email protocols are the two you should disable immediately. These protocols don’t support MFA by default and will fully circumvent MFA with single-factor authentication. That means if an attacker phished the credentials of one of your users, then he or she can easily access that user’s entire inbox if authenticating via an IMAP or POP client (and trust us, this will probably be the first thing they try).
Another big concern with IMAP and POP are that they expose too much data to the client application. Different clients have different sync settings by default and this determines how much of the mailbox is actually downloaded after a session is created. Attackers can obtain an entire copy of a user’s mailbox in order to search and parse offline for sensitive data. Another shortcoming with these protocols is that there’s usually no logging available to determine exposure once you find an account compromise via IMAP or POP. In many circumstances, your security leaders would consider the entire mailbox exposed.
G Suite usually has these protocols disabled by default. However, if somewhere along the road your admins enabled it for any of your users, it’s fairly simple to disable.
O365 is another story, though. IMAP and POP are enabled by default and must be manually disabled across the tenant. If your user base is using IMAP or POP clients, particularly mobile clients, this could impact their ability to access email and may require them to authenticate with a new email client that supports MFA. As a helpful reminder, if you have multiple tenants, you will need to apply these actions to all of your tenants.
If you determine that it’s catastrophic to end-user experience to get rid of these protocols on your tenant, then consider using global and conditional access policies to prevent employees from using these protocols under certain circumstances. (More on conditional access in a bit.)
Disable basic authentication for all email protocols
Is your org’s IAM team getting woken up in the wee hours of the night thanks to a ton of Azure Active Directory, G Suite or cloud IAM (Okta/Duo) account lockouts from unauthorized access attempts?
Here’s the primary culprit. (You’re welcome — and cheers to now getting a full night’s sleep.)
O365 currently has two implementations of authentication: basic authentication and modern authentication (Microsoft’s OAuth2). Because basic authentication is enabled by default, this allows older email clients that do not support modern authentication to bypass MFA as well. The protocols that allow for basic authentication in O365 are ActiveSync, Autodiscover, EWS, IMAP4, POP3, and authenticated SMTP. Now, even if you’ve disabled the IMAP and POP protocol as described in the previous section, the attacker can still attempt to authenticate (via credential stuffing, password spraying, or brute force), which in turn will create an abundance of account lockouts! Microsoft has released some good news though. In October 2020, they will no longer support basic authentication in O365, but in the meantime, you can disable basic authentication yourself. Remember that this could have a major impact your end-user experience, and may require using a different email client. On October 1, 2019, Microsoft released conditional access policies in audit-only mode, which can help measure this impact to users.
If you’re interested in the current use of IMAP/POP and other basic authentication sessions in O365, we’ve found that the user-agent string CBAInPROD is a pretty good indication of this activity. Check your Azure AD logs for signs of this if you’re uncertain of your current Exchange configurations. It can be found in the ExtendedProperties of UserLoggedIn operations logs.
G Suite also provides support for less secure apps (email clients). This too is disabled by default, but if you find it is enabled for users in your G Suite account, you can disallow sign-in from these apps.
Enable conditional access policies
Conditional Access enables administrators to apply policies (or multiple policies) to control who and what has access to apps in your environment. Conditional Access policies are enforced after the first-factor authentication has been completed but before the user is granted access to the environment. Therefore Conditional Access can evaluate multiple “signals” against your policies to determine success against certain pass/fail conditions. These “signals” include:
✓user and/or group membership
✓IP location information or ranges
✓users device type, state or use patterns
✓attempted access to applications
✓real-time and calculated risk detection as well as other features unique to each service provider
If your org only services customers in one region of the U.S. and all of your employees reside and operate within the U.S., do you need to allow authentications from China, Russia and the Netherlands?
Conditional access policies in O365 are another security measure which is relatively easy to enable and go a long way in supporting the effectiveness of MFA. Policies can be configured within an administrative session on the “Azure Conditional Access” tab.
For G Suite, conditional access policies are most often configured via a third-party SSO agent or MFA client such as Okta and DUO respectively.
Much like enabling MFA, whenever you make policy changes to authentication protocols, consider any adverse reactions to critical production systems and processes. We recommend making any of these changes in a phased roll out so that you can closely monitor changes for several days before implementing the next set of changes.
Any one of these security measures will strengthen your security posture — but combined they complement each other to make your organization far more resilient against business email compromise (BEC) and unauthorized access.
