Tag Archives: cross site

Phishing Toolbars — The One That Works

Last week I wrote in my WSJ.com/AWSJ column (sub required) about the cross site scripting phish I received a few weeks ago (it appeared late because of the Easter holiday.) The point I made in the column is that most of the browser toolbars designed to prevent phishing failed to warn the user of the attack.

Some readers have asked which toolbars didn’t work. I didn’t have space in the column to list them, but I did mention that one worked: Netcraft’s Anti-phishing Toolbar. Sadly it only works with IE, but since most banking sites still insist on only functioning in that browser, this is not too much of a handicap. Netcraft are actually an interesting, serious bunch of people who do good work, not least their DNS search engine. (They also measure server traffic, and pointed a few days back to a burst in visits to the Vatican’s website as the Pope lay on his deathbed.)

Anyway, next posting I plan to list the toolbars that didn’t work on the Charterone phish.

Putting Phishers In The Banking Frame

Phishers are smart, and banks are dumb. At least, it seems that way. Here’s another example of what’s called a cross site scripting vulnerability attack, which basically lures the victim to what seems, both in the phishing email and in the website it links to, to be a genuine website belonging to Charter One Bank.

My phishing guru Daniel McNamara explains that the long URL — which begins with a legitimately looking http://www.charterone.com and contains none of the usual hidden URLs further down the URL — actually contains a link to a frame, which “effectively allows the phishers to load a frame containing their site withing the real charterone site”. This frame appears in the browser inside the legitimate page http://www.charterone.com/legalcenter/do_not_solicit_confirm.asp . It looks like this:

Charterone

I’m going to run this by CharterOne to see what they have to say about it, but as Daniel points out, “it’s a pretty bad failing. a fairly common one unfortunately.”

Bicycle Bandits And Phishing

Further to my post about the phishing incident at SunTrust, you don’t always need to be that sophisticated to rob a bank. All you need is a bicycle.

Late last month, the Richmond Times-Dispatch in Virginia reported that a man entered the SunTrust bank in Richmond “shortly before 11 a.m. and made a verbal demand for money. He displayed no weapon. After receiving an undisclosed amount of cash, the man fled on a bicycle heading west toward the Toys “R” Us store.” Clearly a man keen to get his kids’ Christmas shopping out of the way ahead of the rush.

It may not be the first time the Bicycle Bandit has hit. The Dispatch reports: “Police are investigating whether the man is the same person who robbed the Bank of Richmond at 8905 Fargo Road on Nov. 15. In that case, the robber also escaped on a bicycle.” Quite a getaway.

Could this be the same guy behind the phishing attack? Was he just probing the bank’s vulnerabilities, and decided to opt for cross-site scripting rather than a bicycle-borne attack?

The Phishing War Escalates

The guys at Netcraft, a British security consultancy that has done a good job of tracking, exploring and warning about phishing, say they’ve come across the first case of cross site scripting being used in the wild for phishing purposes. This isn’t as arcane as it sounds, since it allows phishers to make their lure appear to even the wariest eye to be from a legitimate source — your bank.

Usually the weak link in a phishing email is the link itself. However much they disguise it phishers can’t get away from the fact that they are trying to lure the victim to a site that is not the bank or other institution they’re pretending it is. Cross site scripting lets them do so.

This is done by phishers exploiting a vulnerability to ‘inject’ their own code into the legitimate website. It’s this code that the link will appear to go to in the phishing email — and so will begin with a legitimate bank URL — www.citibank.com, or whatever. The URL will then, without the victim’s knowledge, load some JavaScript from somewhere else to redirect the user to another site. This is what some fraudsters have done with a SunTrust bank phish, which Netcraft says was sent in large numbers in recent days. Netcraft says SunTrust has so far failed to reply to their emails:

Careless application errors and inadequate testing are believed to be an industry wide problem for internet banking, and even though it would seem to the man in the street appalling that someone could run a fraud from a bank’s own site, SunTrust competitors are unlikely to be strongly critical through fear of similar problems with their own facilities.

If true (and I’ve no reason to doubt it; Netcraft know what they’re doing) this is a pretty sad state of affairs. I have two main concerns: Firstly that banks still don’t seem to understand what they’re dealing with, and don’t respect security companies enough to keep up a dialogue with them so these problems are nipped quickly in the bud, and secondly, I suspect these kind of attacks render most ‘anti-phishing tool’s useless. This is not only annoying, but dangerous.

Something I’ve noticed in recent months is a shift on the part of anti-virus manufacturers to push out software that will protect the user from phishing attacks. This is just bad marketing, and foolish. Nothing can protect the individual from phishing attacks than their own wariness and savvy. To suggest tools can will just give people a false sense of security. Examples like this SunTrust case prove the point, which I’ve banged on about for nearly a year now, that phishing is a war of escalating technology and that pushing out some feeble toolbar and suggesting it will protect the user from all such attacks is irresponsible, and thoroughly underestimates the scale of the problem and the kind of adversary we face.

TRUSTe’s Own Phishing Hole

