Online Bank Security: Cover Your Assets!

LogError writes: "Randy M. Nash writes in this article: 'Why are there so many concerns about online banking? Where is the breakdown in security? Even brick and mortar banks have internal networks that must be secured. It's my understanding that these are very well secured indeed. What happens when these security-conscious organizations move their presence to the Internet?'"

Re:Online Banking is a joke

> 3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.

If it's a half-way intelligent banking system, they'll have the system set up to ONLY accept 128-bit browsers. If you can hit your bank with an old version of 40-bit Netscape, time to bail!

For what it's worth...

I bank online, and I'm relatively confident about it, but I don't pretend that I'm safe. Bank One seemed to think that by requiring 128-bit encryption, their security needs would be taken care of. I don't know much about the internals beyond that, but my guess would be that any sort of security issues that come about are going to be a result of people exploiting some code quirk, rather than decoding encryption on the fly.

No matter how careful they are, sooner or later somebody is either going to find or stumble upon some back hole into the system, whether it's some nasty SQL that's output that's displayed to the user or just a random glitch.

Re:Regarding sysadmins and security

The Sr. Sysadmin should be able to, in no uncertain terms, explain to the company the importace and *COST JUSTIFICATION* of proper security, and should also perform proper security audits, and instruct his staff accordingly.

In a regulated organisation like a bank, it is most definitely NOT the sys admins (whether senior or otherwise) who should be doing this: it's the Security Manager .

While I fully agree the sys admins should all be security minded , this should be backed up by clear directives (policies/standards) written/approved by a security manager, who has the time and the high-level clout to act.

It's the application stupid!

I see all this talk about 128 bit SSL, the best IDS, the best firewall, etc... All Worthless against a good Application hack. Take a study by the ICSA, "Out of 5000 hacks, 2/3 were at the application layer"! Hell, take a study of all the financial sites out there to have gotten hacked. Go further and look at all the high profile sites that have been hacked recently and you will see one thing in common - the hack targeted the web app. No network security device can prevent a web application layer attack.

Just spent a fortune on that cool network IDS system? Great, well guess what, SSL renders it useless because you can't watch encrypted traffic! So now the hacker is hacking securely as they come right through your firewall on port 443 and just mucks with your web site while you have no clue what's happening.

It's an accepted fact that all code has bugs, your web site is based on code, it has bugs, and it's only a matter of time until the hacker finds a way to exploit them, and most of the time you won't even know.

The problem requires a new approach, you need an web application layer IDS, and this is not entirely a easy thing to do. You have to be able to understand the application in real time and process the SSL transactions yourself, in essence you end up with a very smart (and hopefully fast) reverse proxy. There is only one company out there (www.sanctuminc.com [sanctuminc.com]) that's doing anything at all to solve this problem and they are worth checking out if you are really serious about locking down your web site.

Until the banking world grasps the real problems of application security, sites will continue to get hacked and defaced. Go ahead, hide behind your firewall, your SSL, your IDS, I'm going to come in, right past all of it, and rip your web application to shreds while you watch your firewall and IDS logs - and see nothing.

If you build them like I do...

My last job (I left earlier this year, the creative design part was over and I got bored doing routine administration) was an Internet Systems Engineer for a large bank/credit card company/merchant processor.

We built that system as impenetrable as we could. Extreme security, multi-level DMZ design, black IP, major intrusion detectors, dead-end fake IP subnets, quite a few traps and, uh, planted 'distraction', and of course 128-bit SSL. It's been running for almost two years now, and noone has come close to hacking it. The firewalls and intrusion detection software usually record several attempts per day, usually just script kiddies, once in a while a 'real' cracker. But nobody has ever got in, and if someone did, I would definitely be one of the first to know.

We even hired some top-of-the-line, extremely good professional hackers, and they were only able to gleam the tiniest amount of information about the topology of the network.

The only bad thing about the bank site is that the HTML coders have made one of the ugliest, lamest sites I've ever seen. They sure could have done a better job, but it's at least usuable and extremely secure.

I use it myself, and feel safe doing so, especially as I implemented a lot of the security myself, very very carefully, as if I made an idiot mistake I would be held PERSONALLY liable. Kinda scary knowing how many billions of dollars are in that bank, and it's my ass if they get through. But I'd be very very surprised (and very respectful of the person) if anybody actually got through!

