Online banking has multiple elephants in its room

A recent New York Times editorial on online banking suggested that many banks are not up to the task of security. However, the editorial writer mis-understands some of the technology. Here I will point out the holes in a couple solutions and some huge issues that were not addressed at all.

Non-techies reading the editorial may think that if their bank does the suggested defensive steps then online banking is safe. This is not true. 

Let's start with the frequently suggested solution of multiple authorizations (two factor authentication). A typical scenario might involve an online transaction that starts on a computer but does not complete until the account owner responds with a code sent in a text message by the bank to their cellphone.

The theory being that a bad guy, without the victims cellphone, can't make fraudulent transactions. But, this can be defeated in multiple ways.

Perhaps the most pernicious, is a man-in-the-browser attack where the web browser software has been compromised.

In this type of attack, transactions are initiated by an authorized account user. Three passwords wouldn't prevent this type of attack. One time use passwords don't prevent it. A retina scan wouldn't prevent it.

The software in the browser modifies the transaction being sent to the bank. Thus if the victim asks to transfer $10 to person x, the bank gets orders to transfer $10,000 to person y.

To cover this up, the malicious web browser also modifies the web pages being returned by the bank. Security company Sophos recently referred to this as a post-transaction attack. In a discussion of the latest version of the SpyEye Trojan they wrote: 

The new Trojan ... hides bogus transactions even after users have logged out and then logged back into their accounts. This version of SpyEye both hides the fraudulent transaction and masks the amount of the transaction, putting forward a fake balance and ensuring that victims are oblivious to anything being amiss.

The only defense against a man-in-the-browser attack is to use a different computer. 

Another suggestion in the Times' editorial was blocking a "connection to bank servers from unknown or suspect Internet addresses."  

This too, is defeated by a man-in-the-browser attack which, again, is initiated by an authorized user. But, it can be defeated other ways too.

An Internet address, or more correctly, an IP address, identifies a connection to the Internet. Typically this is a high speed (broadband) connection shared by multiple computers. No website can differentiate the various computers sharing a single IP address, so the first flaw in this scheme is that it does not block bad guys at the same physical location as authorized users.

Another problem with this approach is that many connections to the Internet have dynamic IP addresses. This means that the IP address changes at the whim of the Internet Service Provider. Any online banking that needs to be done from an Internet connection with a dynamic IP address can not use this scheme.

On the other hand, a bank should be able to restrict account access to IP addresses in one specific country. But, this can be defeated by a bad guy that remotely controls a compromised zombie computer or by simply using a VPN service.

The editorial also mentioned that banks should detect unusual patterns of activity in real time. This is an excellent defensive step, but, I suspect, very hard for the bank to do. And, as a customer, how can you tell which banks do this and which do not? And, among the banks that do it, what is their definition of unusual? Can the customer define limits?  

Then too, a relatively normal pattern of activity may well be fraudulent.

This can be dealt with using alerts that notify the customer via text message, email or an automated phone call of transactions over a certain amount of money that the customer can define.

My bank, Chase, fails in this area. I would like to be warned any time more than x dollars comes out of my accounts but Chase won't do this because I don't have an online banking account. Anyone who walks into a Chase bank with fake ID can take money out of my account and instead of knowing within minutes, I won't know until my next statement arrives in the mail.  

Recently I had money withdrawn from my account by an honest mistake by the bank. They quickly made good on it, but I didn't notice the transaction until weeks afterward. How 1980s.  

The editorial correctly points out that small businesses are especially vulnerable to online banking scams, but cites the fact that they can't afford "high-technology defenses" as one reason. This ignores one of the elephants in the room: Windows.

Online banking users need to avoid Windows before they worry about high tech defenses. Almost all malicious software targets computers running Windows. A computer running Linux or OS X is hugely safer, without doing anything else.  

The big advantage Linux has over OS X is cost, as it doesn't require a dedicated computer. A Linux distribution can be installed on a CD or USB flash drive and run on most Windows computers (after re-booting). People without the technical skills to create their own copy of Linux can buy it, fairly cheaply, on a CD or USB flash drive.

Finally, there is yet another elephant in the room that is online banking: fraudulent copycat websites. When someone goes to they may end up at a copycat website designed to steal logon information. 

This topic doesn't come up much, perhaps because few journalists understand how to pull this off, but techies know many ways to do this (see below).

Could you tell if this happened to you? The only guaranteed giveaway is the IP address of the website, even the SSL certificate does not insure that the site is the real deal.

Perhaps one day online banking will truly be safe. But until there are no more man-in-the-browser attacks, until Windows defends itself better from malware and until there is no need to check IP addresses, it remains far too dangerous, at least for someone interested in Defensive Computing. 

How a victim may end up at a malicious copycat website when they navigate to 

1. Modify the hosts file

2. Modify the DNS servers on the victim computer 

3. Modify the DNS servers in the router

4. Compromise the DNS servers of the ISP or corporation

5. Intercept DNS queries and respond before the target DNS server

6. I'm not 100% sure, but if the victims computer is configured to use a malicious proxy, this too may send them to a scam website

7. When connecting to a public wireless network, a victim may connect to an evil twin router in which case all bets are off

For victims that fail to notice the lack of SSL security (HTTP being used instead of HTTPS), sending them to a copycat website is sufficient. 

For victims that do look for it, there are tricks to display a lock icon even without any SSL.

And finally, the actual certificate itself can be bogus. There are almost a dozen ways to pull this off. 


Copyright © 2012 IDG Communications, Inc.

Shop Tech Products at Amazon