We all know about phishing websites that look like real banking sites. Usually, to the informed layperson, there’s something in the site to inform the wary that it’s not kosher. But what happens when there’s something in the site that confirms that it is kosher?

First some background: TRUSTe is an independent body whose “services support online business growth by allowing companies to communicate their commitment to privacy, and letting consumers know which businesses they can trust.” A TRUSTe seal on a website allows the user to check whether the website is kosher (and whether it supports privacy and other consumer issues). Nearly 1,500 websites use the service, including 28 Fortune 500 companies. In short, as TRUSTe’s own website puts it: “People trust the familiar TRUSTe seal. They know our sites comply with strict standards of online privacy.”

[A seal from the MSN privacy page http://privacy.msn.com/]

But what if that’s not true? What if someone can fake the TRUSTe seal to make it look like their website is TRUSTe-approved? Andrew Smith of Where’s The Beef has shown that it’s possible, using cross-site scripting, to open up the TRUSTe web site to attack and allows a scammer also to use TRUSTe as a phishing source (via addict3d.org).

Now, this shouldn’t be confused with the widespread practice of scammers to simply put a TRUSTe seal and link on their phishing page. That might fool some people into thinking the page is legit, but they will stop thinking that if they click on the link, because it will, in most cases, merely take them to the TRUSTe webpage, which verifies nothing. (In fact, the TRUSTe homepage contains a warning about ‘Seal Spoofers’ — “Did you arrive here by clicking on a TRUSTe seal? If so, you might have found a company that is using the TRUSTe seal illegally” — and invites the user to alert TRUSTe to the scam.)

But this vulnerability is different. It allows the phisher to set up an entire page that, to everyone who visits it, looks as if it is a TRUSTe webpage (correct URL address and all) verifying the scammer’s page as legitimate. As Andrew puts it himself: “This could be quite serious because a phisher could use TRUSTe to just plain scam people or convince them that their site is ‘TRUSTe Verified’.”

This is a serious issue, and I’ve asked TRUSTe for comment. I’m guessing they’ll be alarmed. After all, TRUSTe itself is all too familiar with phishing: It recently sponsored a survey on the subject. Its conclusion: Three quarters of consumers are experiencing an increase in spoofing and phishing incidents and that a third receive fake e-mails at least once a week. Total monetary loss in the U.S. to victims: approximately $500 million.

Of course, the holes that Andrew can be plugged, but that will just be the start. It’s further illustration, if it were needed that

  • phishing is not just about fake emails. It’s about impersonating authenticity.
  • phishing is a war, not a battle. Scammers will keep probing every defence for a vulnerability, forcing both sides to get increasingly sophisticated.
  • users need to get smarter, because the people supposedly protecting them cannot be relied on to be the smartest people on the block. If you use online banking, you need to be more alert than if you just use the Internet for email and checking the weather.
  • folk like Andrew Smith should be thanked for their work in exposing these flaws. If people like him have spotted them, it’s fair to say the bad guys are not far behind, and companies and banks should recognise this.

Finally, one can’t help but wonder whether verification services like TRUSTe may at some point cause more problems than they solve. If the appearance of an official looking seal on a website lulls the user into a false sense of security, then what good is it?

How To Phish Google

I’ve long believed that phishing emails are just the beginning of a new kind of fraud which is likely to be sophisticated and fast moving. Here’s an example of what they might look like, courtesty of a British computer scientist called Jim Ley, written up at the security website Netcraft. Ley, Netcraft says, “has demonstrated that opportunities exist for fraudsters to launch phishing attacks using cross site scripting bugs on the very widely used Google sites.”

I’m not quite clear from either account whether this is one vulnerability or more, and whether it applies only since Google extended their desktop search to include files on your computer (rather than on the Internet).

As far as I can figure it out, it works like this. A bad guy, rather than try to lure a victim to his dodgy website using a socially engineered email or a virus, would ‘inject’ content into Google to do the same thing. So, say, a user would visit Google to find a credit card submission form which explains that Google is soon to become a subscription-only service at $5 per month, but that users could take advantage of an earlybird special offer to obtain lifetime free searches for just $10. (This is Ley’s example, cited by Netcraft.)

Another vulnerability included in the Google Desktop would, Netcraft says, have “allowed an attacker to search a user’s local machine for passwords and report the results directly back to the attacker’s own web site.” Both vulnerabilities have been fixed, but Netcraft and Ley say incompletely.

I don’t claim to understand the technical aspects of this, and it may be somewhat obscure. But what is worrying is that (a) Ley reports Google as being less than interested in addressing the issues he raised (two years ago, according to his website) and, (b) that if such tricks are occurring to diligent folk like Ley, they must be occurring to hackers and the Internet underground. I’ve said it before, and I’ll say it again: Phishing is not just misleading emails, it’s a multifaceted effort to part us ordinary folk from our online money. And it’s not going to go away. Indeed, like most things technological, it’s a fast escalating arms race, and I don’t think we’ve even started to get it figured out.