Bank One Online Puts
Customer Account Information at Risk

Date: 2000/10/25 20:08:32 
Revision: 1.0

This report is also available in PostScript.

Abstract:

The Bank One Online Banking service uses an insecure method of storing customer banking information, which puts customers' credit card numbers at risk of exposure. Access control to customer accounts also appears to be lacking. The risks that we discuss here are not theoretical; these are real problems that must be addressed immediately.

1 Overview

  Bank One's online service provides a method for customers to retrieve account information via a web browser interface. While providing a convenience for customers via a secured (encrypted) page, the mechanisms of the rest of the system are implemented such that the benefits of encryption are defeated for perhaps the most typical attacks. The convenience is for a customer to store his account number on the local machine. (The Bank One site refers to this as an ``Access ID'' which is the credit or debit card number of the account holder.) By failing to deselect the option ``Save Access ID on this computer for future logins'', the user allows the account number to be written in the cookies file of the web browser. In future transactions, the Access ID field of the web form is automatically populated with the account(s) of the customer.

Storage of this information on the client side is insecure and the cookie is inappropriately protected against accidental transmission in the clear.

2 Potential Compromise Of Customer Information

  By choosing the convenient method of entering an account number, the customer inadvertently exposes a flaw in the Bank One Online system. There are two primary avenues of attack that threaten the secrecy of the private customer information. Which avenue is most dangerous will depend largely on the environment and behavior of the user.

2.1 Local Disk Access

  Because the account number is stored in cleartext (i.e., not encrypted) in a cookie that resides on the client side, anyone with the ability to read the browser's cookies file can get ahold of sensitive account information that is critical to gaining access to the account itself. Using a normal (unprivileged) user account on a network, we were able to find more than a half dozen Bank One customer card numbers this way. These users' cookies files were world-readable and anyone on this network who knows what to look for will be able to get these account numbers.

On machines where multiple users share the same browser profile, such access is trivial.

Another related attack works just like this, except instead of having access to the local disk, the attacker has access to the same network as the target and the user's cookies file is stored on a ``network drive'', or remote filesystem. In such a case, the sensitive information is likely to be transmitted across the network between the client and the remote filesystem's server in the clear. Thus, even though the cookie itself is transmitted over an encrypted channel (namely TLS [3] or its predecessor, SSL [4]), the action of writing that cookie to disk causes the data to be transmitted across the local network in the clear.

Obviously, any user with administrative access to the filesystem (or its backups) would have the ability to read the sensitive information as well.

2.2 Remote Access to Cookies

  Although there are some basic precautions implemented in browsers to prevent sites from reading each others' cookies, some bugs have caused these precautions to fail [5,1,2]. Thus, there are browsers that will improperly reveal private account information to sites programmed to steal users' cookies.

Additionally, one precaution that could be used is not. Cookies can be tagged as ``secure'', which means that the client will not transmit the cookie to the server unless the connection is encrypted. The cookie with this account information is clearly designed to operate only where the session is encrypted, so that the account number will not be sent over the Internet in the clear. However, the flag that would prevent the browser from sending the cookie in the clear is not set. Thus, any connection to any site in the bankoneonline.com domain where the URL contains the string ``/logon'' will cause the browser to send the cookie to the server, whether the session is encrypted or not.

3 Risks

  The risks here are significant and important, but the information that is exposed is not all of the information that an attacker will need to login to or to abuse the credit card number. Nevertheless, very little additional work is necessary to perpetrate real abuses.

To use the cookie to impersonate the user, an attacker will also need to supply a personal identification number (PIN). With fewer than 10,000 possible combinations, the probability of guessing the proper PIN needed to access the account is not low enough to make such an attack unlikely to yield results. (Although the PIN is four digits long, certain sequences are disallowed, thus reducing the number of possible combinations.) That is, if an attacker were to collect 10,000 cookies, the odds are in his favor that he would guess one PIN from that lot correctly on the first guess. The more attempts he gets, the better his odds are.

In the case where the account number is used as a credit card or debit card, an attacker has an even easier time, since the only other information that the attacker will need to abuse the card in many cases is an expiration date. (Some abuses can take place without knowing the correct expiration date, but in the general case, the correct expiration date will be needed to make a purchase.) If credit cards are only active for three years at a time and the granularity of expiration dates is one month, then the attacker has a one in 36 (12 months times three years) chance of guessing the correct expiration date on the first try. Again, the more guesses he gets, the better his odds are.

Given the potential value of account access or use of a credit or debit card to an attacker, odds like this are completely insufficient for protecting the security of users. The risk here is very real and it must be addressed immediately.

4 Solutions

  First, all existing ``userOption'' cookies from bankoneonline.com must be destroyed. Anyone with a bankoneonline.com cookie should delete it. This can be done manually by the user, or bankoneonline.com can overwrite the ``userOption'' cookie for every user who revisits the site. Also, each user can be required to revisit the site. As long as there are ``userOption'' cookies out there with valid account information in them, attackers will find the information they need to perpetrate crimes by looking in the right place.

For the long term, user authentication for account information access must be made more robust. This almost certainly means decreased convenience, at the very least in the form of longer PINs. However, given the fact that the cost of fraud is borne by the financial system's customers, insistence on convenience far above security will result in higher costs and greater hassle in dealing with abuses of this information. Dismissing security concerns is only in the interest of attackers.

Cookies used to store state information must be made completely unusable outside of the scope of the application in which they're used. That is, a user ID token in a cookie should not be connected to information that can be used to impersonate the holder of that cookie.

Cookies intended to be transmitted only in an encrypted channel should be marked as ``secure'', which will prevent the client from sending the token in the clear. Although one could argue that the server is under the control of the issuer of the cookie and thus able to be guaranteed never to be transmitted in the clear, failing to take advantage of available precautions is poor security practice, particularly when this results in a single point of failure.

5 Conclusions

  The Internet--and the World Wide Web in particular--is fast becoming the de facto standard for communicating, thus making it the emerging foundation for Society. Understanding this medium--not only its advantages, but its problems--is absolutely critical for implementing systems that are trustworthy.

Computing, particularly mainstream commodity computing, has been driven by the credo ``more features, faster, cheaper''. This optimization is completely inappropriate for Internet-based applications, particularly in cases where failure can result in such severe consequences.

We strongly suggest that designers and implementors of systems consider the failures discussed here to learn from these mistakes and to avoid making them again.

References

1

Microsoft Corporation. 
Microsoft security bulletin (ms00-033). 
Technical report, Microsoft Corporation, 2000. 
[online] http://www.microsoft.com/technet/security/bulletin/ms00-033.asp.

2

Microsoft Corporation. 
Microsoft security bulletin (ms00-055). 
Technical report, Microsoft Corporation, 2000. 
[online] http://www.microsoft.com/TechNet/security/bulletin/MS00-055.asp.

3

T. Dierks and C. Allen. 
The TLS protocol version 1.0. 
IETF, January 1999. 
RFC 2246.

4

Alan O. Freier, Philip Karlton, and Paul C. Kocher. 
The SSL protocol version 3.0, November 1996. 
[online] http://home.netscape.com/eng/ssl3/draft302.txt.

5

Bennett Haselton and Jamie McCarthy. 
Internet explorer ``open cookie jar'', May 2000. 
[online] http://www.peacefire.org/security/iecookies/.

About this document ...

Bank One Online Puts Customer Account Information at Risk

This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)

Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were: 
latex2html -split 0 -no_navigation -show_section_numbers bankone-online.

The translation was initiated by Matt Curtin on 10/25/2000