HSBC Online Banking Security Flaw Analyzed

greenechidna writes "The BBC is reporting that a vulnerability has been found in the online banking service of HSBC by researchers at Cardiff University. According to the story the attack would allow an attacker to log on to an account within 9 attempts. The attack relies on a keylogger being installed on the victim's machine. The article doesn't have any further technical details." David Nicholson adds links to coverage at CNN and at the Guardian, writing "The attack revolves around the order that customers are requested to enter random security numbers on the site. The main news stories fail to detail the vulnerability but I have provided an analysis of it here."

Comments

Nine attempts?

[Kerr]

As a HSBC internet banking user, I can safely say you'd be locked out long before your ninth attempt, hell; four locked me out when I last forgot my IB code. Being locked out is something you can only fix by visiting your local branch and using your password to unlock the account again.
The number of attempts is not given, but the automatic lockout is at least covered at their security page
Sorry Cardiff University, no bank hax for you today.

So what's the best real solution to the problem?

[mcrbids]

Ok, so I replied with a joke a few minutes ago... but I think this warrants more intelligent discussion.

As a vendor of a web-based, access-restricted product, keyloggers are a real issue. I've been considering setting up client-side SSL certificates in order to restrict access to only machines that have been "set up" in order to deal with the problem of keyloggers. Are there better solutions?

Does this bank have something that's: A) Easy to use, B) doesn't require painful machine-by-machine setup, and C) significantly improves security?

If so, I just might be interested!

A similar problem exists in meatspace

[Bigboote66]

In the U.S., most places have taken to just displaying the last 4 digits of your credit card number on the receipts they give back to you. However, on a recent trip to Europe (Finland & Russia, actually), I noticed that the receipts there seem to favor a scheme where a random set of digits appear each time (e.g. XXXX-XXX1-234X-XXXX). If you're like me, you often accumulate a bunch of these receipts in your pockets as you travel; some people may just dump the days wad of receipts in a trash can. A fortunate dumpster diver may stumble onto a wad of receipts that allow him to reconstruct the credit card number. I'm not sure why the people that implemented that latter scheme thought it was preferable.

-BbT

Security checks, and requirements

[TheRealBurKaZoiD]

I find this all pretty funny, especially the requirement of the keylogger, because it hits home pretty close. A web application I wrote and deployed to production about a year ago and now support was finally put through a third-party security check a few weeks ago. The results were fine for the most part. The application is more or less rock-solid since it is secured through Kerberos, hardened against sql injection, and invulnerable to cross-site scripting attacks.

What the company did list as issues (and severe issues mind you) was the fact the application displayed signs of being vulnerable to cookie stealing, and session hijacking through man-in-the-middle attacks, that the server type was sent in the http headers, and that ports 110 and 25 were open on the web server. Well, my complaint is that the security report listed the application problems first, and give them a higher score of criticality, which made everything else, including the open ports 1) seem less sever, and 2) seem as though they were application problems and not network problems, which is what they really are. The business people flipped out and thought the sky was going to fall, since there is some sensitive information stored in this system. Rather than breaking out champagne and celebrating the fact the system was secure against 99.9% of the attacks that would possibly be thrown at it, they lamented issues that weren't application issues. Now understand, I don't manage the servers this application runs on. I merely wrote the application. I don't know what all kind of shit the people who do manage it might have changed.

The funniest thing is, in order to successfully run any cookie stealing, or session hijacking, you (the hacker) had to already have access to not one, but two windows accounts on the domain! The only way to get those was to either work there and have an account, brute-force the username/password, or social-engineer someone out of theirs. And, in order to successfully run the man-in-the-middle attack, you would have to have penetrated the LAN, or hacked someone's computer at their home.

I began to run damage control, explaining how these exploits were possible, why they weren't application issues but network issues, and explaining lots of terms like ARP spoofing, cache poisoning, and how to avoid those things. I remarked that the open ports issue should be rated more highly than the MITM issues, and I also detailed how virtually every web application ever written was similarly vulnerable to these attacks in one way or the other, only to wind up being told that can't possible be true, how I'm extremely arrogant, and how I think I know everything! One person even threatened to have me removed from the project, the cocksucker.

At any rate, the requirement of the keylogger reminded me of the extenuating circumstances needed to exploit this application here: network penetration, not one but two valid accounts, and specialized knowledge of the application.

It's weird. You try to help people and do your job, and they hate you for it. I think I've been doing this for just too damn long.