Security Review: Online Banking

By chernyak at 10:04 am on February 12, 2008 | 5 Comments

Online Banking – Many banks now provide an online application that will let the bank’s clients manage their funds. This includes both, viewing, as well as transferring funds to arbitrary third parties through a feature called ‘Online Bill Pay.’ Thus, given access to a user’s online banking credentials, an adversary can easily drain the user’s funds.

Assets and Security Goals

  • Availability. The online banking application should be available at all times for bank clients
  • Funds. Adversaries should not be able to affect funds.

Weaknesses

  • Adversary may attempt to disrupt service. As an online service it is susceptible to any sort of denial of service attack. Denial of Service attacks come in many flavors including floods of ICMP packets or at the application level. Alternatively, Distributed denial of service attacks may be performed pooling the resources and bandwidth of many computers to perform the attack.
  • Adversary may attempt to extract/move/increase/decrease funds in a non-legitimate manner This can be done in many ways. Some examples:
    • Phishing: Adversaries can register URL’s that use unicode characters but render identically to the name of your bank. They can then send emails requesting customers re-enter their personal data, or trick users to interact with their page instead of the legitimate bank’s page.
    • Adversary may install a keylogger on a public terminal. When an unsuspecting user uses the terminal to conduct online banking, their credentials will be logged by the keylogger. The adversary can then emplpy their credentials to drain the user’s account
    • Some banks (untill even very recently) used to send online passwords in the clear, or encrypted in an insecure way (SSL was not used!). A packet sniffer attached to the network with a user performing online banking could then reveal their credentials.
    • As we know, SSL is susceptible to a man-in the middle attack. If an adversary masquerades as an access point (say at an airport or coffee shop) then when a user performs online banking over SSL, the adversary will be able to spoof the SSL session with only the slightest hint to the user that something may be wrong. An unsuspecting user will likely not examine the certificate authority and continue
      banking as normal. In the process, the adversary will have full control of the user’s banking session.

Potential Defneses

  • Defenses against DoS and DDoS: There are lots of ways to defend against a DoS including firewals and other network hardware that can differentiate good traffic from DoS traffic thus reducing the ammount of traffic your services have to contend with.
  • Defenses against phishing: Most browsers will now detect and warn about potentially adversarial URL’s that attempt to masquerade as others. Users should also be on allert since it is unlikely that their bank would suddenly request them to re-enter personal information.
  • Keylogging:
    Don’t use public terminals for secure communications – you cannot trust the computing
    environment on a public terminal
  • Plaintext passwods:
    Banks should use secure communication at all times.
  • SSL MITM Attacks:
    Examine the CA for your session carefully and make sure it is trusted.

Risk Evaluation

  • Phishing – high: Individuals may not notice the hoax and, since they trust their bank, re-enter their private information.
  • Keylogging – high: Many individuals will need to check their ballance on the run – for example when they are at an airport or out shopping. An internet kiosk can be convenient, but it may come with a keylogger.
  • plaintext passwords – low: most (hopefully all) banks have switched away from this.
  • SSL MITM attacks – medium: this one is somewhat difficult to trick the user into and relies heavily on chance (both that the user will connect to the adversary’s access point, and that the user will not examine the CA for the SSL cert)

Conclusions

The risks in online banking are high since there is potentially a direct monetary gain for an adversary attacking this system. Thus it is absolutely essential that both the applicaiton provider (the bank) and the user take all the security measures seriously and consider the security of their communications channel diligently.

Filed under: Security Reviews5 Comments »

5 Comments

  • 1
    Get your own gravatar for comments by visiting gravatar.com

    Comment by Robert

    February 13, 2008 @ 3:11 pm

    Many banks are also implementing various other mechanisms to ensure identity and protect against phishing. Bank of America, for instance, requires each user to select an image from a large bank of images. They call this a Site Key and it is used in conjunction with the SSL cert to ensure site identity. This is easier for the average user to use because they don’t have to worry about browswer warnings or certificate problems.

    The Alaska USA credit union requires users to enter their password on a keypad that contains randomly placed numbers and letters. The keypad also has a background that is of the user’s choosing. This is another mechanism to ensure identity and protect customers.

  • 2
    Get your own gravatar for comments by visiting gravatar.com

    Comment by Max Aller

    February 13, 2008 @ 4:45 pm

    Hey Robert.

    While the idea of a site key is nice, it’s simply not effective, as outlined in this news article that cites a Harvard/MIT study from a little over a year ago. Basically, people don’t notice and/or care if their site key is missing. That seems a little problematic. Despite the age of this article, Bank of America still has done nothing about it…in my mind, BoA should have 1 in every, oh, 20 logins result in a page that doesn’t have their site key. If the user proceeds as usual by typing in their password, a “You Could Have Been Phished” warning pops up. If you look for the link “Why isn’t my site key shown?” it takes you to the regular login page with a happy message at the top to the effect of “Congratulations, you passed”.

    Anyway, read the article. It’s interesting.

  • 3
    Get your own gravatar for comments by visiting gravatar.com

    Comment by Robert

    February 13, 2008 @ 10:26 pm

    Thanks for the info, Max. It seems like the most difficult piece of security to control is the end user. This leads to an interesting ethical question: At what point does the burden of security pass from the company to the user?

  • 4
    Get your own gravatar for comments by visiting gravatar.com

    Comment by esoteric

    February 17, 2008 @ 6:10 pm

    I recently switched to Bank of America, and another defense mechanism employed by this bank is that it keeps track of the valid IP addresses that are allowed to login to a particular account. When a user tries to login to his or her account from a new IP for the first time, BoA’s website asks the user to answer a personal security question before allowing the normal login system to be used. This feature, along with the aforementioned graphical site key system, shows that Bank of America is really attempting a defense-in-depth approach to online banking. These added security mechanisms are of little hassle to a legitimate user, but represent major roadblocks for an adversary.

  • 5
    Get your own gravatar for comments by visiting gravatar.com

    Comment by justin

    February 18, 2008 @ 12:19 am

    Max-

    Though it may be the case that the site key mechanism has failed thus far to be effective for the average user, if viewed as more of an “opt-in” security measure I find it highly effective — because I do opt to use it to enhance the security of my sessions.

    I try to be mindful of warnings about security certificates, but having the site key mechanism gives me nearly full confidence that the site isn’t being spoofed. Without it, there would exist the possibility that someone could spoof the BoA site without SSL and I wouldn’t notice it. I would hope not, but who knows.

    In any event, it certainly would be nice if they threw up a bogus site key identifier every once in a while. But I suppose the risk is that it would cause more harm than good, as I suspect that a large percentage of people would refuse to internalize what something like the “sitekey” is or how it can be useful, no matter how many times the virtues are extolled.

RSS feed for comments on this post