Dear RIPE: Please don't encourage phishing

Mailman List Mirror (Read Only)
21

Freakonomics recently aired a story about the problem of getting Doctors to follow hand hygiene rules and wash their hands as frequently as they are supposed to (upon entering and leaving each patient's room) to avoid spreading disease. One of the biggest problems with changing behavior with doctors (and with technical people) is that the smarter people are, the more they chafe at being told they aren't doing things the correct way.

The most effective step they took to counter-act the hand-washing problems was using a screen-saver on all the public terminals, showing the consequences of not-washing - an image of a petri dish showing the bacteria results from a hand-print of a doctor's hand.

http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hands-visual-edition/

If you wanted to have a similar effect at $workplace, try a similar visual (e.g. a mockup of 2 screenshots, first clicking on a link in email then typing in a password on a webpage with a phishing URL (with a typo)) as the screen saver on all company computers; as the first slide in all in-house ppt presentations; on the wall at all card-lock entry doors, etc.

jc

22

I agree. Training your customers/clients to click on URLs in email
messages is precisely equivalent to training them to be phish victims.

I teach people to (carefully!) bookmark the sites that they use which
require passwords, and to always use those bookmarks -- that is, *never*
to use the links in any mail message or on any web page.

(Of course, an attacker in control of their browser could manipulate the
bookmarks, but there is little reason for an attacker who's already gotten
that far to do so.)

---rsk

23

The problem is you need the 3rd visual...

a picture of an abandoned factory, with the doors flapping in the wind,
bceause the company went out of business because someone got spearphished.

Cheers,
-- jra

24

Has this ever been spotted in the wild? Serious question - most of the well-publicized
spearphishing attacks lately the victim company is still around.

25

I don't know that we would have any way to know that a demised company went
down due to a spearphish... but yes, I was exaggerating.

Cheers,
-- jr 'hyperbole and a half!' a

26

In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter wrote:

Windows has had its own centralized certificate store and APIs since
NT 4.0's release in 1996.

You are correct that I maligned Windows in a way I shouldn't have
done. Indeed, I've been very impressed with the software they make
to manage certificates in the enterprise before, making it quite
easy to roll out per user certificates for VPN's or E-Mail and dump
it in the certificate store.

I think my view was incorrectly colored by the fact that the API
is not used by many programs (open source in particular) where as
OSX has had some traction with the Keychain.

It would be nice to get something approximating a cross platform API,
even if all that means is the ability to do the same operations on all
major platforms.

27

So because of phishing, nobody should send messages with URLs in them?

more and more these days, i have taken to not clicking the update messages,
but going to the web site manyually to get it.

Yup -- I wrote about that a while back (SMBlog -- 2 October 2011)

waaaay to much phishing, and it is getting subtle and good.

What's the line -- "I know I'm paranoid, but am I paranoid enough?"

    --Steve Bellovin, Steven M. Bellovin

28

The really hard parts are (a) getting the users to pay attention to the
validation state (or, more precisely, the lack thereof on a phishing
email, and (b) get them to do it *correctly*.

Some of the browser password managers have protection against phishing as
a very useful side-effect: if they don't recognize the URL, they won't pony
up the correct login and password. That's much better than hoping that
someone notices the absence of a little icon that means "this was signed".

The "correctly" part has to do with the PKI mess.

    --Steve Bellovin, https://www.cs.columbia.edu/~smb

29

"Just because people say you're paranoid, that doesn't mean that there
*aren't* people out to get you."

Cheers,
-- jra

30

The problem space is that most folks won't catch the difference
between an email and link from ripe.net, ripe.org and ripe.ca. The
game is lost long before a purely technical version of validating the
message source becomes an issue.

Regards,
Bill Herrin

31

In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:

The problem space is that most folks won't catch the difference
between an email and link from ripe.net, ripe.org and ripe.ca. The
game is lost long before a purely technical version of validating the
message source becomes an issue.

You're reply is along the lines of what several other folks have
told me privately, and I think they all miss the mark of where I
am going with my suggestion.

Hypothetically, I get an e-mail from ripe.ca, which uses some trick
(perhaps as simple as HTML text and link that go to different places)
to visually show me ripe.net and actually sends me to ripe.org.

Let's also assume I have a ripe.net account and have been to that
web site before.

The software can do a pile of things that make life better for the user:

1) When I reach ripe.org (from the phish above), my browser can say:

   "This is an SSL web site asking for a login and password, and yet,
    you've never been here before. Maybe you would prefer to register,
    or leave if you came here incorrectly."

   That's all client side UI, and would make even novice users stop
   and think about what happened.

2) Let's say the e-mail was signed, by ripe.ca, the original sender.
   When my e-mail client passes the URL to my browser, it can also pass
   the details of the ripe.ca key. My browser can then say "You got
   an e-mail from Key ABC, but went to a web site run by XYZ, are you
   sure this is what you want to do?" Of course if everything matches,
   it can be silent.

