Impressive Phishing Attack

Read about it here, or in even more detail.

I find this phishing attack impressive for several reasons. One, it’s a very sophisticated attack and demonstrates how clever identity thieves are becoming. Two, it narrowly targets a particular credit union, and sneakily uses the fact that credit cards issued by an institution share the same initial digits. Three, it exploits an authentication problem with SSL certificates. And four, it is yet another proof point that “user education” isn’t how we’re going to solve this kind of risk.

Tags: , , , , , ,

Posted on February 22, 2006 at 7:41 AM • 38 Comments

Comments

Richard Braakman • February 22, 2006 8:52 AM

I’m amused by the Geotrust comments that imply that only organizations that look like financial institutions are checked. This raises the question… if only financial institutions need such scrutiny, then why does anyone else use a signed SSL certificate?

Joseph • February 22, 2006 9:00 AM

I’ve been waiting for something like this to happen for a long time. It seems that most Phishing developers are complete idiots. All that was needed was for one “real” developer to turn to the world of crime in order to create a truly convincing phishing scheme.

peter • February 22, 2006 9:08 AM

This gives a good reason to move the Encryption and Banking industry to supplying a new flavour of SSL cert based upon a posted bond with a Federal Agency such as the Banking Regulator or SEC. There should be two-flavours of SSL certs; untrusted and bonded. Bonded should be easily verifiable by following the cert chain to a single Federal Agency.

Peter

Homeland Stupidity • February 22, 2006 9:16 AM

Peter, the government would do what they do with every other program: screw it up. There’s no need for the government to provide such a solution, when any company could do it better and cheaper.

Mike Sherwood • February 22, 2006 9:30 AM

The obvious solution to me would be for banks not to use email for communications. No banks I have accounts with use email for critical communications. I mark all mail from banks as spam. Ultimately, it doesn’t matter if it comes from the bank or not because it shouldn’t be trusted, ever.

I work for the international marketing group for a bank and the decision makers do not understand that the offers they make via email are indistinguishable from phishing. Of course, it’s impossible to convince people of something they don’t want to believe.

Anonymous • February 22, 2006 10:00 AM

“One, it’s a very sophisticated attack and demonstrates how clever identity thieves are becoming.”

I don’t know – you still have to be rather an idiot to fall for that one. But I agree, if people fall for Nigeria scams, they will also fall for that one.

“Geotrust’s cert verification process is largely automated”

Now that’s interesting! And they say that involving a human wouldn’t have helped. So what is this verification process supposed to verify??? Not that anybody would have checked the certificate anyway…

Ipstenu • February 22, 2006 10:04 AM

Working for a bank too, I can tell you that I’ve seen more people bitch about snail mail messages than email. They both are a problem, and currently our online interface only emails you to say you have a new message, please log in. This is an attempt to cut down on phishing, but it’s not foolproof.

Also, my physical mail is much more susceptible to being tampered with. I watch every day as a mailman LEAVES HIS CART on the street to walk into a walk-up and deliver mail. Also, my back-up mail person is notoriously sucky at putting the right mail in the right slots. So … yeah, there is no cure.

Mike Sherwood is right about the marketing problems. We complain about it a lot at work too, and they just look at us blankly. Oy.

Lyger • February 22, 2006 10:19 AM

“And four, it is yet another proof point that ‘user education’ isn’t how we’re going to solve this kind of risk.”

I would change that to read: “And four, it is yet another proof point that ‘user education’ ALONE isn’t how we’re going to solve this kind of risk.” As written, the statement implies that user education is useless, or at least too ineffective to be bothered with.

No system is ever going to be foolproof. To ask that one is doesn’t do anyone any good. But it’s also of value to understand that anyone who lacks a reliable means of omniscience can be fooled once in a while. The problem that SANS points out is that there are instances in which “the system” operates in a way that is directly at odds with users’ efforts to protect themselves, rather than as a compliment to it. This results in the wasting of a valuable resource – namely users’ efforts to reduce their own vulnerability. A system that better integrates with user knowledge and effort will be more effective than one that tries to cut them entirely out of the loop.

Homeland Stupidity • February 22, 2006 10:27 AM

An interesting thing happened when I first upgraded to Thunderbird 1.5. It started giving a new message: “Thunderbird thinks this message might be an email scam.”

Interestingly enough, it was indeed appearing on all the phishing emails, as well as a few email forwards from people who really should have the forward button removed from their mail client. You know who I’m talking about.

It’s not the final solution, but it’s a start.

hggdh • February 22, 2006 11:42 AM

