1249562 - Unexpected Behaviour in Mozilla ThunderBird That Assists Phishing Attacks

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[Mazin Ahmed]

Attachment: PoC.txt

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151210084841

Steps to reproduce:

Hello,

I have found a vulnerability that affects Mozilla ThunderBird, that
leads to unexpected behavior, and can be used in performing
watering-hole attacks.

The issue can be reproduced when a user send a <form> and <input> HTML
attributes within the email. ThunderBird fails to render the <input>
tag, and causing it to be opened by Firefox or the default browser once
the user navigates to the email.

This can be used in performing Social Engineering attacks and Watering
Hole attacks, as the victim would not expect this behavior. An attacker
can point the form to an executable file that will be downloaded once
the user opens email. Also, it can be used as a vector in phishing attacks.

Proof of Concept:-
http://secbot.me/0bin/?09b54e6a0d2ee063#zrcVDQQQxMvqOswz20RRAFtOievmNyFcZDkaWsusY04=


Best Regards,
Mazin Ahmed



Expected results:

The <input> and <form> HTML attributes should habe been stripped from rendering. Also, it should to lead the current behavior of opening link automatically.

Comment 1

[Magnus Melin [:mkmelin]]

There's no automatic opening of the form. That requires the user clicking in the form and it is expected that we open the form for filling in the browser instead on such occasions (so the user can have all the usual ways of knowing where he is and where the data would be submitted).

I don't think there's much of an issue here. There's always social engineering ways to trick users to follow a link, and your case is not really different from that.

Comment 2

[Mazin Ahmed]

Yes, I understand that, but the difference here that there is way that a normal sender sends an email with <input> and <form> tags. I can't think of any occasion that is needed to have those tags in an email. 

If someone would the user to act by submitting the form, he would actually share a link to the form, he wouldn't embed it.

Comment 3

[Magnus Melin [:mkmelin]]

Not good practice, no. But you get what you ask for - and if it happens to be something legit I think the current behaviour is a good trade-off. Conversely, if you for some reason want something that look like a button to show up in an html mail you can always achieve that e.g. by embedding an inline image. So disabling rendering of certain elements is pretty moot.

Comment 4

[Adam Muntner [:adamm] (use NEEDINFO)]

Thank you for your report.

I don't see anything that make this inherently more dangerous than a phishing attack, both require user interaction and tricking someone to follow a link. 

The executable file triggers a dialog box for how to handle it, this unexpected unusual behavior would cause most people to be suspicious, making it less useful to attackers by virtue of likelihood of making a target more cautious.  

This is also more of a phishing attack than a watering hole attack. Example of watering hole attack: http://krebsonsecurity.com/tag/watering-hole-attack/

All that aside, I agree with the reporter that <input> and <form> tags should not be rendered. There is no reason to render them, and a good reason not to: it makes a phishing attack marginally easier. 
Most importantly, because the tags aren't necessary, stripping them will immunize us against any other possible issues that are lurking in their handling. 

So while I'm setting the risk to low, I would urge the Thunderbird project to prioritize this patch.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

Minusing for a bounty because this is a "low" rated security issue and does not qualify because of that.

Comment 6

[Josiah Bruner [:jsbruner]]

Attachment: form-phishing.eml

I'm going to try to tackle this as it's a pretty interesting issue.

An .eml containing the suggested PoC is attached (with a modification that makes it try to download from localhost:8000/download-me instead of the provided URL). The SHA 256 hash of it is: 982f72dd27755f9ec9a19fe3cefe7eef13b73298dfa4d6e65f622f6bacedbeee

There are at least two ways to handle this:

1. Don't render <form> or <input> tags period.
  1.1 Prevents the issue entirely (no way for user to bypass it) from TB's perspective.
  1.2 However, will either require us to tamper with the message and strip the tags or to change how gecko renders certain elements. Maybe it's easy to prevent gecko from rendering such elements, but I am not aware of how to do that.
  1.3 In addition, there is no indication to the user that the sender / email is likely malicious. They may open the email on another client and be exposed to the issue.
  1.4 This may break the layout of "legitimate" emails.

