With the football World Cup currently underway in Russia, and inevitable news that email fraudsters are seeking to take advantage of the event, it seems an apt time for a blog on email security.

Although our topic of interest (email authentication) is a little less exciting than malware-laden fixture planners, we thought it would be interesting to share a couple of things that have come to our attention recently. These aren’t new discoveries that we’ve been clever enough to bring to light. But they most definitely fall into the category of Things We Were Surprised To Learn.

Given the tenuous football theme, we’ll call them Email Security Own Goals. They concern security peculiarities in Microsoft Exchange Online, which is part of the popular Office 365 suite. If you use O365 then you might be particularly interested to read on…

Email Security

We’re fans of email authentication – SPF, DKIM and DMARC. We know that DMARC isn’t a panacea, and we also know (from direct experience) that it can be hard for large organisations, who often have somewhat Byzantine email infrastructures, to implement and maintain operationally. But we’re a small organisation and believe that authentication is(at the very least)good cyber hygiene.

We think it’s good for organisations who receive email from us to know, with a high degree of certainty, that messages sent from our domain are from a legitimate source. We also think that it’s good that those within our own organisation know this: as practitioners concerned with security awareness (including, of course, phishing), we really don’t want to have to teach people to question whether emails from their own domain have been spoofed.

Our DMARC record is therefore set with a “reject” policy (below). The way we understand it, this policy (publicly available within DNS records) clearly states that “we’ve gone to the trouble of setting up email authentication properly so please, mail-servers of the world, don’t deliver anything which fails these checks”.

Own Goal #1

The first thing that we were surprised to learn recently (thanks to Ozan from Keepnetlabs) is that, with Exchange Online, anybody can send a message to any mailbox in your domain purporting to be from another email address in your domain – no password required! What’s more, Microsoft have published instructions of how to do it!

Pause to consider this for a moment….if you use Office 365, absolutely anybody in the world (good, bad or indifferent) can telnet into the mail-server advertised in your MX DNS record, and can issue a few commands to make it send an email from, for example, [email protected] to [email protected] This works regardless of whether or not the sending address actually exists as a valid mailbox. And at no point is a username or password required.

We should note that emails sent in this way are consistently (with our default Exchange configuration, at least) delivered into the Junk mail folder in Outlook. This is due to the presence, we believe, of an email header indicating that the sender was not authenticated by the originating mail-server. We can, nevertheless, think of several nefarious ways this “feature” can be used to exploit unwitting users – in particular since messages appear to come from an internal source. It’s also easily automatable via some basic scripting.

Own Goal #2

Following on from the above, the second thing we were surprised to learn is that Microsoft overrule a DMARC “reject” configuration, including if the above technique has been used to send the email.

Inspecting the headers of an email sent using the above method we see the following…

What this header tells us is:

  • The message failed the SPF authentication check because the sending IP address is not specified in DNS as a valid originator of emails from our domain.
  • The DMARC status is therefore “fail”, but…wait…what’s this…?
  • …for some reason our specified DMARC policy of “reject” has been replaced by something called “oreject” (see third line “action=oreject”).

Cutting to the chase, it turns out that Microsoft has decided it’s not going to reject messages that fail DMARC, even if the owner of the domain in question has made and published a policy decision that that’s what they want. Instead, they’ll mark it with “oreject” and deliver it into the Junk mail folder.

Again, pausing to consider this for a moment….by setting our DMARC policy to “reject” we are making a very clear statement that we don’t want mail-servers to deliver emails which fail authentication checks. But Microsoft has decided that they know better and delivers them anyway.

So what?

We have absolutely no axe to grind with Microsoft (having been very grateful recipients of support via their excellent Bizspark programme) but, sorry guys, it’s not cool that you’ve given external parties a direct route to send emails with spoofed internal addresses into our users’ mailboxes – in spite of the fact that we have everything set up to prevent exactly that.

Microsoft’s blog on their approach to DMARC is interesting reading – but what it fails to mention is that one of the main points of DMARC is to bring consistency to the handling of email authentication failures and to “remove guesswork from the receiver’s handling of these failed messages”.

That’s right – the whole thing is specifically designed to remove the need for mail-servers to make arbitrary decisions about what they will/won’t deliver. Those happy with an arbitrary decision have the option of not setting up DMARC and leaving it to the receiving mail-server to decide. But those of us who’ve set up DMARC have clearly stated how we want mail-servers to react in the case of authentication failures. And Microsoft are plain ignoring it.

Some might ask: what’s the problem here – you’ve said emails will be delivered into the Junk folder? Our answer would be to counter with a question of our own: what does the Junk folder, where plenty of legitimate email ends up, mean to users anyway? But that seems like a good topic for a future blog post…

Own goal image: Google and the Google logo are registered trademarks of Google Inc., used with permission.