The problem is not allowing use of e-mail or not (although this would momentarily inhibit the attack), since next phishing could very much be done with a combination of data acquired/stolen, and snail-mail.

The problem is the abuse — huh, overload? — of SSL certificates usage, and bad verification/validation procedures.

Also: what those phishers did will leave tracks everywhere, and they will be almost certainly taken.

Mitch P. • February 22, 2006 12:43 PM

While I agree with Bruce in general that the final solution to these kinds of problems is to move at least some of the financial burden onto the financial institutions, in this case the institution didn’t appear to have done anything wrong. In thise cause it appears that the biggest “failure” was insufficeint dilligence by EquiFax. Should Equifax bear some liability here?

antimedia • February 22, 2006 1:45 PM

First of all, banning all HTML email would solve a host of problems. HTML never should have been allowed in email to begin with.

Secondly, nothing BUT user education is ever going to solve this problem. The ID 10 T problem can’t be solved by technology.

When people get email from a vendor they trust, they should go to the vendor’s website independently, not by clicking on a link in the email. Or just delete the message.

There’s plenty that banks can do better, but in the end, only better users will solve these problems.

Matt Sayler • February 22, 2006 2:13 PM

GeoTrust provides certs based on “do you control the domain in question”. This is, I beleive, a perfectly legitimate type of certificate to issue–if that’s all the assurance you need.

Longwalker • February 22, 2006 2:14 PM

Phishing using phunny SSL certs is another ballgame compared to ordinary unencrypted phishing efforts. ‘Look for the lock’ can deal with ordinary phishing; dealing with phunny SSL requires stronger measures. Specifically, phunny SSL certs should not be issued in the first place.

Shifting phish liability to financial institutions isn’t going to make certificate authorities care enough to exercise due dilligence when issuing certs to something that appears to be a financial instutution. Liability for phunny certs should belong with the certificate authority.

Ultimately, the chain of trust for financial institution SSL certs must extend, in a meaningful way (not just in the sham two-signatures-on-letterhead way), to goverment banking regulators. FIs cannot operate without regulatory license, so regulatory bodies are the final authority on if someone seeking an SSL cert is actually a bank or not.

Doug • February 22, 2006 2:30 PM

I think any Phisher using an SSL certificate isn’t to smart. First I believe the Geotrust process leaves a string of touch points behind and my guess is the people who did this may be caught. This stuff does not appear to be new. VeriSign had a well known Microsoft cert and verified by Visa cert and I believe some other folks have issued certs like this as well. This market appears to be like antivirus – where the attacks get better/ change over time. The best thing would be to turn CRL checking in the browser by default so if they was a problem, the cert could be revoked… that way using an SSL cert would be really dumb.

Relativism • February 22, 2006 2:44 PM

I have argued unsuccessfully for years that issuing your own server certificate is just as secure as a certificate issued by a CA tied to the major browsers. I tried suggesting this at work and was dismissed out of hand because the customers would get spooked by the warnings issued by the browser.

The point to me is that there is no way on earth that all the certificates issued by all the CA’s tied to browsers can possibly be authenticated. How can they possibly be trusted? They can’t, and perpetrating the fiction that there is such a thing as a chain of trust for Internet web-based commerce is a fraud (hear me Microsoft!). There is an illusion of a chain of trust, nothing more.

SSL security is intended to provide an encrypted channel between client and server, nothing more. The trust bit is a sham.

If the customer was trained to take part in an out of band authentication procedure (check the warnings for this, only type in mybank.com yourself, never type in anything else, never follow links…) then the customer would be getting better security regardless of the warnings.

But of course, nobody listens. E-commerce is based on displaying soothing images suggesting security and making sure the customer never gets any scary warnings…!

Doug • February 22, 2006 2:52 PM

Relativism

Good points. But I think a central place to revoke certificates and make revocation decisions is good. I also think the SSL authentication models used by all SSL providers were designed in the 90s before phishing. There should be some way to come with a higher validated certificate for phishing target sites that requires a physical visit to the business… This happens in getting home owners insurance – why not in issuing a highly validated SSL? And, revocation has to be done by default.

j • February 22, 2006 3:40 PM

One of the points of this entry is that typing in “mybank.com” yourself is not necessarily good enough! I may forget that my bank’s on-line system uses “compassweb.com” because I almost always use a bookmark to access it. If I got a phish and I typed in the URL I might not realize that “compassonline.com” is not the legitimate domain for my bank.

piglet • February 22, 2006 3:54 PM

“I think any Phisher using an SSL certificate isn’t to smart. First I believe the Geotrust process leaves a string of touch points behind and my guess is the people who did this may be caught.”

