Online Bank Security: Cover Your Assets!

Banks are secure. We all take this for granted. You can see the security; Strong walls, locks, alarms, cameras, vaults, security guards-¦ most of it is visible (physical) security. But there’s another component of security for banks that isn’t so visible-¦ electronic or information security. All banking security is managed, controlled and dictated through various regulations and/or laws as handed down by the Office of the Office of the Comptroller of the Currency (OCC). To quote:

“The Office of the Comptroller of the Currency (OCC) charters, regulates, and supervises national banks to ensure a safe, sound and competitive banking system that supports the citizens, communities and economy of the United States.”

Now this is all very comforting, and makes perfect sense. So, 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?

I recently participated in an assessment for an online bank. We were tasked to assess the security of their online banking application, check out the supporting infrastructure, and perform some data analysis of their internal traffic. What we found was quite disturbing, and has strengthened my resolve to limit my online transactions.

The online application was fairly well done, but we did identify some obvious vulnerabilities that should have been addressed. One weakness we noted was in their messaging service; not exactly an email process, but more of a database oriented message board. It was vulnerable to basic scripting attacks! This means I could embed javascript, html, or other code to trick someone into revealing their account name and password. The simplest ruse would be to create a popup window stating that the session has timed out and they need to log in again, then email this information. The application should check for and remove potential code of this nature. We also identified some very weak password practices. We received some accounts to use for our evaluation. One account had a password of “1234”, while another used the account name as the password. I could write a simple script to attack probably accounts and use these two password examples that would probably result in access to about 1/4th of the accounts.

This was not the only problem we identified, nor was it my biggest concern. The real concerns were with the supporting systems. After evaluating the web-based application we started checking their network for potential vulnerabilities. I was amazed at the state of their systems. First of all, their firewalls were configured improperly. I was able to readily identify their firewalls, down to the version of the OS and the type/version of the firewall. This was readily visible by SNMP! The level of detail available via SNMP is astounding. Windows NT machines running SNMP will display full system information including such details as available services, account names, file shares, and IP routing tables.

Just through this feature I quickly identified critical systems, vulnerable services running on various systems, and I had a full set of account names for use in a brute-force attack. Further scans revealed a full array of standard vulnerabilities across multiple systems. I had full access to some of their systems in approximately 5 minutes.

We also found problems when we analyzed their internal traffic. During the interviewing process we were told that all traffic internally was travelling over SSL for security reasons. Unfortunately, we discovered this was not the case. We found a large portion of the financial traffic travelling in the clear over HTTP, not HTTPS. This not only left account names and passwords vulnerable, but also credit card numbers, accounts for other institutions, and personal information. We also found one administrative account using “password” as its password.

Let’s recap-¦ a poorly designed web application, weak passwords, poor policies and procedures, and a vulnerable infrastructure transmitting information in the clear. Not encouraging if you do your banking online, is it?

This engagement took place back when all the U.K. banks were taking a beating. (Such as “Roundup: UK online banking security crisis” for example), so I started thinking about why online banks were having so many problems. I believe the breakdown in security occurs between the bank and their service provider. Banks take their security very seriously, but day-to-day operations at an ISP are generally run by a collection of “20-somethings” with an average of 2-3 years of IT experience and zero banking experience. I know this isn’t the case everywhere. What I’m saying is this is a common problem for banks that outsource their hosting services to an ISP that lacks a clear understanding and focus on the security needs of an online bank. There are a large number of banks that do not outsource their online service for just this reason. They understand the difficulties associated with having an Internet presence, and they take an active role in ensuring the security of their systems.

How can you know if your bank is safe? What questions should you ask, or what should you look for? Here are some suggestions:

• Is there a point of contact for Security?
• Do they have any security statements or privacy statements on the web site?
• What security measures have been taken?
• Do they use a firewall to protect their web service?
• What about Intrusion Detection?
• Do they have any security-related Service Level Agreements (SLAs)?
• Has an impartial 3rd party done a security assessment of the site?
• How do they protect customer account information?

These are just some ideas to get you started. If you do decide to take your banking business online, please be very careful, and don’t be afraid to ask some challenging questions.