Specifically I am NOT suggesting to ever trust a root-CA, or the
details in a certificate. Indeed, browsers could ship with no
certificates what so ever in my scheme. The key is comparing
multiple sources of information. Most folks might not know the
difference between ripe.ca and ripe.net. The existing CA scheme
may allow both of them to get the common name "Réseaux IP Européens",
confusing even the technical who look close. But it's trivial for
the software to say Cert in E-mail != Cert in Web, or even that
they don't have a common branch in the tree (in a large org they
may have the same parent, for instance).

As I've also said, a good UI feature would be the ability to add a
description to a cert locally. Once I'm sure my banks web site is legit
I should be able to add "Leo's Bank" in the cert store locally. Now
when my web browser or e-mail client use that cert to validate a message
they can display "Leo's Bank" next to it. I can easily look for that
and know I went back to the same place. I click on a link in my e-mail
and see no description, I know something went wrong.

Does my scheme stop all phishing. Heck no. If we wait for a perfect
solution we'll never have any solution. Look at NANOG. Bandy Rush is
here somewhere. It's why many years ago I set my mailer to PGP all
e-mail to NANOG. See an e-mail from me not signed, don't trust it.
Does that stop all impersonation on NANOG. Heck no, but if we all did
it, and subscribed to the web of trust, it would all but stop it.

Users hate encryption and ignore the warnings not because they don't
want to be secure, or are idiots. They do it because the darn software
is broken, confusing, and has the worst UI's ever invented. If the
industry fixes it, encryption will be much more widespread. Small
steps, like banks allowing users to upload an cert to their account
profile, and then communicate via two-way authenticated e-mail would go
a long way to traning the user community how this should work. End user
ISP's (cable, DSL) issuing e-mail certs automatically and installing
them as part of their install package would be a quantum leap forward.

It's not hard, people just don't do it.

32

> So because of phishing, nobody should send messages with URLs in them?

more and more these days, i have taken to not clicking the update messages,
but going to the web site manyually to get it.

Web site? With the RIPE db one communicates using PGP email for data
in and port 43 queries for data out. The web site is for signing up to
RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into
new fancy guish junk, and tend to forget how things should be done, and
some things -- the horror! -- are only possible to accomplish using the
web site and some forgotten password. To me, that is much more annoying
than the side projects that people are griping over.

</rant>

waaaay to much phishing, and it is getting subtle and good.

Indeed.

33

Because banks and many other institutions have prioritized all-singing,
all-dancing, bloated, horribly-badly-marked-up HTML email with
"stationary" and logos and pictures and web bugs far, FAR ahead of
security, privacy, accessability, portability and other -ilities that
I'm too lazy to enumerate just now. Besides: it's not like it's *their*
accounts that will get hosed or *their* money that will get lost.
Things like that only happen to the little people.

See also this related note:

  http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html

---rsk

34

There used to be the old programming benchmark of how large a "program"
(in lines, as well as compiled bytes) it took to say "Hello, world."

The 21st century benchmark might now well be the size of a "Hello,
world" e-mail.

Or a web page with a similar statement.

Jeff

35

You know, clickable objects in automated business communications are a
standard practice,
the larger the organization sending the message, the more complicated
and annoying their standard e-mail template full of HTML eyecandy, the
more clickable links to improve accessibility, and banks among the
worst offenders.
Those encourage phishing, because HTML just provides way too many
methods of faking a URL, or making a 'button' or 'link' go to
somewhere else besides what is suggested by the e-mail text.

All an e-mail user needs to do is click on one unknown link, to be
quietly diverted to a fake website, that will then ask the user to
"change" a password; it makes no difference whether the e-mail
itself is about passwords or a security issue or not.
Convincing the user to "log in" can be done while they are visiting
the fake website.

There are plenty of phishers that rely on convincing users to hit the
'reply' button and divulge sensitive info, with no clickable items
in the message at all.

But this particular item from RIPE here appears to be a plain text message...
text/plain

The message from RIPE is darn benign, and does not really encourage
phishing moreso.
When was the last time you saw a phishing attempt in a text/plain
e-mail showing the name of a HTTPS location
on the real organization's web site ?

If sending out a web address "encourages phishers", then what are
they supposed to provide to make sure maintainer users can easily
and quickly change their password?

RIPEs not encouraging phishing by sending such a message. MUA
developers who included text/html MIME type support and support
creating clickable objects in a HTML message have encouraged
convincing phishing very much so.

What RIPE did there is a perfectly example of what should be done.
Send plain text e-mail with the URL location to review, no HTML
doodads.

They have no control of your e-mail client that for some reason
perhaps turns a plaintext URL into something you can click.

36

In article <20120210213755.GA88812@ussenterprise.ufp.org>, Leo Bicknell <bicknell@ufp.org> writes

Hypothetically, I get an e-mail from ripe.ca

Or from ripen.cc which is one of their actual domains (used briefly as a url shortener).