I didn’t think of that. Actually, if the certification process includes sufficient identification of the person demanding the certificate, then the certificate has some value, and phishers are ill advised to use a certificate. The question is, how reliable is this identification, and what is it based on? Can this be done by sending an atomatic email?

Relativism • February 22, 2006 4:21 PM

@j

“typing in “mybank.com” yourself is not necessarily good enough! ”

Yes, you’re right, because many sites have been set up to trap the unwary spelling mistake. I certainly don’t rely on typing in the URL every time, I use my bookmark once I have verified it is correct by using whatever out of band methods I have available.

Relativism • February 22, 2006 4:35 PM

@piglet

“how reliable is this identification”

Often (usually?) not very. Certainly in Australia no attempt is made to verify identity of the signatory on documents for companies or registered business names. You probably need an address, but that is easy. The registering government authorities have a stated policy of leaving it to the courts to decide cases of fraudulently lodged documents, because in practice it is far too boring an exercise for anyone to bother with.

This does mean that you can register a company with no real identity check (and what would be the good of a poor check anyway!). This is probably true of most countries in the world. Once you have a company or business name you can easily get a .com domain, once you have a domain you can easily get a certificate.

SadCA • February 22, 2006 4:46 PM

Interesting topic, good comments.

This is actually a good test/example for the trust provided by today’s Certificate Authorities. Based on the information provided to and verified by the CA as part of issuing an SSL server certificate, the FBI should be able to immediately identify this phisher and go directly to the phisher’s place of business and arrest them.

If this is not possible, then I would say the CA has serious flaws in their SSL server certificate issuing procedures and are providing no trust whatsoever for their SSL server certificates – and generally undermining the trust and security benefits provided by using SSL in the process.

As a result of this obvious irresponsibility on the part of the CA, this CA should no longer be allowed to issue SSL server certificates. But who’s going to enforce this? The browser vendors? The “marketplace”?

Todd Ridereck • February 22, 2006 6:40 PM

GeoTrust – probably gets attacked 100 times a day. They seem to have very good brand and be a nice target. I know the same things have happened to VeriSign a couple times. This sounds radical, but I think this is all progress. I am guessing only good will come out of Verisign and Geotrust being attacked. They will get better. I dont expect perfection, just improvement. It is like Doug said – like antivirus you dont know what will come next. Without someone trying to provide trust, it is the wild west. Firms like GeoTrust and VeriSign probably provide much more good than bad… I am going to have a glass a wine and toast progress.

Steve • February 23, 2006 5:58 AM

Blaming the CA misses the point. If you look at the certificate (there’s a screenshot in the Washington Post blog article), the subject-organisation of the certificate is “www.mountain-america.net”. So all the certificate proves is that the CA believes that the organisation to which they issued the certificate really does own that domain. Which, to be fair to the CA, is true. They’ve done their job – it is not their job to prevent people registering domain which look like they might belong to credit unions. In fact it’s not anyone’s job to do that.

As Bruce says, the problem is an “authentication problem with SSL certificates”. More precisely it’s that SSL certificates (or at the very least, the way they are currently presented in user-agents) are too complex for phishing victims to understand. The real Mountain America site, http://www.mtnamerica.org, has a certificate issued to “Mountain America Credit Union”, meaning that the CA thinks the certificate was issued to the company of that name. Users should know to look for the real name of the company in the “Issued-to” section of the certificate information, but in practice that’s too much for most people to handle.

Ian Ringrose • February 23, 2006 6:24 AM

One of my stock brokers users a very effective and simple system.

To log on I type in my user name and password.

I then SEE details of my account.

If I wish to move money or trade, I have to confirm the action with my DEALING password; this is not the same as the password I used to log on.

To defeat this, the phishing site will have to connect to the real site so that it can show me my account details.

It a bit more secure, as my account number is stored in a cookie, and I know something is “odd??? if the side does not automatically fill it in on the logon page.

Artichoke • February 23, 2006 7:11 AM

@Ian

“It a bit more secure, as my account number is stored in a cookie, and I know something is “odd??? if the side does not automatically fill it in on the logon page”

What happens if the cookie is lost, corrupted or expires? Will you stop using the site because your account number doesn’t appear or will you eventually get frustrated and log in anyway?

“To defeat this, the phishing site will have to connect to the real site so that it can show me my account details”

Presumably you’ve just typed your username and password into the phishing site. What’s to stop them retrieving your account details from the legit site and displaying them to you? I’m no expert but I assume this is possible.

witless • February 23, 2006 10:24 AM

@steve

