Mate --

IMHO the "simple" fix to phishing is an email client that is KISS, KISS, KISS

the entire phishing phenomenon, the whole industry, the whole thing - is based on the following

in typically set up Microsoft email clients that 99.9999% of punters use,

you can send an email which has a LINK TO url "foo.com" *BUT* the email client user sees a link to "bar.com"

Thus, the dumb civillian user clicks on what he thinks is "bar.com" but actually goes to foo.com

That's just all there is to it and explains 80% of successful phishing

The whole entire thing would never have happened if that was not the typical behavior of email clients

It's a great example of a small simple thing you would never have thought about having big consequences.

It's also a reason why one should always stick to plain text courier, no styling, no html, nuthin' - always !!!

Jape,

there are many phishing attacks that have come through chat clients and chat rooms ... The whole concept derives from AOL chat rooms as far back as 1997 or so!

I think but am not sure that there is also browser-to-browser phishing. So, unfortunately, to address the bigger issue, one has to assume the email client is not the only delivery of the phish. That's why I ignore it and concentrate on the browser. It also has some concept of what's right and what's not - whereas the email client has less of a concept.

iang

>
> I think but am not sure that there is also browser-to-browser
> phishing.

how does that work ?

another variant of fishing instead of in the email going "link looks like commbank.com, but is really to villainsite.com" ..... ie ..... the villian gets the DOM "c0mmb2nk.com" which at first glance looks like "commbank" but it is not. Thus the villain can send a plain email, not even using the "link looks like commbank.com, but is really to villainsite.com" html in email trick.

However -- these sort of phishing attack are more easily dealt with. As soon as you tell an ISP or reseller that some fool has a site "natw3st.co.uk" running, the ISP will just shut it down. It's a controllable problem.

It just occurs to me you could phish for information WITHOUT using the web! heh!

I could send you an email "from" Nat West saying, dear NatWest customer Iang Grigg, please telephone this number 012 999 3145 to receive your new higher interest rate.

once you fone the #, you actually get me .. it would be easy to have a voice-prompt system there with background music etc so it sounds just liek a bank, and have people key in their security details -- or even talk to an "employee" !!

> how does that work ?

Beats me, I heard about it somewhere ...

> another variant ...

Right! There are a squillion ways of sending the phish. I think this is what makes it hard to deal with: most people think in terms of stopping the attack from reaching the victim, like with spam. But, with phishing, as we've seen with spam, stopping the phish reach the user seems to be a loser's game.

This all comes down to a few basic factors: the attacker (the phisher) is smart. And the economics of it are that you (the company) have to defeat all attacks, whereas the phisher has to get only lucky enough to make a haul.

It's like what the IRA guy said to the Brit cop: you have to be lucky every time, I have to be lucky once.

So, the alternative to protecting the user is to have the user defend herself. That is, give her the tools to defend herself. Which is fundamentally the browser - what does its security model do to help? Nothing, when what it should do is cache and compare the context, and advise the user that prior relationships are kicking into play. OR NOT!

> It just occurs to me you could phish for information WITHOUT using the web! heh!

Yep! Phishing could be defined as more broadly. One of the artifacts of the security model of the web is that it is ok to type your details into a FORM at the institution's site. (Only techies know it was supposed to be something different.) For now, that's what users do.

When used over the phone, we often call it "social engineering." So web-based phishing is a narrow and automated form of social engineering.

> once you fone the #, you actually get me .. it would be easy to have a voice-prompt system there with background music etc so it sounds just liek a bank, and have people key in their security details -- or even talk to an "employee" !!

You know, they do that in Britain - when I was staying at a friend's place, every *day* the phone would ring, and a voice-prompt system would announce a "major prize" ... apparently it is some fraud going around.

iang

Interesting post, however IMO there are some things that can be done at the server-side to mitigate (current) phishing attacks.

