RE: (not really a) Proposal to anti-phishing

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

Validating the site that you are on won't stop phishing,
though it's a swell idea. Here are just a sample of the
options available to the phisher:

1. Framing: If I inject a transparent frame that captures
your keystrokes into the application, how does site auth
protect? There are mulitple ways to inject a frame including:
-luring
-DNS manipulation
-Wireless (utterly ignored even though a tool to do this
was released seven months ago)

2. Session/State attacks: If the application does not
enforce strong sessions and workflow and do so in a
secure manner, any client that *automatically* provides
credentials/tokens/client-side certificates/whatever
(your web browser) will enable a phisher to take actions
on your behalf.

3. Code injection attacks (XST, stored, reflected,
2nd-order, n-order, whatever).

Hardware token or no. Client SSL cert or no.

Right now the phishers are focused on the befuddlingly
broken browser. Microsoft has given them a cornucopia
of low-hanging-fruit.

You fix that and teach the world to use SSL or implement
some smarmy client-side validation and attackers will
move on to items like the above.

My $0.02 USD, depreciating rapidly,

Arian



> -----Original Message-----
> From: Lyal Collins [mailto:lyal.collins () key2it com au] 
> Sent: Sunday, January 16, 2005 12:39 AM
> To: 'RSnake'; 'Don Tuer'
> Cc: 'Rafael San Miguel'; webappsec () securityfocus com; 
> Enrique.Diez () dvc es
> Subject: RE: Proposal to anti-phishing
>
> To eapnd on this, there is nothing the stop the phisher 
> capturing the entire
> session (i.e MITM tunneling), even using a valid OTP token to 
> logon, and
> even a second OTP token to 'authenticate' a transaciton.
> With tunneling the entire session, the attacker can easily 
> present the user
> with screens saying "transfer $200 to mum" while telling the 
> banking site to
> 'transfer $1000 to joe () hacking site.somewhere"
>
>
> Lyal
>
>
>
> -----Original Message-----
> From: RSnake [mailto:rsnake () shocking com] 
> Sent: Saturday, 15 January 2005 3:59 AM
> To: Don Tuer
> Cc: 'Rafael San Miguel'; webappsec () securityfocus com; 
> Enrique.Diez () dvc es
> Subject: RE: Proposal to anti-phishing
>
>
>
>       To expand on this, there is nothing to stop the phisher from
>       saying "Our hardware token system is down, for the time being
>       you need to enter your name, your social security number, bank
>       account number, pin... for your security."  This doesn't add
>       much value when you're up against people who are gullible.
>       Also, the obvious technical problem with the solution you
>       proposed is that it requires software.  Software can be broken
>       into, and it's also highly unportable.  I can't go to my
>       friend's house and log in without installing something, nor can
>       I use it at an airport kiosk or internet cafe, without
>       installing something, opening yourself up to MITM attacks, if
>       you are even allowed to do it, etc...
>
>       You're on the right track, but we've researched these solutions
>       extensively.  For the most part it just isn't worth it, and the
>       consumers aren't in love with it.  AOL is in the midst of a
>       token trial, and Credit Suisse has issued tokens for years.
>       They are your basic RSA keyfobs, which don't require software
>       integration.  They seem to have some traction there.  From a
>       financial standpoint "giving" tokens away isn't fiscally
>       responsible.  An account takeover for AOL has got to cost them
>       barely anything, so the capital outlay involved would be
>       ridiculous to send tokens all over the world.  That's why they
>       charge.  Therefor it's opt-in.  This again, breaks your security
>       model.
>
>       For this to work it would require global federation from a large
>       consortium of banks, hardware vendors, and e-commerce groups.
>       Everyone would have to agree to allow one second factor
>       authentication token to work on multiple sites.  Otherwise we'll
>       all end up with 50 tokens in our pockets as more and more things
>       go online.  One token works on multiple sites, and is 100%
>       portable.  That's the only way this idea will work for a large
>       scale.  Visa is doing something interesting with forcing banks
>       in Europe to take on liability if they don't accept smart cards.
>       Smart cards are an alright solution because of their ubiquity.
>       The problem is that readers are sparse, and even the smallest
>       reader I've seen is still about the size of an RSA token, and
>       requires USB or some physical connection to a device, which
>       won't work at airport kiosks, again.  Anyway, keep thinking.  If
>       you solve the question, I'd be the first in line to order it.
>       :)
>
> On Fri, 14 Jan 2005, Don Tuer wrote:
>
> > Two phased authentication is good for security but some obvious
> > disadvantages include:
> >
> >     - Cost of hardware tokens
> >     - Cost of distribution
> >     - Cost of managing hardware
> >     - Complexity and user training
> >
> >     Also will the user need to return their token for replacement if
> > they forget the PIN?
> >
> > Thanks
> > Don
> >
> > -----Original Message-----
> > From: Rafael San Miguel [mailto:smcsoc () yahoo es]
> > Sent: Wednesday, January 12, 2005 4:37 AM
> > To: webappsec () securityfocus com
> > Cc: Enrique.Diez () dvc es
> > Subject: Proposal to anti-phishing
> >
> >
> > Hi all,
> >
> > I am currently working on a security design that
> > involves an innovative strategy to combat phishing. I
> > have something in mind that seems to work allright.
> >
> > The solution is based in a hardware token that is
> > delivered to every customer. This token includes the
> > true certificate that should be presented by the bank
> > when a customer access his/her account, and a program
> > that checks if the certificate presented by the
> > webpage is consistent with the first one. The program
> > is in read-only memory so that it can't be modified by
> > anything external to it.
> >
> > The customer will not be able to access his/her
> > account if the token is not plugged in, or if the
> > check fails.
> > Note that it is the token who sends credentials, not
> > the client. Also, the token is PIN-protected to
> > prevent unauthorized use.
> >
> > I don't see any obvious disadvantages to this
> > solution.  Hope this helps other people researching
> > for anti-phishing techniques.
> >
> > Greetings,
> >
> > Rafael San Miguel Carrasco
> >
> > -------------------------------
> > Rafael San Miguel Carrasco
> > Consultor Técnico
> > rafael.sanmiguel () dvc es
> > + 34 660 856 647
> > + 34 902 464 546
> > Davinci Consulting - www.dvc.es
> > Oficina Madrid - Parque empresarial Alvento
> > Via de los Poblados 1 Edificio A 6ª planta
> > 28033 Madrid
> > -------------------------------
>
> -R
>
> The information in this email is confidential and may be legally
> privileged.  It is intended solely for the addressee.  Access to
> this email by anyone else is unauthorized.  If you are not the
> intended recipient, any disclosure, copying, distribution or any
> action taken or omitted to be taken in reliance on it is 
> expressly prohibited and may be unlawful.


The information transmitted in this e-mail is intended only for the addressee and may contain confidential and/or 
privileged material. 
Any interception, review, retransmission, dissemination, or other use of, or taking of any action upon this information 
by persons or entities
other than the intended recipient is prohibited by law and may subject them to criminal or civil liability. If you 
received this communication 
in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network 
system.