So all the certificate proves is that the CA believes that the organisation to which they issued the certificate really does own that domain.

If that’s all the CA does, why do they charge so much? GeoTrust’s cheapest, “QuickSSL”, is $189 – sounds like a lot for an automated process that provides little…

Steve • February 23, 2006 11:57 AM

If that’s all the CA does, why do they charge so much?

Because they can? What they’re selling is, as much as anything, the fact that their CA root certificates are trusted by major browsers. So scarcity is a significant factor, and one would not expect their prices to reflect their marginal costs of production per certificate.

The point is though that regardless of it cost, a certificate only proves (to the extent I trust the CA) that the owner is who he says he is. In this case, the certificate did exactly that, and it would be a mistake for me to think “well, if it cost $189 then this must be the real Mountain America Credit Union”. It’s also a mistake to think “well, it’s http://www.mountain-america.com, so it must be the real Mountain America Credit Union”, so problem is how to prevent users making that mistake.

It’s a problem which the CA cannot wholly solve, because it’s not up to them to decide who is allowed what domain names. Presumably they could mitigate it somewhat. For example, they could have set the subject-organisation to “owner of domain mountain-america.org, who could be just about anybody for all we know or care”. I don’t know whether the ITU publishes a standard for identification of organisations in x.509. But even if they did that, the fact is most users don’t look at the certificate anyway, they (at best) just look for the little padlock symbol, because they’ve been told that means they’re “safe”.

Ari Heikkinen • February 23, 2006 3:42 PM

Looks kind of neat. Those first five digits of the card and a valid certificate have likely fooled many (as they can obviously claim they display only five digits for security reasons).

However, as someone suggested, why blame the CA? They apparently checked that the domain in question belongs to whatever company that claims owns it. A certificate proves nothing else.

So exactly what the CA did wrong?

Blaming the CA is like blaming a car seller when someone later uses that car sold for fast getaway after robbing a bank.

Personally, I think the only advantage of actually buying a certificate is to get the site in question open without a dialog on browsers you haven’t installed (or don’t have control of) yourself. If you install all the browsers your users use then you can aswell be your own CA and generate the certs for your servers yourself.

Oh, and if there’s a problem with a cert, would you really expect your common users to actually do anything else but simply click on about anything to just get on that website they’re trying to reach?

Ari Heikkinen • February 23, 2006 3:49 PM

Just to add, does anyone ever even bother to read what information a cert contains anyway? I surely don’t remember doing so much, if ever.

M • February 23, 2006 4:32 PM

I showed this article to a friend and his reply was “why bother to fake a bank site when you can just write a trojan to transfer money after the user has logged into his/her real bank site?”

Apparently these trojans are all the rage now 😉

What does Bruce have to say about this one? All the biometrics in the world aren’t going to stop this — I guess the best advice is just “avoid trojans.”

http://news.zdnet.com/2100-1009_22-6041173.html

piglet • February 24, 2006 11:39 AM

From the zdnet article:

“But in response to the increased adoption of stronger authentication, cybercriminals are changing their tactics, according to Alex Shipp, a senior antivirus technologist at MessageLabs.
“We have recently seen a move away from stealing user name and passwords,” Shipp said during a panel discussion at the RSA Conference 2006 here on Thursday. The new “bank-stealing Trojans” wait until the victim has actually logged in to their bank. “It then just transfers the money out.” This new type of Trojan is on the rise and is currently No. 3 on the list of most common threats, according to Shipp.”

We’ve read that before, haven’t we? “changed tactics” – “on the rise” – “nothing you can do about it anyway” – “security expert”. How many of those attacks have actually been observed, how much money was successfully stolen? And does anybody care to actually analyze the vulnerabilities exploited by those alleged attacks, rather than just releasing frightening soundbites?

Dulles • February 25, 2006 4:45 AM

According to Network Solutions, the phishing site domain mentioned in the article (mountain-america.net) is registered to a guy in Ithaca, NY. According to ZabaSearch the guy is 60 years old and really lives at the address given. I wonder if he knows he owns the domain? Do you suppose the FBI has told him?

Tony H. • February 27, 2006 7:47 PM

Didn’t anyone read the actual text of the email? The phrasing is a dead giveaway, even if it’s a little more polished than most phishing mail. The parts where they cut & pasted from real Visa text are fine, but then we get to:

“We present our apologies and thank you for cooperating. Please do not answer to this email – follow the instructions given. These instructions have been sent to all bank customers and it’s obligatory to follow.”

Does your bank write like this? Even Joe Sixpack himself would never write “answer to this email”; his errors would be quite different.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.