the use of 2-factor authentication, like Secure.ID would make attacks harder to execute as the password grabbed in the attack would only have a ~60 second life in which to be used. (another idea that I've seen floated is leverege the availability of mobile phones and send a one-time password to the customers registered phone which they then must input to a second logon page

Another alternative would be to move to a 2-stage authentication method, so after the first stage when the institution requests authentication details from the customer and they're validated, a screen is presented with a piece of information known to the institution, essentially showing the customer that they're at the correct site and then requesting a second authentication from the customer.

Whilst there are definately improvements that can be made at the browser-level, the problem is getting this deployed on all browsers... given that there are still a significant number of users on IE 4.x any improvement in browser security would take a considerable time to get out to all users...

> So, the alternative to protecting the user is to have the user defend herself.
> That is, give her the tools to defend herself. Which is fundamentally the browser -
> what does its security model do to help? Nothing, when what it should do is
> cache and compare the context, and advise the user that prior relationships are
> kicking into play. OR NOT!
>

holy shit!

So you are suggesting a browser where:

say I commonly look at commonwealthbank.com.au

(in fact - I do!)

Say in the future, I happen to look at, let's say, cuntface.com

In fact, the "actual content" of cuntface.com LOOKS LIKE, TO A HUMAN EYE, the web site "commonwealthbank.com.au" ie the one I have, previously, looked at often.

Are you saying that the browser should be able to TELL that that new site, cuntface.com, in fact looks similar to commonwealthbank.com.au

If that is what you are saying ...

(1) that is incredibly ingenious in concept !

(2) but ............... is that EVEN POSSIBLE, mate !?!?!?! you are asking for an artificial intelligence task of high order right ?!

Sure - you could do a few simple heuristics

Again, this is an incrediubly ingenious idea. Did you thiink it up?

> When used over the phone, we often call it "social engineering."

I don't really agree with that definition man - "social engineering" is totally different, right ?

"Social engineering" is, simply, when a villain calls a Bank, and, the villain basically by (say) chamring the secretary, or whatever, gets say a password or some needed piece of info.

A totally different idea is ... the villain sets up a FAKE !! for gods sake perhaps bank, bank telephone line, or indeed bank web site. He then uses email or letters or whatever to get customers to go to that "fake" entity.

Jape,

One at a time: "social engineering."

Well, maybe. The essence of the con is that something is presented to the victim that is plausible, but if examined carefully, doesn't hold water. Using charm and aggression is simply the icing on the cake to convince the victim not to do the appropriate amounts of due diligence.

When a villain sets up a fake site, yes, it's going a lot further. But, all fake sites just need to be properly examined to be shown as a fraud. And that proper examination would normally, properly be done.

Social engineering is what, I suggest, is used to stop the victim employing those normal checks.

iang

Whether the browser can tell that commonwealthbank.com.au looks different to some other site... No.

As you suggest, that's heuristically hard.

But, the browser does know one thing: the two sites are not the same. They are not in the same place. (Either by DNS or by certs.)

Now, how can you tell the user that it is different? Well, that's kinda hard. Obviously... but there is some info here.

What is there is that the browser knows ... or *could* know ... that you the user have a relationship with one site, and not with the other.

You have been to commonwealthbank.com.au a dozen times, maybe even a dozen in one day. Imagine if the browser recorded and counted the visits to that one cert. And *told* you that this was the 17th time this week you've checked your balance for the dividends cheque to hit...

Then, when you went to the phish site, the browser would be ominously silent. Or perhaps it would display in the "branding box" as we call it the big black & red flashing number ZERO TIMES VISITED. Or maybe it would panic when it saw a form ....

This doesn't guaruntee anything of course. But it helps! It's something that a user can understand. And, you can see that - with your knowledge of branding and marketing - that this relationship management by the browser is only the beginning.........

iang

Rory,

thanks for posting! As you no doubt recognise, ideas 1 & 3 will fall to an MITM. The phisher has already constructed a sophisticated website and can no doubt move onto the next step which is real time processing of the phish.

So, yes, 2 factor authentication would help but only marginally. I doubt it is worth doing.

Going to multiple channels - delivering the challenge over the phone - is much more secure. But, sadly, that relies on the market all having that mechanism. And it raises costs way above the "free net" level. Phone companies of course will love it.

I don't think you can really fairly say that browser deployment will be a problem, when compared to the vague and fear-driven solutions that institutions are panicing over right now. The main problem with the browser is that the manufacturers of them have not accepted that phishing is anything to do with them. Once they recognise that there is only about a programmer-month's worth of work in making these sorts of displays available, and that they work, I suspect things will change.

Zero times visited is an excellent idea ...

You know my personal opinion? the web will die and banks and the like will create lightweight applications of their own for people to run!! :O

hi again,

Yep 1 and 3 would fall to a full MITM attack, they're more "arms race" style measures for short-to -medium term mitigation (in that the first couple of banks or institutions to deploy them will be free of attacks for a while as the phishers continue to attack those who haven't)

