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](https://docs.google.com/spreadsheets/d/1jkb_ZybbAoUA43K902lL-sB7c1HMQ78-fhQ8nowJCQk), 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](https://www.mailsploit.com/index#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...
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](https://docs.google.com/spreadsheets/d/1jkb_ZybbAoUA43K902lL-sB7c1HMQ78-fhQ8nowJCQk), 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](https://www.mailsploit.com/index#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 potus@whitehouse.gov 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](https://tools.ietf.org/html/rfc1342) (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('potus@whitehouse.gov')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(potus@whitehouse.gov)')}?=@mailsploit.com ``` 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: potus@whitehouse.gov\0(potus@whitehouse.gov)@mailsploit.com ``` Using this payload, both macOS and iOS will show that the email comes from potus@whitehouse.gov 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: potus@whitehouse.gov ``` Here is a demonstration of the bug on iOS: https://youtu.be/hwjUROtXV5I 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. https://youtu.be/Upbamn3PZz8 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: service@paypal.com<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"\n\0@mailsploit.com ``` In this example, the HTML is inside the encoded part of the mail. * Example 2: Open Mailbox https://youtu.be/gfAGOMeiXNI * Example 3: Spark and Airmail https://youtu.be/fyPhVIZQ44c
