- From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
- Date: Wed, 22 Nov 2006 12:09:42 -0500
- To: pbaker@verisign.com
- Cc: public-wsc-wg@w3.org
- Message-ID: <OF504DB568.AA5CB64B-ON8525722E.005DD025-8525722E.005F82C5@LocalDomain>
Phil, good statements around contact and capture as well. I agree with your abstraction on contact, though I would add a non-push technology to the examples, such as some sort of shared community/bboard area (social networking, craig's list type things) and/or a web page meant to capture certain kinds of searches to then tempt the user to the false BobBank. Mez Mary Ellen Zurko, STSM, IBM Lotus CTO Office (t/l 333-6389) Lotus/WPLC Security Strategy and Patent Innovation Architect "Hallam-Baker, Phillip" <pbaker@verisign.com> Sent by: public-wsc-wg-request@w3.org 11/20/2006 08:17 PM To "Stephen Farrell" <stephen.farrell@cs.tcd.ie> cc <public-wsc-wg@w3.org> Subject RE: Action Items - check your due dates These comments can be added directly to the discussion section as is. Only point to clarify maybe is that in the case of WebMail there are two security contexts that have to be authenticated to the user, the context of the message and the context of the WebMail provider. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, November 20, 2006 6:44 PM > To: Hallam-Baker, Phillip > Cc: public-wsc-wg@w3.org > Subject: Re: Action Items - check your due dates > > > Two additions to this: > > 1. Since the user may be using webmail there's no absolute > need for a separate MUA in this scenario. > > 2. The incoming mail may have some markings (e.g. DKIM > signatures, or authentication results) that could be > beneficial (e.g. if the UA itself maintains state). > > S. > > Hallam-Baker, Phillip wrote: > > > > ACTION-4 > > > > > > Formalize the scenario of user getting a request via e-mail and > > using that information to contact a web-site using HTTP protocol > > (e.g. using a browser) > > > > > > Alice is a customer of BobBank. Mallet is an attacker > attempting to > > obtain Alice's access credential for the BobBank site by > impersonating > > BobBank, first in email and then as a Web site. > > > > > > Mallet sends Alice (and a million other users) an email > that purports > > to come from BobBank. The email may claim a sender address that is > > used by BobBank (accounts@bobbank.com > <mailto:accounts@bobbank.com>), > > an address similar to that used by BobBank (accounts@b0bbank.com > > <mailto:accounts@b0bbank.com>) or an entirely unrelated > email address > > (accounts@as818d2182.ru). <mailto:accounts@as818d2182.ru).> > > > > > > The email purporting to come from BobBank directs Alice > to a web site > > that looks very similar to the authentic BobBank site. > The email link > > may use a cousin address (http://www.b0bbank.com), a > numeric address > > (http://10.1.1.1), a numeric address with a fake username portion > > (http://www.bobbank.com@10.1.1.1/). In many cases the > user is shown a > > URL that is different to the one that is actually linked. > > > > > > In some cases the Web site will be implemented as a proxy to the > > genuine BobBank site, in others static HTML and image > file data that > > has been 'screen scraped' from the authentic BobBank site. The > > objective of this site is to persuade Alice to enter her > username and > > password so that Mallet can record it and either use it > to access the > > site at a later date or to sell the information for a > third party to > > make use of in this way. > > > > > > At the time Alice attempts to contact the impersonating Web site > > BobBank may have been alerted to the existence of the > impersonating > > Web Site by a number of channels: A customer, spam > control company or > > anti-phishing company may have explicitly made contact > and alerted the > > bank, the use of the genuine sender address may have caused a > > 'backwash' of failed email delivery attempts, previous attempts to > > connect to the site as a proxy may have been detected. > > > > > > Alice and BobBank both have assets at risk. Alice may > lose funds from > > her account that are not reimbursed. BobBank may be required to > > reimburse Alice for funds taken from the account. In addition to > > direct losses due to fraud BobBank may suffer indirect > losses due to > > increased customer service calls whether or not the attack is > > successful: Alice may insist on doing all her future > transactions at a > > local branch at significantly higher cost to the bank. Alice may > > contact customer service to ask about the attack. > > > > > > Discussion > > > > > > In each case the attack has two disftinct phases: contact > and capture. > > In the contact phase Mallet solicits interaction with a > large number > > of potential victims using a medium that supports unsolicited > > interaction; email, instant messaging, telephone. > > > > > > The contact message directs Alice to the capture site. > While this is > > typically a Web site today the use of automated telephone > attendant > > sites via VOIP is rising. > > > > > > k h > > > > >
Received on Wednesday, 22 November 2006 17:23:25 UTC