Background

Email identities were really easy to spoof back in the 90s and early 2000s. Changing the “From” header field was enough to make friends believe an email came from their mother, significant other, or even the FBI. There were websites specially made for this purpose.

However, those tricks no longer work thanks to anti-spoofing protections such as DMARC (DKIM / SPF) and anti-spam filters. Today, emails with a spoofed “From” field either go to the spam folder or are completely rejected by the server.

Email usage is higher than ever and email is used for everything – from tracking parcels to sharing sensitive data. Unfortunately email is already not a very secure way to communicate.

We’ve seen a lot of malware spreading via emails, relying on social engineering techniques to convince users to open unsafe attachments, or click on phishing links. The rise of ransomware distributed over email clearly demonstrates the effectivity of those mechanisms.

What if there was a way to bypass DMARC protection and spoof the sender name like it was 1999? Guess what, there is!

Introducing Mailsploit

Mailsploit is a new way to easily spoof email addresses. It allows the attacker to display an arbitrary sender email address to the email recipient. In the following demo I use [email protected] but any other email address could be used.

And this is how it works: In an email, all headers must only contain ASCII characters, including the “From” header.

The trick resides in using RFC-1342 (from 1992!), a recommendation that provides a way to encode non-ASCII chars inside email headers in a such way that it won't confuse the MTAs processing the email.

Unfortunately, most email clients and web interfaces don’t properly sanitize the string after decoding which leads to this email spoofing attack.

Here is what it looks like:

=?utf-8?b?[BASE-64]?=

=?utf-8?Q?[QUOTED-PRINTABLE]?=

Either base64 or the quoted printable representation can be used.

Using a combination of control characters such as new lines or null-byte, it can result in hiding or removing the domain part of the original email, allowing us to replace it. Here is why:

• iOS is vulnerable to null-byte injection

• macOS is vulnerable to “email(name)” injection

Mixing both of them turns out to work perfectly on both OSs:

From: =?utf-8?b?${base64_encode('[email protected]')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('([email protected])')}[email protected]

Which becomes:

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

Which, once decoded by Mail.app, becomes:

From: [email protected]\0([email protected])@mailsploit.com

Using this payload, both macOS and iOS will show that the email comes from [email protected] and not …@mailsploit.com:

• iOS will discard everything after the null-byte

• macOS ignores the null-byte but will stop after the first valid email it sees (due to a bug in the parser)

In order to avoid that the victim sees a glitch when trying to reply to the email, it is enough to add a “Reply-to” field:

Reply-To: [email protected]

Here is a demonstration of the bug on iOS:

Payloads usually differ between clients, but tweaking them could eventually make most of the clients react to the same payload.

Should DKIM signatures not make this impossible?

DMARC is not attacked directly, but rather bypassed by taking advantage of how the clients display the email sender name. The server still validates properly the DKIM signature of the original domain and not the spoofed one.

While MTAs not only don’t detect and block these spoofed email addresses, they will happily relay those emails as long as the original email seems trustworthy enough (the attacker can therefore ironically profit from setting up DMARC on that email address). This makes these spoofed emails virtually unstoppable at this point in time.

Responsible disclosure

All vendors were contacted at least 3 months prior to the publication, some of them even 4 or 5 months before the publication.

The spoofing bug was found and confirmed in 33 different products. As of Dec 5th 2017, it was fixed in 8 products (~ 24%) and triaged for 12 additional products (~ 36%). Two vendors (Mozilla and Opera) said they won’t fix the bug (they consider it to be a server-side problem) and another one (Mailbird) closed the ticket without responding.

As for the remaining 12 products (~ 36%), the vendors have received the bug report but have not commented on whether they will address it.

The (non-exhaustive) list of the affected companies and vendors are available here: https://docs.google.com/spreadsheets/d/1jkb_ZybbAoUA43K902lL-sB7c1HMQ78-fhQ8nowJCQk

Certain vendors in the list are anonymized for now as per their bug bounty rules.

Solutions

Update your email client whenever a software update is available. Email will continue to play a role for decades but you can reduce the usage drastically as better alternatives to stay in touch exist.

Use end-to-end encrypted messengers for personal conversations, and at work. https://www.securemessagingapps.com is a good, independent source of recommendations for that.

If you must stick with emails then use PGP/GPG to verify the identities and encrypt email contents.

One more thing: Code injection

Some affected companies and vendors were affected by both email spoofing and code injection vulnerabilities (here, XSS).

• Example 1: Hushmail

The code execution is triggered when clicking on “Create a rule”. Their team was extremely fast to fix the issue.

Here is the payload that was used for Hushmail:

From: =?utf-8?b?c2VydmljZUBwYXlwYWwuY29tPGlmcmFtZSBvbmxvYWQ9YWxlcnQoZG9jdW1lbnQuY29va2llKSBzcmM9aHR0cHM6Ly93d3cuaHVzaG1haWwuY29tIHN0eWxlPSJkaXNwbGF5Om5vbmUi?==?utf-8?Q?=0A=00?=@mailsploit.com

Which then becomes:

From: [email protected]<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"\n\[email protected]

In this example, the HTML is inside the encoded part of the mail.

• Example 2: Open Mailbox

• Example 3: Spark and Airmail