254913 - add "phishing" detection to mail client

Status: RESOLVED DUPLICATE of bug 279191

(Thunderbird :: Mail Window Front End, enhancement)

Description

[(not reading, please use [e-mail] instead)]

add "phishing" detection to thunderbird

Talked to mscott, benb and lorenzo about this on friday.

perhaps we could add some code to help detect potential phishing emails to
thunderbird.

for example: if href url is an ip address or if href url domain doesn't match
href text domain, then it might be a phishing email.  (or something, we could
read up on http://www.antiphishing.org for what makes a phishing email.)

We could then display a bar (like the "junk" or the "remote images" bar) to let
users know "this could be a fake email intended to xyz."

if we think it is a phish email, we could display in simple html, like we do
when we think something is junk.

the order of importance would be junk, phish, then remote images, so that we at
most show one "bar" at a time.

Comment 1

[Ben Bucksch (:BenB)]

*** Bug 254965 has been marked as a duplicate of this bug. ***

Comment 2

[OstGote!]

(In reply to comment #1)
> *** Bug 254965 has been marked as a duplicate of this bug. ***

Because your bug was for MailNews this one is not TB only, is it?

Comment 3

[Ben Bucksch (:BenB)]

all: see also the descr of the dup bug.
ostgote: Seth and me were talking about the same thing. This feature should be
available in both Seamonkey and Thunderbird.

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: evil virus phish email

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 6

[Lorenzo Colitti]

Here is a snippet that turned up in my inbox today:

<strong>Click here &gt;&gt;</strong> <a
href="http://updatebilling.info/updates/" onMouseover="window.status=''; return
true" onMouseout="window.status=' '; return true"> 
http://cgi.ebay.com/ws/eBayISAPI.dll?AccountUpdate?ID=54345622773</a><br>

This would have been caught by the idea we were discussing of running the URL
parser on the link text and seeing if it matched.

This particular email also uses JS to obscure the link target. But if JS is
enabled you're pretty much toast anyway, I think. In fact maybe we should have a
warning there in the preferences panel?

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

See also bug 257307.

Comment 8

[Juan Rey]

See also Bug 264850 and Bug 264629

Comment 9

[Jean-Marc]

*** Bug 264629 has been marked as a duplicate of this bug. ***

Comment 10

[Leif Hedstrom]

Trying to do "rules based" detection of Phishing and Spam URLs is pretty hard,
we try a lot here, and it's always an arms race. Open redirects (like google and
to some extent Yahoo), HTML escaped characters, embedded images, javascript etc.
makes these things hard to detect (without some significant amount of FPs).

Since Mozilla/Firefox has knowledge of all URLs (after any encoding/JS etc.),
and subsequent redirects, it might be easier for us to do something "clever". It
might be expensive, but one idea could be to use an existing DB of known
phishing IPs and URLs (e.g. something like SURBL, http://surbl.org). We'd have
to deal with redirects, something like:

0. Get the "requested" URL, normalize/parse it
1. Check the URL domain/IP against some DB (e.g. SURBL, or some other Phishing
specific clearing house)
2. If marked as phishing, warn/stop before loading (allow for manual override)
3. If not, do a HEAD request on the URL, and see if it's a redirect (e.g. HEAD
http://www.google.com/url?q=http://www.ogre.com/)
4. If it's a redirect, normalize/parse the new URL, then go to step 1. and start
over
5. Continue loading the URL if no phishing detected.


Like I said, quite a few network roundtrips involved here, but it could be
pretty effective. Even if we don't do a network DB lookup, it would still be
useful to traverse the redirection "links", before making the "final" decision
if it looks like a phishing URL or not.

Comment 11

[Ralf Hauser]

solid phishing protection probably cannot be realized short of equipping the
user with a (personally transferrable) security token - see RFE Bug 268835 for
how mozilla could enable such a protection.

Comment 12

[Mateo]

I was about to post a new bug (feature request) along these lines when I
discovered this one.

Here is my suggestion:

- Whenever the text of an html link begins with "http(s)://" check to see if the
linked text is equal to the target url.
- If not, display a warning. It can be an icon next to the link or a "links in
this email have been dissabled top screen as we have for extension installations
in firefox).



I think this should be rather simple.
 - If a link is something like <a href="http://somesite.com">Text</a>, no action
is taken.
 - If <a href="http://somesite.com">http://somesite.com</a> (Linked text begins
with http://) it is checked to see if both are the same. If they are the same,
do nothing. If not, give a warning or disable links till aproved (as for
extensions).

This would be a great security feature, I belive.

Comment 13

[Ben Bucksch (:BenB)]

Bug 116242 would be useful for this, it should find anything that looks
reasonably like a URL to humans, even when in the middle of other text.

Comment 14

[Frankie]

Didn't there used to be a Keyword for "other competing apps have this feature"?

Eudora 6.2 ScamWatch: http://www.eudora.com/email/features/scamwatch.html

Google GMail: http://gmail.google.com/support/bin/answer.py?answer=8253

Some fairly simple patterns to start with:
 * linked text is a valid URL but different from the href
 (thunderbird is already able to detect valid URLs in text,
 since it does so in received plaintext emails)
 * javascript changes/overrides the link to a different URL,
 or calls window.status in any way.

If adding a separate "phishing" flag and UI is prohibitive,
 increasing the junk score for these patterns would work too.

Comment 15

[OstGote!]

*** Bug 274171 has been marked as a duplicate of this bug. ***

Comment 16

[Ger Teunis]

Some IMAP Anchors seem to trigger the phishing warning when using an internal IP
address (192.168.0.1) as IMAP server address.

The anchor link was:
imap://valentijn@192.168.0.1:143/fetch%3EUID%3E.INBOX.Trash%3E5099#32816
And triggered the anti-phishing dialog reporting that the link was directed to
192.168.0.1 (our internal mail server).

I think this warning should not be triggered when the target address is the same
as the IMAP server.

Comment 17

[u49640]

an other bad email i saw while browsing through my Junk folder: (just the
relevant part)

<html><p><font face="Arial"><A
HREF="https://online.regions.com/ibsregions/cmserver/users/default/confirm.cfm"><map
name="FPMap0"><area coords="0, 0, 623, 349" shape="rect" href="(phishers Adress
removed)"></map><img
SRC="cid:part1.09010701.06040700@[e-mail]"
border="0" usemap="#FPMap0"></A></a></font></p><p><font color="#FFFFFC">in 1998
AOL BMW Male Will you, please... </font></p></html>

when i moved over the image i saw the regions.com adress in the status bar, not
the actual one

PS i dont know if i sould post it here, or in Bug 279191

Comment 18

[Miles Libbey]

Re: comment 17.  There is a specific bug for showing the wrong URL with MAP
targets: https://bugzilla.mozilla.org/show_bug.cgi?id=245855.  

Comment 19

[Matthias Versen [:Matti]]

*** Bug 297001 has been marked as a duplicate of this bug. ***

Comment 20

[Reed Snellenberger]

I'd second the suggestion in #12 -- agressively highlighting the situation where
the URL in the text doesn't match the link would be a significant improvement. 
An option that disabled links with a mismatch (possibly restricting the
comparison to the link's domain) would be excellent... 

Comment 21

[Michael W. Burden]

*** Bug 302023 has been marked as a duplicate of this bug. ***

Comment 22

[Mauro Cicognini]

Excuse me for the lame question, but how does this bug differ from the
(resolved) #279191?

Comment 23

[:Gavin Sharp [email: [e-mail]]]

*** This bug has been marked as a duplicate of 279191 ***