also I agree that the current responses of a lot of institutions aren't of the best at the moment!

However I've got to say I'm still not convinced about the idea of a client-side solution to this problem even if browser vendors can be persuaded to put some form of robust mechanism in place for a couple of reasons

1. Look at the level of spyware/trojan infections currently on Windows-based PC's (the recent survey done in conjunction with Dell stating that 90% of machines have some form of spyware installed on them). With more and more trojans including keystroke-loggers any client side security is useless against this style of attack if the site it's connecting to relies on static usernames/passwords.

2. From the Point of View of an institution currently being attacked in this fashion, they can't really affect browser development (apart from perhaps lobbying microsoft) so they have to focus their countermeasures on areas which they control.

cheers

rory

Who ends up with liability today with phishing attacks? Not a day goes by that I don't get a message from Citibank telling me that my account has been compromised, or they are improving their security procedure, and I need to re-enter my account information. Card number and PIN, if you please. Suppose I fall for this. What would happen next? Would they be able to empty my account? Would I be successfully able to contest the charges? Would it be Citibank or me who was liable?

Hal,

liability is a big open question in my mind. Assuming that this is an American-style liability & suits issue, here's what I think:

Firstly, the banks are on the hook primarily and at the end of the day. This is not so much because of the contracts they have, but because english common law, consumer law, and banking law generally agree that the bigger party has to carry the can. In the end, the FDIC will eventually put the liability on the banks to cover the user's losses.

But that's in the future. Now, it will bounce between the consumer and the bank, until one of them weakens. Which means lots and lots of additional costs. The average attack seems to net about many thousands of dollars, but it also includes many tens of hours of time wasted on the part of the consumer. I've heard 40 - 100 hours, which can also be worth many thousands of dollars.

But, and it's a big but, the banks have done all they were told to do to secure their systems. So why aren't they secure?

Well, as I described, the browser is what is being breached. And this is a simple case of the users being tricked about an SSL connection to the bank. The users aren't really at fault, and neither is the bank.

What is fundamentally failing here is the SSL secure browsing system. It is not protecting against a very basic attack. What's more, as has been stressed and written up over and over again, the SSL secure browsing system could protect against this attack.

So getting back to your liability question, I would fear that at some stage, the banks will cotton on to the fact that they've been sold a bill of goods. How they'll respond, I don't know, as banks like to keep their security blunders under the covers, even when it wasn't their fault.

OTOH, the users don't care one jot about exposure. When the class action attornies figure out the angle, my uneducated guess would say there would be a fair to evens chance that a class action suit would bear fruit.

iang

Rory,

just to respond to your 1 & 2, there.

1. spyware: yes, it is true that Microsoft users are facing a one-two pincer attack, and their position appears hopeless at the moment. But, is that an excuse to do nothing? Microsoft are working to repair their platform, and maybe in a couple of years they will have made headway.

In the meantime, browser security cuts across platforms. And browsers will continue to be used for this purpose, they are the only scaleable way of contacting masses of users in a "secure" fashion.

So regardless of the problems elsewhere, that limit the efficacy of the fix, I think this is a "home truth" that must be dealt with someday. And, think of the benefit for the Unix platforms (including Apple) who can offer a virus free and phishing protected platform!

2. It's really easy to effect browser development. Just start hacking Firebird (a.k.a. Mozilla). It's Open Source! And there are 5 million copies out there, to date.

Once one platform does it, the others will follow. In fact, some of the work has already been done by Amir and Ahmad in their forthcoming paper/proposal for logos.

(I agree it is impossible to talk to Microsoft. I would and I've tried but I can't even figure out who their security guys are. Their only access seems to be through some blogs, where the control the agenda.)