The Problems with Secure On-line Banking
Tim Redhead and Dean Povey
Security Unit
CRC for Distributed Systems Technology (DSTC)
Level 12 S(ITE) Block
Queensland University of Technology
Brisbane, Australia
{redhead, povey}@dstc.edu.au
Abstract
A growing awareness of the commercial benefits of online banking have contributed to a sense of urgency among banks to deploy such systems. However, while security of the communications is usually well considered, most do not sufficiently address the security of the platform on which these applications run. In this paper, we outline two existing on-line banking schemes and describe how this weakness can be exploited to subvert the authentication mechanisms in these systems. The aim is to show that these types of attack are not just theoretically possible, but practical and even easy to implement. We present alternative approaches for securing the authentication of on-line banking applications including a new method that provides an effective compromise between security and other concerns.
Key Words
Internet Banking, Electronic Commerce, Security, Trusted Computing Systems.
With daily newspaper reports declaring secure on-line banking to be a reality (Hickman, 1997; Lynch, 1997; Wood, 1997), the promoters of on-line (Internet-based) electronic banking are investing much time and effort in ensuring the widespread adoption of these schemes. Many of Australia's banks have joined the rush and are developing or promoting their own electronic banking schemes.
These systems all require privacy and integrity of transactions, and most importantly strong authentication. However, while these issues are usually well addressed by the communications protocols used in these systems, there are fundamental weaknesses in the security of the platform on which these applications run. It is well known that many popular operating systems do not provide sufficient protection from malicious programs such as viruses, which may be used to subvert authentication protocols by capturing authentication information such as a PINs or passwords that are entered by users.
This paper seeks to illustrate the common shortcomings of at least two electronic banking schemes that are available in Australia today. These schemes concentrate on the security of the communications between the customer and the bank, but do not provide sufficient protection from other programs on the platform that the customer is using. This is despite explicit mechanisms to address these concerns. The aim is to demonstrate that such concerns are very real, and that users and implementers of such schemes should be aware of the risks that they are taking when deploying Internet banking solutions
The rest of this paper is set out as follows: Section 2 gives an overview of electronic banking schemes and section 3 describes the current state of such applications in the marketplace. Sections 4 and 5 present the problems associated with the electronic banking schemes examined to date, and describe how these security holes can be exploited for work or pleasure. Section 6 outlines some alternative authentication schemes and also presents some new work that may provide an effective solution. Section 7 outlines future directions we could take for this work, and conclusions and references follow at the end.
As a final introductory note, you might try to view this work from the point of view of your favourite major Australian bank who, upon seeing us buzzing gnat-like around its newly created on-line feast, is just as likely to lash out and swat us! Thus, we will not detail the identity of the banks whose schemes we have studied; we leave this as an exercise for the reader.
Electronic banking aims to provide easy access to banking services for customers. Both banks and customers stand to benefit from the introduction of electronic banking schemes, since the bank can offer its services at much lower cost, while the customer can access the services from any location at any time. Indeed, these benefits can obviate the need for branches or tellers altogether, resulting in the emergence of so called virtual banks, who conduct business purely on an electronic basis.
This paper concentrates on Internet-based electronic banking. Such schemes rely on the existence of an Internet connection over which a customer can access a bank's services. There are a number of models that can be adopted to implement such a system, each of which are described below.
The Australian banks that we have examined have both chosen to implement the third model for Internet banking and so provide executable applications for customers to download from the bank's web-site. This is probably due to the weak encryption provided by export-crippled software that is available for the first two. (Of course, in this age of heterogeneous systems and open standards, executables are generally only provided for Wintel platforms).
Services which are currently offered via Internet banking schemes are similar to those offered by many phone-banking services and includes facilities that allow the user to:
Some banks also include facilities for electronic cash as part of their Internet banking applications, and there are plans for providing other services such as loan applications and setting up term deposits
Most Internet banking applications authenticate users based on an account/client number and a secret PIN. The account number is generally typed directly into a text field, while the "secret" PIN is entered via a GUI-keypad using the mouse. Account numbers are displayed in plain text, while an "*" is written to the screen as each keypad key is pressed. Once the user's information is complete, the application contacts the bank server and attempts to authenticate the user.
Network security is well addressed in all the Internet banking applications we have reviewed, and is based on establishing a secure channel between the user's client application and the server running at the bank. The protocols used provide connection security that has three basic properties:
Australia does not have any restrictions on the lengths of cryptographic keys for domestic use, and so very strong encryption can be implemented. Secure communications based on 1024 bit RSA and 128 bit IDEA have been implemented in at least one of the Internet banking schemes, providing secure channels that are infeasible to break with current technology. According to Schneier, a million 1MIP computers working in parallel would take on average around 4000 years to break a 664 bit public key, and a 1024 bit key would take 1010 years. In addition, unless a weakness is found in the IDEA algorithm, 128 bit IDEA symmetric keys can only be cracked by brute force, a process which would take a billion processors which can try a billion keys per second, longer than the age of the universe (Schneier, 1996).
In summary, the communications side of the Internet banking applications that we have reviewed would seem to be secure, and should remain so for the foreseeable future. However, as we shall see in the following section, such security can be easily subverted, if the platforms on which these secure applications run do not protect them from other malicious programs.
As discussed in the previous section, the problem of ensuring privacy and authenticity between peers over a public network is well studied, and solutions are widely available to implementers. We propose however, that in the development of Internet banking applications, general attention has been too strongly focused on the issues of network security, and not focused enough on the issues of security at the user's platform.
MS DOS has never been evaluated under the US National Computer Security Center (NCSC) Trusted Computer Systems Evaluation Criteria (TCSEC). However, according to the NCSC, "Without modification, it is apparent from the most cursory examination that [DOS does] not implement many of the features required by the C1 class" (NCSC, 1997). Some unevaluated implementations of UNIX would also fail to achieve a C1 class rating.
This of course only serves to document the obvious; most personal computing platforms are not designed to enable segregation of users and data, and do not have the facilities to enforce user authentication and auditing, mandatory or discretionary access control. An application downloaded or installed by one user can generally be run by a second, since there is no concept of file or process ownership or protection.
In trusted computing systems evaluation there is the concept of a Trusted Computing Base (TCB). This is defined as "the totality of protection mechanisms within a computer system, including hardware, firmware and software – the combination of which is responsible for enforcing a security policy" (DOD, 1985). There are two main ways of implementing such a system:
Because, the TCB is a small and identifiable part of the system, it is easy to be confident in its ability to enforce the security policy correctly. In general, the existence of a TCB is a prerequisite for enforcing the security policy in any secure system.
However, in the case of an operating system such as Windows 95, there is no identifiable TCB on which a trusted system can be based. The operating system does not provide a security kernel to control access to resources. Any application can access any file on the system, and can observe (and perhaps alter) the flow of messages between hardware devices such as mice and keyboards and applications. Because there is no way for an application to prevent other applications from accessing resources and information, and this feature is explicitly not supported by the operating system, an application cannot enforce its security policy in this way.
Additionally, it is very difficult to implement a system that provides a TCB by filtering. Because access to resources cannot be prevented by the operating system, we must attempt to construct a perimeter around the entire machine to ensure it is protected. In other words the security filter must operate on every piece of data that enters or leaves the system. While such a system is conceivable, and certainly exists in certain high security environments (like defence), it can be assumed that most users will not operate in such a restrictive environment. Although, virus scanning downloaded documents/programs may seem like one way of implementing such a filter, it is insufficient on which to base a secure system that has such high security requirements as Internet Banking. This is because of the rapid ways in which viruses evolve and the difficulty of determining whether given data actually contains a virus or not.
Hence we must consider that any secure application that we deploy will be operating in an untrusted environment. Therefore, the design of such applications must take this into account. There are many imaginable scenarios that could be used to illustrate dangers inherent in executing critical applications in such an untrusted environment. However, we will center on just one scenario in which a user executes an arbitrary piece of malicious code without even realising they are doing so – the computer virus.
A virus is generally small program that is able to replicate itself when executed (Atkins et al, 1996) and perform some unsolicited action, either benign or malicious. Viruses can take the form of executable programs or executable system files that are introduced onto computers via downloaded/copied infected programs or corrupted floppy disks. Viruses can also take the form of programs written in an application's macro language. Such macro viruses can be attached to files such as word-processing documents intended for the target application, and will be executed when the file is processed (CIAC, 1997).
Regardless of the method that a virus uses to replicate itself, there can be no doubting the effectiveness of the general principle. Older studies (Cohen, 1994) have shown examples where a single virus was planted and overtook an entire system in times ranging from 5 to 30 minutes. Virus scanners are available on the market, and while some products employ a number of detection techniques and include frequent updates for newly detected viruses, studies indicate that the incidence of infection is growing. A 1996 survey of 300 organisations in North America indicated that 98% of them had experienced at least one virus infection (NCSA, 1996). In addition, the survey also showed that the likelihood of virus infections has increased dramatically from 0.2 infections per month per 1000 PCs in July 1994 to 14.4 infections per month in February 1996. This represents a massive 7100% increase in infections over a period of just over 18 months.
When a virus runs on a platform that has no concept of ownership or access control, any application that runs on that platform may be compromised. Even if access control is enforced by the O/S or by additional hardware, the virus techniques can still work (albeit slightly less effectively). While the O/S process management can ensure that other users' processes are safe from direct intervention by the malicious process, the processes owned by the 'owner' of the virus can still be compromised. Furthermore, techniques exist for eavesdropping on the traffic that flows between windowing server and client applications and such techniques can compromise any GUI-based application.
In the past, most viruses were either benign or carried out some form of simple vandalism e.g. reformatting the victim-machine's hard drive. However, the demonstration on German television of a virus which used Microsoft's "ActiveX" and Intuit's "Quicken" program to illegally transfer funds to an attackers bank account, heralded a new era for the virus (Chaos Computer Club, 1997). With the emergence of new applications like Internet banking, virus writers may soon find that they can now turn their skills to their financial advantage.
The lack of a TCB on which to base secure systems allows an attacker to subvert the security mechanisms of a banking application using viruses by attacking the way the user enters authentication information such as a PIN or password. This is done by having the virus lay dormant until it detects the critical points when such information is to be entered, then monitoring system events such as key presses and mouse clicks to capture authentication information for later use.
In order to assess the viability of such an attack, we examined two Internet banking applications offered in Australia that both run under the Windows 95 operating system. In the follow section we discuss the results of our efforts.
Interestingly enough, designers of both applications seemed well aware of the existence of the proposed attack. This was evident in the first application we tested by the provision of a "virtual PIN pad for increased security" which seemed to be designed in order to thwart programs which log key presses. Users enter their card number using the keyboard, but are forced to enter their PIN with the virtual keypad. As each key on the virtual PIN pad is clicked an "*" is displayed in an edit control on the screen. Unfortunately for the designers, while this method does stop attackers from logging key presses, the PIN box is a standard edit control, which while displaying "*"s on the screen, also holds the plaintext PIN in its buffer. We were able to retrieve this information quite easily using a technique that we call text scraping.
Windows 95 uses a message-based scheme to control user input. Each window has a message queue that contains messages such as "key pressed", "mouse clicked" and so on. On receiving each input message, a Windows 95 program will either process it or pass it on to the operating system to handle. These messages may also include requests for information from a particular control or window, such as "give me your window text". In Windows 95 it is possible to create an application which monitors the message queues of particular windows and intercept messages before they are processed. In fact, Microsoft provides source for an application called "WinSpy" with their Visual C++ development tool that allows a user to monitor the messages sent to particular windows. In addition to these standard messages, Windows 95 also provides "notifications" when notable events occur, such as a new application starting or an application's window being minimised. Like other messages, these system notifications can also be monitored. Each window in a Windows 95 application has a "window class" which determines the type of window that is being created. Some special windows (known as controls) also have a unique ID that can be used to identify a particular instance of that control on a form.
WinSpy was an extremely useful tool, enabling us to peek inside the windows of the banking applications and find out what the window classes and IDs of particular windows and controls were. In addition its source code provided useful guidance to us, who with very limited Windows programming experience set out to tackle the task at hand (a task which incidentally took less than 10 person-hours to complete).
Our approach was simple. We wrote a program that waited for notifications about new windows opening, and waited for the telltale signs of the bank’s main application window before activating our code. Using WinSpy we were able to determine the unique ID of the OK button which a user clicks when they have entered their card and PIN correctly. Our program then installed a callback function that filtered all messages to this window, waiting for the right moment when the OK button was clicked. As soon as this occurred, the attack application "scraped" the authentication info from the form by sending two WM_GETWINDOWTEXT messages to the Card number and PIN edit boxes that returned the cleartext contained in the buffers of these controls. Having this information, it was a simple exercise to open a socket and push the details off to a server on a remote machine.
The designers of the second banking program we attacked also seemed aware of the possibilities of system monitoring attacks. However, they appeared to have taken a much more sophisticated and novel approach to the problem. Like the previous application, this new one also uses a PIN pad to avoid key press loggers. However, recognising that the co-ordinates of particular mouse clicks in a window are available to attackers, they took the step of having the keypad jump around randomly after each click in order to render this information useless.
The second application also uses edit controls for client number and PIN in a similar fashion to the previous one we attacked. Naively we thought we could use the same approach for this application, but when we scraped the text from the PIN buffer we found that the number had been encrypted with a simple substitution cipher which varied from execution to execution.
We then took the crude (but rather effective) approach of simply capturing a bitmap image of the keypad window after each mouse click and drawing a red dot corresponding to the co-ordinates of the mouse pointer in that window. Microsoft came to the rescue again, with some nice sample source code that we were able to debug and modify to suit our purposes. We modified our code to ship both the client number and sequence of images corresponding to each button click off to our remote server.
The scary thing about these attacks is not that they were possible, but that they were so simple, and that they were so simple despite the fact that steps had been taken to specifically prevent them. Using freely available source code we were able to circumvent the security of these systems in an extremely short space of time. While the mechanisms that were used to "examine" the Internet banking applications were tailored for the Windows 95 environment, one can conceive of similar attacks that may be possible in other operating systems.
It should also be noted that for many reasons (not the least of which is the fear of a plague escaping the lab), we chose not to implement the infection and duplication code as part of our studies. However we did find that sophisticated virus construction kits can be obtained easily on the Internet for the princely sum of US$25 (we leave the rest as an exercise for the reader).
The potential value to an attacker of hacking Internet banking applications means that they may go to extraordinary lengths in order to do so. One cannot assume that an application is safe simply because it is obfuscated (this principle is commonly called "security by obscurity"). As discussed in an earlier section, the security of these applications will only be effective if they are designed to specifically operate in an untrusted environment where no TCB exists. All the banking applications we surveyed used simple passwords as the primary form of authentication. In this section we examine some of the other more advanced authentication techniques and discuss their applicability to Internet banking applications.
In one-time password systems, the password entered is only valid for a single login, and then changes in a secure way. The benefit of such a system is that monitoring by an attacker is useless, as the information available to them can not be reused. This is an example of a system that is specifically designed to operate in an environment without a TCB. One such system in widespread use is the S/KEY system developed at Bellcore (Haller, 1994). S/KEY uses a secure hash function called MD4 (Rivest, 1992) to generate passwords. This is done by iterating a secret password s through the hash function f, N times
p0= f N(s)
Subsequent passwords are then generated by only running the hash function N-i times, where i is the number of logins.
pi= f N-i(s)
Because the hash function is secure, an attacker with knowledge of pi cannot compute pi+1 without knowing the secret password s. However, a server can verify the correctness of a password very simply by applying the hash function to it and comparing it to a previous password
pi-1 must equal f(pi)
If the two don't match then the server rejects the user.
While a hardware/software calculator can be used to calculate the appropriate S/KEY from a given secret key and N value, it is also possible to generate a list of keys and have the user enter them manually. This would be beneficial in banking systems as software calculators still operate within the untrusted system, and hardware calculators are likely to be expensive. However the disadvantages of this scheme are that administration is complex, and the user has to store a list of keys on a sheet of paper, creating the potential for theft and misuse. For these reasons, it is unlikely that a bank would adopt such a scheme, or that the public would accept it, even if it were implemented.
Token based systems provide authentication of a user by requiring them to demonstrate the possession of a physical object or token which is unique to that user (NIST, 1994). There are basically three types of tokens:
Memory tokens are of little use for Internet banking, as the authentication information on them will be available to an attacker by monitoring. However, as the encryption stage is done offline with both smart cards and hand held password generators they are impervious to monitoring. In this way, the TCB of the application is provided by the token itself, which exists as independent unit, and implements its own security policy. Smart cards are particularly elegant, as they interface seamlessly to the computer and avoid the unwieldy entering of data that is required for the other schemes. Unfortunately, all these schemes require the purchase of extra hardware, making them unattractive to both banks and their customers.
Despite the availability of these more advanced authentication schemes, the disadvantages in terms of cost and maintenance make them impractical to use for banking applications. Clearly we must devise a new scheme which can be implemented simply and without the need to purchase extra hardware. In order to determine what properties such a scheme will have we will illustrate the operation of one of the better alternatives and demonstrate how we can use that analogy to provide a cheap and secure system for authentication.
Smart cards are small credit-card sized tokens that contain both a CPU and a small memory. The cards contain executable programs stored in non-volatile storage called firmware. The firmware of authentication cards typically consists of cryptographic algorithms which use keys stored on the card to encrypt data input into the card via I/O pins on the its interface. All encryption is done on the card, and the user sees it as a black box into which they put a value and get something back.
This indivisible or atomic operation is what makes smart cards able to thwart monitoring attacks. With no way of intervening between the input of the encryption key and the actual encryption, the attacker is unable to obtain any useful information.
Our approach, the atomic authentication scheme, seeks to emulate this property in software. The approach is to bypass the operating system and create a mini security kernel to provide a TCB for the authentication stage. To do this requires both the disabling of interrupts and breakpoint debugging to ensure that no code (malicious or otherwise) can be executed during the authentication process. This means that operating system services (which are typically implemented with call gates using software interrupts) will be unavailable during this time, and the authentication process must seek to access the raw I/O ports in order to obtain the authentication data. Investigation of this technique on Intel boxes under Windows 95 indicate that this approach is at least feasible, but we are yet to attempt a full featured implementation.
One of the major disadvantages of this scheme is that it is largely dependent on the platform and operating system as to its success. For example, the memory protection scheme that has been in Intel’s x86 family of chips since the 80386 allows the disabling of access to I/O ports to user code. If an operating system implemented this feature then the authentication stage would need to run as a trusted process. In addition, the system is not perfect. It may be possible for an attacker to modify the code that performs the authentication step and substitute a Trojan horse that leaks the authentication information. Nevertheless, we believe that in cases where such an implementation is possible, that atomic authentication provides a useful compromise between the needs of implementers to provide secure systems, and the commercial realities that result in banks deploying these systems for operating systems which do not provide a TCB.
Investigation and full implementation of the atomic authentication method is a top priority. It would be useful to look at both the feasibility of implementing this approach on the multiple operating systems implemented on Intel's x86 chips as well as reading the authentication information from both keyboard and floppy disk.
In addition, it may be interesting to look at generalising the approach to attacks on web browsers. Essentially a web browser is an application like any other, and as such will be susceptible to monitoring. A more sophisticated version of the attacks undertaken could be conceived which could seek to target information entered into forms that are generated from specific URLs. Our surveys indicated a number of other international on-line banking applications that are accessed using web browsers, are likely to be vulnerable to such attacks.
Internet banking has the potential to provide a useful service to customers and banks alike. However, unless more consideration is given to the design of secure applications that can operate within an untrusted environment, Internet banking will remain an activity that is associated with a significant level of risk.
In theoretical terms, the problem is well understood, and there are elegant solutions. Unfortunately, the commercial realities are that these solutions are impractical for widespread use, and systems will continue to be deployed on untrusted operating systems, and at least for the time being without provision for some sort of extra support such as a smart card.
This paper has presented some alternatives to current approaches, including a mechanism which we believe may be a good compromise between the needs of security, and the need to rapidly deploy systems. Finally, at the very least, this paper should raise concerns about the level of security in deployed systems today and make users and developers alike aware of the risks involved.
References
Atkins, D. et. al. (1996) "Internet Security Professional Reference". New Riders Publishing, Indianapolis.
Chaos Computer Club. (1997). Press Release. URL: http://berlin.ccc.de/CRD/CRD-280197.html
CIAC (1997) G-10a:Winword Macro Viruses. U.S. Department of Energy's Computer Incident Advisory Capability. Information Bulletins and Advisory Notices Page. URL: http://ciac.llnl.gov/ciac/bulletins/g-10a.shtml
Cohen, F. (1984) "Computer Viruses". Computer Security, A Global Challenge. Elsevier Press.
DOD (1985). Department of Defense Trusted Computer System Evaluation Criteria (Orange Book). U.S. Department of Defense.
Freier, A.O. Freier, Karlton, P. & Kocher, P. (1996) The SSL Protocol - Version 3.0. IETF Internet Draft.
Haller, N.M. (1994) "The S/KEY One-Time Password System". Proceedings of the Internet Society Symposium on Network and Distributed System Security. San Diego, CA.
Hickman, B. (1997) "Internet banking services to soar" Article. The Australian. Tuesday, April 8, 1997.
Lynch, A. (1997) "Secure banking a reality" Article. The Australian. Tuesday, May 20, 1997.
NCSC (1997) The NCSC's Computer Security Evaluation Frequently Answered Questions Page. URL: http://www.radium.ncsc.mil/tpep/process/faq.html.
NIST. (1994) Guideline for the use of Advanced Authentication Technology Alternatives. Federal Information Processing Standards (FIPS) Publication 190. National Institute of Standards and Technology.
NSCA (1996). NCSA 1996 Computer Virus Prevalence Survey. National Computer Security Agency.
Rivest, R.L. (1992) "The MD4 Message-Digest Algorithm". RFC1320.
Schneier, B. (1994) Applied Cryptography: protocols, algorithms and source code in C.. John Wiley and Sons, Inc.
TPEP (1997) What is the rating of DOS? Trusted Program Evaluation Program FAQ. URL: http://www.radium.ncsc.mil/tpep/process/faq-sect5.html#Q9.
Wood, R. (1997) "Being the first - building the complete first Internet Banking facility in Australia". Proc. 2nd Australian Computer Money Day conference.
acknowledgements
The work reported in this paper has been funded in part by the Co-operative Research Centre Program through the Department of the Prime Minister and Cabinet of Australia.
COPYRIGHT
Distributed Systems Technology Centre © 1998. The Authors assign to ACS and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to ACS to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the SEARCC’98 conference papers, and for the documents to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.