Mailsploit: using emails to attack mail software

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.

Mailsploit

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 theFrom header.

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 Andr=C3=A9.

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.

Attacks

The Mailsploit bug has different consequences on different platforms.

Twelve email clients were found to be vulnerable to code injection attacks smuggled in through RFC-1342 wrappers. Hushmail, for example, allowed the spoofing of email addresses and injection of arbitrary HTML and JavaScript into its web-based client, leaving users at the mercy of XSS (Cross-site scripting) attacks launched from fake emails that bypassed DMARC protections.

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 controlexample.org but you want to fake an email as if it’s come from example.com.

Your maliciousFrom header looks something like this, before it’s encoded:

From: fake@example.com\0(fake@example.com)@example.org

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 fake@example.com 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.