RE: Phishing

["Mark Curphey" <mark () curphey com>]

A trend I have noticed with a lot of online banks is to place the login page
within http and then POST the form to HTTPS. They typically use a padlock
icon (image) on the form to indicate that the POST location is over HTTPS.
However the end result is that the place you are being asked to enter your
username and password was not authenticated using server SSL auth (i.e. the
cert).  Net result you do not know that you are entering your username and
password into a legitimate site (sure you could check POST action but how
many end users would ever do that). 

This practice IMHO makes phishing another step easier and I really think
there needs to be awareness of the issues to stop it.

-----Original Message-----
From: Rogan Dawes [mailto:discard () dawes za net] 
Sent: Wednesday, May 12, 2004 8:59 AM
To: Griffiths, Ian
Cc: Amit Sharma; webappsec () securityfocus com
Subject: Phishing


Griffiths, Ian wrote:

> I'd guess that a major issue at the moment is users being fooled in to 
> entering their details in to a nefarious web application which looks 
> authentic but of course is not.
> I'm not sure if discussion of this would be beyond the scope of the 
> list.
>  
> Ian

It probably is in-scope. The question is, what can we do about it?

Perhaps start by describing the various ways that such phishing attacks are
being executed, and then move on to ways to thwart them?

Method 1:

Scammer downloads a copy of the target's web site, and hosts it locally,
using either a non-SSL site, or an SSL-site with a fake certificate.

Counter: Educate users to check that the "lock" exists, and that the
certificate matches the bank's URL.

Method 2:

Scammer sets up a proxy pointing to the targets web site, and records
sensitive information submitted, while relaying it to the target. Sends a
redirect to the actual site when the sensitive info has been captured. 
Proxy uses own certificate to terminate SSL socket, and re-encrypts to talk
to target. (e.g. WebScarab in transparent proxy mode)

Counter: Again, educate users to check the certificate details.

Method 3?

Anyone?


Notes regarding educating users:

Make the site name as short as possible, and as obvious as possible, to
reduce confusion. Rather than "www{1,2,3,4,5,6,7,8,9}.encrypt.bank.com",
try to use something short and simple like "secure.bank.com", and use it
consistently for all servers supporting a particular application. That way
there is less confusion for users, and less likelihood that a scammer will
get away with using a slightly different domain name.

Also, if your bank is abc.com, don't make your internet banking URL
abc-online.com, or similar. Keep it under the original domain. Less for the
user to be confused about.

There is no RFC stating that all URL's have to start with "www". It is
simply a convention from many years ago that helped users find your online
presence. By all means name your company's main web site www.company.com.
But there is no need for www.secure.company.com, and
www.admin.secure.company.com, etc.

[ Apologies for my little rant ;-) ]

Regards,

Rogan
--
Rogan Dawes

*ALL* messages to discard () dawes za net will be dropped, and added to my
blacklist. Please respond to "lists AT dawes DOT za DOT net"