DMARC: an imperfect solution that can make a big difference

Posted by   Martijn Grooten on   Jul 24, 2017

US Senator Ron Wyden has written a letter (pdf) to the Department of Homeland Security, urging the US government to implement DMARC to "ensure hackers cannot send emails that impersonate federal agencies".

DMARC is an email security standard that was launched by a few major players in the field of email in 2012, and has since been adopted fairly widely, though as evidenced by Wyden's letter, far from universally.

dmarclogosmall.png

To understand the role DMARC plays in email security, it should be noted that email hasn't changed significantly since its invention in the early 1980s. If an email claims to come from joebloggs@example.com, then the recipient is supposed to assume that this was indeed the sender of the email. After all, on the Internet everyone can be trusted. While this was more or less true in the 1980s, it certainly isn't true today.

The fact is that, despite its misgivings, email works really well, and attempts to replace it with something that has better built-in authentication have failed. Instead, two new standards have been introduced that add some kind of authentication to email, namely SPF and DKIM.

SPF lets domain owners publish a list of IP addresses from which emails from that domain are sent, while DKIM lets mail servers link a domain name cryptographically to an email. So if you receive an email from joebloggs@example.com that comes from an IP address that is listed by example.com as one it uses to send email, and that is cryptographically signed by one of example.com's mail servers, you can be fairly certain that it was indeed Joe who sent the email (or at least someone with access to Joe's email account).

But what if the email doesn't come from one of the IP addresses SPF lists, or it doesn't have a (valid) DKIM signature? That's where DMARC comes in: DMARC allows a domain owner to indicate what a receiving mail server should do with such emails – for example, inspect them a bit more closely (and thus increase the likelihood of them being blocked), or discard them altogether.

You might think that a domain owner could just set up SPF to list all of their IP addresses, make sure all outgoing emails are DKIM-signed, and then use DMARC to tell the world that any email failing the checks should be discarded. Unfortunately, it is not quite that simple, for two reasons.

First, there are valid reasons why SPF is sometimes broken, and why a legitimate email may arrive without a (valid) DKIM signature. It is possible for a sender to prevent this, but this requires very strict guidance on how email is used and would probably mean moving all human users to a separate domain. (This is the reason why PayPal employees use paypal-inc.com rather than paypal.com, which is used solely for notifications.)

Secondly, rather than see their emails blocked, phishers could simply move to a different domain. Maybe one that closely resembles the original one, like exmaple.com or example-official.com, or maybe a different domain altogether. After all, users often don't look at the domain of the supposed sender of the email, and some mail clients, especially those on mobile devices, don't even show the sender.

However, while this means that DMARC isn't a perfect solution to the phishing problem (and Wyden is wrong in his suggestion that it would stop hackers from being able to impersonate federal agencies), it can still make a notable difference. DMARC either increases the likelihood of the email being blocked if the phisher uses the real domain, or if they don't, they are forced to use a domain with a lower reputation, which again increases the likelihood of the email being blocked.

Security in general, and email security in particular, is full of imperfect solutions that actually make quite a big difference; DMARC is just one of them. Maybe we ought to appreciate them a bit more – and the DHS should definitely listen to Ron Wyden's suggestion!

You can find more on DMARC in a VB2014 paper presented by Microsoft's Terry Zink, the video of which is shown below. In his presentation, Terry looked at a neat feature of DMARC, where it can be used to receive automatic feedback on emails from your domain that fail SPF or DKIM, thus not only providing insight into impersonation campaigns, but also helping find 'forgotten' mail servers, thus using DMARC to ultimately make DMARC more powerful.

 

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2019 paper: Fantastic Information and Where to Find it: A guidebook to open-source OT reconnaissance

A VB2019 paper by FireEye researcher Daniel Kapellmann Zafra explained how open source intelligence (OSINT) can be used to learn crucial details of the inner workings of many a system. Today we publish Daniel's paper and the recording of his…

VB2019 paper: Different ways to cook a crab: GandCrab Ransomware-as-a-Service (RaaS) analysed in depth

Though active for not much longer than a year, GandCrab had been one of the most successful ransomware operations. In a paper presented at VB2019 in London, McAfee researchers John Fokker and Alexandre Mundo looked at the malware code, its evolution…

VB2019 paper: Domestic Kitten: an Iranian surveillance program

At VB2019 in London, Check Point researchers Aseel Kayal and Lotem Finkelstein presented a paper detailing an Iranian operation they named 'Domestic Kitten' that used Android apps for targeted surveillance. Today we publish their paper and the video…

VB2019 video: Discretion in APT: recent APT attack on crypto exchange employees

At VB2019 in London, LINE's HeungSoo Kang explained how cryptocurrency exchanges had been attacked using Firefox zero-days. Today, we publish the video of his presentation.

VB2019 paper: DNS on fire

In a paper presented at VB2019, Cisco Talos researchers Warren Mercer and Paul Rascagneres looked at two recent attacks against DNS infrastructure: DNSpionage and Sea Turtle. Today we publish their paper and the recording of their presentation.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.