Internet Banking Security

[paulcam123]

For those that are not hackers and want to see how bad Standard Banks online backing security really is... try this.

Log in to your online banking. Then turn your router off, unplugg the phone cable so there is not internet to your computer. Then turn it back on again. Now contiune to use your Internet banking.

Now you see why people really should not have internet banking.

I tested this. I got a new IP after resetting, but my browser still had an SSL session through the old IP, so it just timed out when I tried to do anything. In other environments, I agree with rurapente - your session might continue as normal. Both results are quite understandable.

Did you get some other unexpected results, or maybe an error message?

 

[rurapente]

just to clarify, card theft still accounts for far more than internet banking theft. although single instances of ibanking fraud can be very high, its still not as high as cc theft. and i doubt it ever will be.

 

[paulcam123]

at the end of the day, its pretty safe, as anyone wanting to make an illegal transfer would have to have your banking details and your linked cellphone, so a beneficary can be created.

Yes, SMS one-time-passwords do help, if enabled. A hacker would be limited to beneficiary payments, balance and statement enquiries, account numbers, card number, phone numbers, email, name, inter-account transfers, etc. Using one-time-email-passwords would probably not help.

I can think of 2 possible ways that this could be bypassed, but neither of them are particularly likely. It imagine it would take a hacker 20 lines of code to view your account, but about 200 lines to possibly bypass the one-time-sms-password (no, I haven't tested this)

 

[paulcam123]

Standard bank actually called me 3 times today. The last guy actually knew something about security, but he assures me that everything is secure. I suppose I expected that.

 

[gregmcc]

Log in to your online banking. Then turn your router off, unplugg the phone cable so there is not internet to your computer. Then turn it back on again. Now contiune to use your Internet banking.

Umm...thats how session states in HTTP/S work. Pretty much all banking sites that use session cookies will do this. If you close your browser or the session times out you will need to logon again.

How does this make it insecure???

If somone else gets your IP address they will still need your session cookie to take over your session.

 

[gregmcc]

It doesn't involve installing any certificates or other software on the PC, works with IE and Firefox, and doesn't give any warning messages to the user.

Do you know what a man in the middle attack is?

When you connect to the banking site your browser establishes a encrypted SSL session between itself and the server.

For a SSL man in the middle attack to take place you need a few things setup:

1) the MITM needs to run a proxy with a SSL cert.
2) the traffic from the client needs to redirected to the rogue proxy (through dns hijacking/poisoning, social engineering etc)

The traffic from your browser is SSL'd to the rogue server where its decrypted, data captured, and re SSL'd and then forwarded onto the banking site.

If there is a code vulnerability on the site then thats another story - thats not a MITM attack.

 

[paulcam123]

Today, Standard Bank Internet Fraud division told me that a MITM attack involved you receiving an email with a link to another site that looks like the bank. That is when I asked to speak to someone more senior.

You give a valid example of a MITM attack, but these can sometimes be prevented on the server side. Like disabling TLS renegotiation could prevent code from being injected during the renegotiation. I would still classify this as a MITM attack, although it doesnt totally conform to your definition.

 

[gregmcc]

involved you receiving an email with a link to another site that looks like the bank

Thats a phishing attack. You click on a link and are taken to a site which looks exactly like the bank site. Your details are captured and then sometimes passed on to the real site.

A vulnerability was found in TLS renegotiation last year where an attacker could inject strings into the TLS session.

I think this is what you are referring to:

A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSLv3 and all current versions of TLS. For example, it allows an attacker who can hijack an https connection to splice their own requests into the beginning of the conversation the client has with the web server. The attacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middle attack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other changes unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extension has been proposed for TLS. It will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.[5] When a user doesn't pay attention to their browser's indication that the session is secure (typically a padlock icon), the vulnerability can be turned into a true man-in-the-middle attack[6]

Found it here http://en.wikipedia.org/wiki/Transport_Layer_Security

And some more info here http://www.sslshopper.com/article-ssl-and-tls-renegotiation-vulnerability-discovered.html

 

[rurapente]

yes, but most banks have patched against that problem now.

 

[gregmcc]

Yeah - I was going to say. Its been long fixed with a patch. I'm sure all the financial institutions were the first to update.

And even if they haven't they most likely have application firewalls which will stop this kind of attack.

 

[paulcam123]

After many denials, Standard bank sent 3 of their security experts through to meet me. They have accepted that there is a problem, and they will be fixing it.

Greg, one of your previous comments almost tells us exactly how to exploit the problem. I will post the details once it has been resolved.

 

[paulcam123]

Ok, Standard Bank has fixed the problem.

For those with some technical understanding, here is a brief summary.

As Greg points out, cookies are used to track users once they log in. So if the MITM gets hold of your cookie, they can access your account.

In this case, the cookie was set by the login screen, before you logged in. If you already have a valid cookie, you didnt get a new one.

So a MITM could intercept the non-secure home page, request a cookie from the secure login page, and send you the cookie together with the home page, and keep a copy. Then, when you get to the login page, it would let you login with the cookie you already had, allowing the MITM to access your account.

You now get a new cookie after logging in.