2. Make <input> or <form> tags trigger our Scam detection and disable all remote content and the ability to navigate away from the email. (I think scam detection already does that?)
  2.1 Prevents the issue unless the user chooses to ignore the warning.
  2.2 Enables us to handle the email in a "read-only" fashion. Detection can be done purely in TB source rather than requiring us to modify our gecko configuration.
  2.3 Scam warning will likely cause the user to delete the email, which is good.
  2.4 This could cause "legitimate" emails to be classified as a scam. <-- Maybe not a bad thing?

Comment 7

[Josiah Bruner [:jsbruner]]

Attachment: bug1249562.patch

This patch now changes Thunderbird's behavior to automatically mark all messages which use <form action="foo"> as phishing attempts. This <form> with "action" attribute was the root cause of the PoC, so I'm leaving <form>s without "action" and <input> tags untouched.

This check is done when the newly add pref (mail.phishing.detection.disallow_form_actions) is set to true (the new default).

[ NOTE ]

Also, while I was around this code I fixed a conditional in analyzeUrl so that we check for the potentially empty param aLinkText.

[ VERIFICATION ]

To test this, do the following:

1. Download the form-phishing.eml file
2. Launch TB without my change and open that email.
3. You should not be warned of a potential scam. Clicking on the body of the email will open http://localhost:8000/download-me in your browser.
4. Now close TB and apply my patch.
5. Repeat steps 2-3 : This time TB should warn of a potential scam.
6. Now go to about:config and set mail.phishing.detection.disallow_form_actions to false
7. Open form-phishing.eml again. You should not see the warning.
8. go to about:config and set mail.phishing.detection.disallow_form_actions to true
9. Open form-phishing.eml again. You should see the warning.

[ REVIEW ]

aceman, can you review this? I'm not sure who the right person is. Feel free to redirect if you want.

Comment 8

[:aceman]

Comment on attachment 8982711 [details] [diff] [review]
bug1249562.patch

Review of attachment 8982711 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks. While I could technically review this, the change probably needs higher level decision about whether we want to show a phishing warning on any form.
The comments even suggested to not render any form tags in emails. I'm not sure that is feasible.
I'd think companies can send forms via email to make surveys inside companies. Yes, they could set the pref to disable the phishing warning, but then it would apply to all (even external) emails. Maybe a pref for whitelisted domains would be useful? Or maybe you could use the existing whitelist of senders/domains that can show external images and for these there would be no warning?

Comment 9

[Magnus Melin [:mkmelin]]

We already do not support filling in forms in the mail, so I don't think we need to use a whitelist.

Comment 10

[Josiah Bruner [:jsbruner]]

Attachment: bug1249562.patch

I updated the patch to add a test which makes sure we warn about emails containing a <form> with an action attribute.

Comment 11

[Ben Bucksch (:BenB)]

Form actions should always be disallowed in emails, be it a recognized as phishing or not.

I thought that Magnus had already created a patch to do that in the message body viewer, 1-2 weeks ago, following eFail. See bug 1462910 and attachment 8981239 [details] [diff] [review] = https://hg.mozilla.org/comm-central/rev/09e20d5562bd881d9743e77bc5d1ea85a466d758.

Could you please check TB trunk with that patch? If I understand the patch here correctly, it should be unnecessary now. But I might be misunderstanding...

Comment 12

[Magnus Melin [:mkmelin]]

Comment on attachment 8984761 [details] [diff] [review]
bug1249562.patch

Review of attachment 8984761 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, r=mkmelin

Yes, forms are now disabled on two levels (in addition to this), so actually submitting the form would not happen. Either way, if the mail contains a form, it's suspicious enough that we should flag it like this.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5df955257afb
Mark messages using <form>s with action URLs as phishing attempts by default. r=mkmelin