Offensive Security Tool: Mailsploit

Reading Time: 7 Minutes

Offensive Security Tool: Mailsploit

Github Link

TL;DR: 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.

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.

In addition to the spoofing vulnerability, some of the tested applications also proved to be vulnerable to XSS and code injection attacks.

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]

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.

The demo is no longer available.

However, source code has been released so you may run your own server locally. Go to GitHub

Try the demo

Your email addressEmail address that should appear as the senderPayloads

Emails are not stored. Please do not send emails to someone else without their consent.

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.

About the researcher

My name is Sabri Haddouche. I am a developer, pentester, bug hunter & privacy advocate. During the day I work at Wire as part of the security team, and in my free time I dabble with projects like Mailsploit and Unsecure.

You can contact me on Wire (@pwnsdx), on Twitter or via email.

Become a Patron!