HSBC Online Banking Security Flaw Analyzed 178
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."
Nine attempts? (Score:5, Interesting)
The number of attempts is not given, but the automatic lockout is at least covered at their security page [hsbc.com]
Sorry Cardiff University, no bank hax for you today.
So what's the best real solution to the problem? (Score:4, Interesting)
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!
Re:So what's the best real solution to the problem (Score:3, Interesting)
You type in your account id (keylogger can pick this up obviously), then you are presented with an on screen keypad where you enter your pin number with the mouse. 4 digit pin number ( easy to remember), the numbers are in a different location on the on screen keypad every time. The only way any spyware can capture this would be with screen captures on every mouse click. I am not sure there are many spywares that go to these lengths.
Re:So what's the best real solution to the problem (Score:3, Interesting)
Thats the best means I've seen so far to protect against keyloggers.
A similar problem exists in meatspace (Score:4, Interesting)
-BbT
How to fix this (Score:3, Interesting)
So who should we look to for an answer? ING Direct [ingdirect.com]! They use a two step process to log in. The first is a non-descript customer number. This step would be defeated by a keylogger or if someone had some mail stolen. Step two is to ask you to answer a pair of personal questions only you know the answer to. Still this could be defeated by a keylogger. The third step is pure genius though. First of all the page displays an image and phrase that you pre-selected. While a keylogger might pick up this phrease during account setup it would not pick up the image. If the image is not present, you are instructed not to enter your PIN number. Then the entering of the PIN number is via a keypad that you click with your mouse. Each number corresponds to a random letter that changes everytime you log in. If you choose you can type in the letter that corresponds to each number for that log in. In this case the data a keylogger might capture would be useless. This is the best security feature on the website and ensures almost nobody except the account owner can ever log in. Of course if the PIN is compromised then the whole system breaks down but a smart user will never have a compromised PIN.
Re:uhhh... (Score:1, Interesting)
No way a keylogger will work there, something much more sophisticated, like a virtual screen connection.
Re:How to fix this (Score:3, Interesting)
For my account, I set my secret phrase to be "false sense of security". However, I was disappointed that for the image they didn't seem to have any pictures that looked like a man in the middle of anything.
What are the image and phrase really supposed to do for you? They are supposed to let you know "hey, this really is the ING site, so it's safe now to login". If you go to a fake ING site (either by DNS poisoning, URL typo, phishing link, etc), they won't have the picture and phrase there, so you know it's a fake website. Well, the problem is, all the fake website has to do is play man-in-the-middle.
1) You provide you account number and submit
2) The fake site connects to ING using your account number and retrieves the page with your 2 security questions and echos them back to you.
3) You answer the security questions and submit.
4) The fake site submits your answers to ING, then on the next page it retrieves your secret phrase and security image and echos them back to you
5) You see the phrase and image and say "yep...this is really ING, it's safe to provide my PIN". At that point, even if something later tips you off that the site might not be legit, you are likely to think "well, that seems odd, but they DID have my image and phrase, so it's got to be alright". Instead of reporting something suspecious, you are lured in by a false sense of security and probably won't report anything.
Security checks, and requirements (Score:3, Interesting)
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.