I don't know about other banks, but this one is tight. (Sorry, I cannot disclose which bank it is without written permission from them, or I'd be happy and proud to tell you.)

As far as the one bank someone was talking about that didn't even use SSL - you'd better find yourself a new bank - FAST!

Online Banking is a joke

There are several issues that make online banks easy targets:

1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.

2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away.

3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.

4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.

5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.

The Myth of Bank Security

I developed a credit card processing gateway in Australia. We dealt with ANZ, Commonwealth, Westpac, St. George, National (NAB) and a number of overseas banks. The security of the ATM/EFTPOS network left us flabergastered. Your average corner store receives a device called a "pin pad".. This is the thing you type your pin number into. It connects to a 2400 baud modem which runs into a standard phone line. A place like us who does thousands of transactions a day (and places like Coles and Woolworths) connect their modems to a "secure" line that is essentially a normal telephone line that goes through different switches. This is called a tran$end line (yes, the $ is intention). Either way, your modem dails out to a remote computer that is connected to the X.25 network. Software in the pin pad generates an x.25 packet with the card details (tracks on the swipe card and the pin number) encrypted with a 56 bit DES key which is set up by the bank when they issue the pin pad to you (a shared secret). The packet is passed blindly onto the x.25 network and the receiving bank does switching to people like visa for credit card purchases or they handle the packet themselves. SWIFT transactions are done the same way. When you are doing online banking, instead of plugging the pin pad directly into the modem, you plug the pin pad into one serial port on your computer and the modem into another serial port. You then run client software on your computer (NT only) which fills in the blank fields of the packet, hands it off to the pin pad to be encrypted and then passes it off to the modem to be sent. Out of curiousity we started reverse engineering the format to the pin pad messages. Essentially it's an ASCII'd version of the x.25 packet with a request byte at the start. Using a plain text attack we were able to recover the DES key from the pin pad and encrypt the packets ourself. It was only after we set up the NAB system that we learned how futile this was. The NAB system uses an NT box (they supply the box) which has no hardware encryption device. The encryption is done by the PC and the DES key is stored in a file on the hard drive. The NAB system is totally insecure. They preinstall PC anywhere on the computer and then dialup to the PC over the tran$end network. Yes, that's right, search bugtraq and you will find an outstanding bug, "PC anywhere passwords passed in the clear". Anyone monitoring your phoneline can see the password and at 2400 baud that is very easy to do. Not that it really matters anyway because they NT box we received from them had not even had any service packs installed. The reason: "we don't run any database or web servers so we don't need the upgrades which these are mainly for fixing". When we asked them where they stored the transaction logs they replied: "in an access database" on the harddrive. I was shocked to find that this included credit card numbers (all the other systems XXX out the middle digits). The commonwealth bank was the securest system I saw. Your web server SSH's to their gateway using an RSA key for authenticity. But perhaps the scariest part of all this is that the entire Australian banking system is outsourced to third parties. This results in the bank having absolutely no idea what they have to do to set up a new client and the rebound of calls from third parties to the banks and back. The bank will give you account numbers which you type into the software and it won't work. So you'll call the vendor and they say "oh.. you just have to add a zero" that doesn't work, so you call back and they say "ahh.. actually you need to convert it to hex and add as many zero's to the end to make it 16 digits then convert it back to decimal" you do that and it doesn't fit in the field anymore and after some head scratching they say "drop the last digit on the decimal representation" and you do and it works. This is scary. Many times we rang up the banks and said we had to change contact details and get new pin pads for our clients and the first few times they demanded that we get written authorization from the client. We quickly learnt that when we call the banks we should claim to be from the client company and they never asked for authorization. Social engineering at its finest. It is strange. You get the feeling talking to banks in Australia that you are talking to public servants - even though all the banks are publically owned. You could tell them anything. Ask anyone who has worked in credit card processing and you will hear stories. We once charged a million dollars to the bosses credit card then charged back 1.2 million then rang up the bank and asked them to reverse it. And this is all done by entering fields into a web page that has ASP as the backend and is protected with code like 'if Request.Form("password") = "sekret55" then'.. We built a pretty secure system in the end but we didn't have much to work with and frankly I still don't trust credit card processing, especially people like Amazon who keep your credit card details in a database. (which BTW is illegal in Australia.. try telling your clients that).