Slashdot Mirror
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?'"
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!
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.
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).
How we know is more important than what we know.