Where email authentication is potentially great – protecting against spoofing from domains with weak authentication

So, in the past couple of posts, I’ve talked about how email authentication is not that great against phishing attacks that use random parameters in the sender, but is well-designed to work against springboard spear-phishing attacks.

There’s another scenario where it is simultaneously well-positioned to protect against spear-phishing, yet not in a good position to actually defend against it.

And that’s a spear-phishing attack where the sender uses a free email account from a sender that looks like it is legitimate, but doesn’t really have anything to do with the recipient. I call this a quasi-impersonation spear phishing attack.

A quasi-impersonation spear phish is when a phisher uses a technique that tricks you into think someone important is contacting you and so you take action on it. The sender doesn’t actually have any relation to you, but you assume that they do and therefore open the attachment or click the link.

Here’s an example message:

This is an actual spear phish with the recipient removed, but the sender’s email address still intact.

1. There is no relationship between the sender and receiver, but doesn’t it look legitimate? If you’re in the finance department you may very well think that this person is invoicing you for something that your company purchased. After all, you’re busy and you see this stuff all the time, so of course you want to help out. You may not know who Russell Robinson is, but it sounds plausible.
   .
   BTW, I’m sure that there is a real-life Russell Robinson, and I apologize to that person, but his name is being spoofed in the message. The account is malicious so if you’re reading this blog post you can safely block this sender email account.
   .
2. The email address, from @outlook.com, is spoofed. The message did not actually come from Outlook.com’s email infrastructure, it came from somewhere else. Yet because @outlook.com publishes a soft fail ~all in its SPF record, and a DMARC policy of p=none, a spam filter cannot use email authentication to automatically treat it suspiciously when it fails auth. The fallback policy says not to enforce anything.Even though the domain is spoofed, if you hit Reply, the reply goes back to the sender in the From: address. Thus, the phisher is under control of that email address, yet sending from infrastructure not associated with @outlook.com.
   .
3. The grammar in the message body is correct, you could easily see that in a real-life message.

Combining all of these together, you might be tempted to click on the link to at least find out what invoice this is for. And if the link leads to malware, your machine could get infected.

So this is what I mean by a quasi-impersonation attack. The sender is not someone who you actually know (like a CEO, CFO or other high-ranked person in either your own organization or someone else’s domain you do business with), but instead who you don’t know but make sense that could have a business relationship with them. You could also potentially have a personal relationship with them if they are contacting you out of the blue, asking for a favor (such as “Hey, I read your article on your blog, I wrote something similar. What do you think?”).
.

.

Can email authentication fix this?

The key part is that the email address is spoofed. As I said in my previous post, not publishing strong authentication records means that your domain can be used in springboard spear-phishing attacks. If outlook.com were to publish a DMARC record of p=quarantine or p=reject, then any service could block this message since it failed DMARC.

Yet publishing a DMARC record for a large domain like outlook.com has its own set of challenges. While large organizations may not know who all their legitimate senders are, outlook.com does know most of its senders (I set up its DMARC records and I review the data). But the problem with going to a stronger authentication policy is that there are a lot of users on outlook.com that would lose legitimate email if a stronger authentication policy were published.

For example:

• Mailing lists that replay messages and modify the body content, yet retain the same From: address, can no longer be used on those mailing lists. This is one of the biggest complaints against DMARC.
  .
• Mail servers that forward messages to another destination have delivery problems if they modify message content (this blog post is the one with the most comments over the past few months, and generates more dissatisfaction than any other issue)
  .
• Some bulk email providers let you put free email accounts into the From: address, they will have delivery problems with outlook.com publishes stronger DMARC records
  .
• And on and on. There’s a long tail of these.

I would say that any one of these problems we could live with, but when putting them all together it becomes less plausible to live with all of those disruptions. You can publish strong authentication records in an enterprise like Microsoft where the company owns its own domain and brand and all user email associated with it, and while technically Microsoft owns outlook.com, we don’t want to disrupt all of our users. People want their email to work, so we approach publishing a stronger DMARC record with caution.

So as you can see, email authentication is in a position to stop attacks like these, yet the cost of doing it (disrupting the flow of legitimate email) is a high price to pay. It has potential, yet will be difficult to realize.

At least with strong authentication policies, that is. So how can we fix it?

Stopping spoof attacks with implicit authentication

Earlier this year, Gmail introduced a change to their UX where if an email does not authenticate, it puts a color-coded question mark in the sender photo. It means that the message did not authenticate with either SPF or DKIM:

If you hover your mouse over the picture, it tells you what that means:

Thus, the experience is degraded for unauthenticated message. In the above example, it would have qualified for a red question mark. That is one way of dealing with this type of message, if you can’t be sure if the message is legitimate (neither authentication nor content filtering is authoritative), then visual cues can warn the user to not interact with it. Machines are good at filtering, but humans are better in some cases for giving a message a second look.

But there’s another way to do it.

Note: Once again, this is all theoretical. This should not be taken to mean that it will be done this way, but rather, an idea of how things can be done.

In my previous post on springboard attacks, I went over a technique that builds off of Office 365’s Exact-Domain antispoofing. It uses a similar algorithm exact-domain spoof and extends it customer-to-customer spoof. Yet what difference does it make whether the email originates from an Office 365 customer vs. whether it originates from some random place on the Internet, be it GoDaddy, Rackspace, Google Apps… whatever?

If a sending domain is big enough, it’s going to authenticate. And the instances where it doesn’t authenticate but comes from a legitimate source – such as a mailing list, forwarder, bulk email provider, and so forth – these can all be figured out with a reasonable degree of accuracy.

This means that given a sender domain with a weak authentication, you check your own authentication history. If it fails and comes from a source you don’t more-or-less trust, then you treat it as if it did have strong authentication policies published. It’s like creating a DMARC record for domains that send you email; but while the domain owner may not know all the ways its domain is being used (e.g., on mailing list), receivers can make a reasonable guess.

Perhaps the message looks something like this: