"Mailsploit" using Emails to Attack Mail Software

"Mailsploit" using Emails to Attack Mail Software

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 other 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.

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.

->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 é, e, ? 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.

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