The most basic tenet of secure programming is this: don’t trust anything you’re planning to consume.
Why? Because computer programs consume things from the outside world – like files, cookies, voice commands, passwords and a multitude of other data types – and things can go badly wrong if they ingest something they shouldn’t.
Programs can be poisoned accidentally, by glitches in the data they consume, or deliberately by hackers trying to feed them morsels designed to kill them or turn them, zombie-like, into unwitting accomplices.
In either case, life for your computer program is a bit like wandering around in a forest and trying to work out which fungus to eat for breakfast. The ones that kill you stone dead have a nasty habit of looking like the ones that go well with some bacon and grilled tomato.
If your computer program is going to last it needs to be suspicious, and that means assuming that everything is a throbbing, knee-high Death Cap mushroom, until proven otherwise.
Computers have been “in the forest” and receiving emails for about 45 years now, so your email software ought to be pretty good at seeing every email received as a potential Deadly Dapperling.
Emails consist of three parts: the message itself, any attachments and a collection of headers that set out (amongst other things) who the email should be delivered to, its subject and who it’s from.
Unlike attachments, where almost anything goes, the headers are governed by pretty strict rules, rules that ought to make identifying an email with a harmful header easier. The
From header, for example, is supposed to contain the name and email address of a message’s author (or authors).
It was a surprise them, to learn that somebody has discovered a way to use malicious email addresses, smuggled in through the
From header, to bypass anti-spam protections and, in some cases, trigger the running of arbitrary, hostile code.
The discovery was made by bug hunter Sabri Haddouche, who recently published information on a quease-inducing BWAIN (that’s a Bug With An Impressive Name), a coding mistake that seems to have been repeated over and over by dozens of different email applications.
He calls his discovery Mailsploit:
Bugs were found in over 30 applications, including prominent ones like Apple Mail (macOS, iOS and watchOS), Mozilla Thunderbird, various Microsoft email clients, Yahoo! Mail, ProtonMail and others.
How not to eat email addresses
Email, being as old as Prototaxites, only allows characters from the ancient ASCII set to appear in headers. That’s fine if you want to send an email and your name is Andrew but not if your name’s André, because ASCII only supports 128 characters and é isn’t one of them.
With only 128 characters to play with and a world of non-English names to support RFC-1342 was drafted in 1992 to allow exotic things like é, ε, э and tens of thousands of other characters (including latter-day essentials like the Pile of Poo emoji), to appear in the
RFC-1342 details a way of using the 128 ASCII characters to represent the hundreds of thousands of non-ASCII characters, using either the Quoted Printable or Base64 encodings (André becomes
Andr=C3=A9 in Quoted Printable and
QW5kcsOp in Base64).
A header that arrives wrapped this way has to be unwrapped before being shown to the email’s recipient so they can see they have an email from André rather than
What Haddouche seems to have discovered is mail software that’s entirely too trusting:
Unfortunately, most email clients and web interfaces don’t properly sanitize the string after decoding which leads to this email spoofing attack.
Without that sanitisation, an attacker can try their luck at smuggling all manner of malodorous payloads into the guts of your mail software via the
From header, provided it has an RFC-1342 wrapper.
And that’s exactly what Haddouche did.
The Mailsploit bug has different consequences on different platforms.
Hushmail, to their great credit, fixed that bug the same day it was reported.
Others have not been so quick to act and Haddouche has published a Google Doc detailing affected vendors and their responses to his bug reports.
The most common problem uncovered, and the most talked about, is the attack’s ability to bypass DMARC, an anti-spoofing protection. If an email’s
From header contains an address the sender isn’t authorised to use then protections like DMARC are supposed to stop from being delivered.
Mailsploit can be used to wrap an email address an attacker isn’t authorised to use, inside one they are authorised to use.
Let’s say you control
example.org but you want to fake an email as if it’s come from
From header looks something like this, before it’s encoded:
After you’ve encoded it, you send the email and the receiving Mail Transfer Agent (MTA) interprets what arrives like this:
From: <some RFC-1342 encoded data>@example.org
DMARC checks show that you are allowed to use
example.org, so the email isn’t treated as spam (this is the correct behaviour). It delivers the mail to your victim’s inbox and later they view it using their email client of choice.
The RFC-1342 encoded data is then decoded and, if you’ve formatted your malicious payload correctly (the correct formatting varies slightly across different applications), the receiving email client is fooled into using the address
firstname.lastname@example.org in the victim’s from field.
Attacks typically exploit mail clients by including null characters (the
\0 in the example above), newline characters, or a combination of the two, that causes the client to discard everything in the header that follows them.
The crack the attack slips through then, is that MTAs authenticate using one domain and email client software can be fooled into displaying another.
What to do?
The DMARC bypass is interesting, real, and being used in the wild but should be spotted easily by anti-spam engines.
It’s worth bearing in mind too that while DMARC makes things better, it was never an impenetrable forcefield. It depends on both SPF and DKIM, and plenty of unknown mail can’t be properly judged because of casual settings like SPF records with a
~all default, while plenty of bogus mail also passes DMARC tests unmolested because it comes from fraudulent or hacked accounts on real servers like Gmail.
Email users should update their software as soon as updates become available.
Programmers, don’t rely on other parts of the system to feed your code properly, and if your inputs can be wrapped, zipped or encoded be sure to sanitise them after they’ve been unpacked.
2 comments on “Mailsploit: using emails to attack mail software”
Interesting discussion, Mark, and well-stated. But fixing this does nothing for the even older trick of using a bogus display name. That fools all the non-techies who believe their email screens which “helpfully” show only the display name and not the addr-spec. This dates back to RFC-822 which pre-dates RFC-1342 and the current address RFC, 2822.
DMARC may prevent this trick, but if it does, then Yahoo! certainly isn’t using it because I get a few emails each day like this.
For readers’ benefit, I’ll outline how this works. I’ll use these square brackets, [ and ], to represent angle brackets. Your full email address might be:
“Mark Stockley” [mstockley AT example DOT com] where “Mark Stockley” is the display name and [mstockley AT example DOT com] is the addr-spec. Email providers don’t care what you define as the display name. The display name is optional. If you omit it, the addr-spec is displayed instead.
Thus it’s simple to get an email address from Google, Microsoft, Yahoo, or AOL and change the display name to president AT us DOT example or putin AT ru DOT example while leaving the addr-spec as the actual email address. Non-technical folks are used to seeing the addr-spec in their display because it shows up whenever an email with no display name is received. You would think that Yahoo! could try a simple algorithm like this:
If display-name contains “@”, then show addr-spec
else show display-name
but they don’t.
I think my son first did this to me back in 1994.
Great intro, with some fine writing to follow it. Thanks, Mark.