About that DMARC "exploit"

A security researcher has identified a rendering flaw that allows for “perfect” phishing emails. From his website:

Mailsploit is a collection of bugs in email clients that allow effective sender spoofing and code injection attacks. The spoofing is not detected by Mail Transfer Agents (MTA) aka email servers, therefore circumventing spoofing protection mechanisms such as DMARC (DKIM/SPF) or spam filters. Mailsploit website

While this is a bit of a problem it’s mostly a problem with the email client (MUA) not the email servers involved.
The short version is that an attacker creates an email address in a domain they own. The address includes a null value encrypted in the local part of the email address. When the email client get a hold of the address it displays the address up to the null value and drops everything after that.
For example

From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com

Decodes to

From: potus@whitehouse.gov\0(potus@whitehouse.gov)@mailsploit.com

Due to a rendering issue different systems end up displaying simply From: potus@whitehouse.gov.
Mail displayed on clients vulnerable to this exploit will be DMARC authenticated for a domain that is different than the domain displayed to the user.
The big problem here is in the email client and how they display to the user. While this is creative, it’s not that much different than using “POTUS <spammer@spamdomain.invalid>”. Display names are a problem, but they’re a problem that has to be addressed by individual mail clients. The choice to display only the comment is a problem.
Maybe this exploit will motivate email client maintainers to rethink their decisions on what to display to users. Their current choices and implementations are vulnerable and need to be improved.
 
 

Related Posts

Ask Laura: Confused about Authentication

AskLaura_Heading3

Read More

Tools!

I just added a DMARC validation tool over on tools.wordtothewise.com.

You can give it a domain – such as ebay.com – and it will fetch the DMARC record, then explain and validate it. Or you can paste the DMARC record you’re planning to publish into it,  to validate it before you go live.
If you’ve not seen our tools page before, take a look. As well as DMARC we have a DKIM validator, SPF expander and optimizer, general DNS lookup tools, a bunch of RFCs covering all sorts of protocols, and base64 and quoted-printable decoders.
There’s also a widget that lets you add those little unicode pictures to your subject lines, whether you need a snowman ⛄, a forest ????, or a pig getting closer ???.
The results pages all have easily copyable URLs so they’re pretty good for sharing with co-workers or customers if you need that sort of thing.
(And if you need a cidr calculator, whois, or easy access to abuse.net & Microsoft SNDS check out Al’s xnnd.com.)

Read More

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More