Secure Security Software Curry Dulcie Alex Wong

Abstract

This project demonstrates the need for software security in security software. Just as in any other piece of software, security software requires secure development. This project provides a demonstration of a serious vulnerability in a potential implementation of a one-time password verifier for S/KEY[1].

1

Table of Contents

Abstract............................................................................................................................... 1 Introduction ........................................................................................................................ 3 Background ......................................................................................................................... 5 Examples ............................................................................................................................. 9 Results............................................................................................................................... 11 Conclusion......................................................................................................................... 14 Group Member Biographies ............................................................................................. 15 References ........................................................................................................................ 17

2

Introduction

Our project originally was aimed at creating a one-time password challenge-response system in userspace. The OTP challenge-response system would be based on a shared key between the client and the server, with the client running the J2ME software stack, and the server running the J2SE with Servlets stack. The OTP itself would be transferred over TLS (using HTTPS). A practical reason for wanting a userspace-only OTP daemon might be to allow portability between operating system platforms. For our project, we wanted to develop a usable set of tools for deploying one-time passwords to applications on the web while leveraging the existing base of mobile devices that can use J2ME applications to provide the necessary calculations. We felt that the existing OTP solutions are rather difficult to use and prone to usability problems; for example, Lamport's Scheme usually involves keeping a list of passwords on paper and is restricted in the number of times the password may be used [3]. This, combined with the fact that Lamport's Scheme uses dependent [7] passwords, motivated us to search for a better solution. Disclosing any later key in a chain for Lamport's Scheme can reveal all prior passwords [7]; thus, keeping the last password secret is extremely important in Lamport's Scheme.

Our advisor for this project, Dr. Csilla Farkas, suggested that our objectives would be considerably more complex than we envisioned, so upon her approval, we have modified our objectives. The new project is related to one-time password schemes, but

3

it is much more general. Instead of implementing an OTP scheme, our project demonstrates how a poor implementation of an S/KEY[1] verifier could be exploited to allow arbitrary remote code execution. In particular, we demonstrate the need for software security (e.g. secure design and implementation) in security software.

Security software and software security are two very different concepts. Security software is software that is developed in order to protect data and other objects stored on a system or even the system itself. Software security, on the other hand, refers to the process that is used to develop any type of software. Making certain that a secure development process is used is extremely important to all software, but such a process is especially important in the case of security software.

Even if secure guidelines are followed to build the framework for a piece of security software, insecure implementation will make it insecure overall. Security is only as strong as its weakest link, and harmful users only need one weak spot to undermine the security present in the rest of the software. In addition, since security software is developed for the purpose of protecting data or systems, if the security on security software is undermined, the data or entire system will be put at risk.

There are few papers which focus specifically on secure software development in security software, although secure software development is universally encouraged and considered to not be utilized as often as it should be.

4

This paper will cover some background information on one time passwords and security software including some potential problems and limitations with one time password systems. We will then present a few examples of security software which contain software security issues corresponding to a few of the software security sins discussed in 19 Deadly Sins of Software Security by Michael Howard and David LeBlanc. Next, we will present our project, which demonstrates the need for secure software development by discussing a potential verifier from an implementation of Lamport's scheme. Finally, we will wrap up with our conclusions and a brief biography of the contributors to this project.

Background

Passwords are a common technology used today to control access to computer resources. Other ways of controlling access, such as biometrics or hardware tokens, are less often deployed. Passwords are inexpensive, are easily replaceable, and provide a reasonable level of security when compared to biometric authentication or hardware token authentication. Biometric data used to authenticate a user is considerably more difficult to replace when stolen, and both hardware token based authentication and biometric authentication are considerably more expensive than a password-based authentication solution.

One variation on employing passwords for authentication is the use of one-time

5

passwords. While most people are familiar with the usual approach of recalling a password and reciting it to a system, one-time passwords change this in a slight way. Of course, password authentication can be combined with other forms of authentication to form hybrid systems. One-time passwords provide a primary advantage over traditional passwords -- they prevent the replay and reuse of old passwords. This means that an attacker who intercepts a password would not be able to use the password in the future to gain access to a resource, although the attacker may still be able to gain access to the protected resource for one session.

One-time password systems can be employed in various situations to improve security. For example, OTPs can be used at a public access terminal by a user who wants to access a resource, such as email, without being concerned about divulging his password to a keylogger. An OTP can also be used to authenticate over a clear-text channel, such as a Telnet session, without worrying about a potential attacker replaying the authentication exchange to gain access to another session. Of course, OTPs do not protect against other issues; for example, with Lamport's Scheme or OTPW, a Man-inthe-middle attack is possible. OTPs also do not provide confidentiality to the payload. Systems such as SSL/TLS or SSH are often used in conjunction with OTPs to provide confidentiality to the payload. Such issues are not covered in this article.

Modern one-time-password systems include Lamport's Scheme (S/KEY[1]) [4], OTPW[1] [5], hardware token-based (RSA[1] SecurID[1], Aladdin[1] eToken[1], Aladdin[1] SafeWord[1])

6

systems, OTP over SMS, N/R OTP [3], Independent One Time Passwords (from Bellcore), and software OTP calculators ("soft tokens" such as RSA[1] SoftId[1]). These one-time password schemes are used to provide additional security to a system by avoiding the reuse of passwords.

S/KEY[1] is a scheme for providing one-time passwords through the security afforded by the computational difficulty in reversing a hash function. The S/KEY[1] protocol can provide a high level of security to the authentication subsystem of a larger subsystem, but only if the rest of the system has high quality code without any serious vulnerabilities [4].

While the protocol may have been verified to be computationally secure, this does not always translate into computationally secure software. If the software for S/KEY[1] is implemented poorly, vulnerabilities may exist that compromise the security of the entire system. As with any other software flaws, there are conditions that mitigate this risk as well as conditions that increase the risk associated with any implementation.

Consider, for example, an implementation of S/KEY[1] using the standard dictionary. At some point, we know that verifier will need to read a string with a certain maximum length from the user. The string may contain a sequence of hexadecimal characters or a sequence of four or five letter words from a dictionary. The words are separated by one or more whitespace characters. In a language such as C, what

7

happens if the string length exceeds the buffer that is allocated for it? Perhaps the implementer chose to allocate 100 bytes, which would be more than enough for 14 words of 5 characters each, with one space between each word. Surely that's enough for a valid S/KEY[1] password! If one is conscious of secure design principles, though, he would need to handle longer passwords gracefully. A regular call to strcpy could allow an attacker to overflow the buffer and write into the stack of the security software.

In a language such as Java, though, buffer overruns are more difficult to exploit. All array buffers in the Java language are bounded, and the runtime provides bounds checking when reading from and writing to the arrays. This doesn't mean that it's not exploitable by a malicious user; it just means that it becomes more difficult. For example, if a verifier similar to the one mentioned above were implemented in Java, an attacker could cause an exception to be thrown, which might terminate the execution of the verifier. This may cause loss of availability, although it would not immediately provide a way to execute arbitrary code as it would have in the previous example. This problem is not limited to implementations of S/KEY[1] alone, but can exist in any kind of software implementation, security-based or otherwise. This means that it is not a failure of S/KEY[1] specifically, and that it is an extremely important issue to keep in mind. In particular, a poor implementation of other one-time password schemes, such as OTPW[1] [5] could also be vulnerable. Additional precautions must be made for OTP schemes on embedded devices. Embedded devices such as cell phones and PDAs are

8

easy to lose. This may provide a window of opportunity for an attacker if proper precautions are not made. Other considerations that should be made include possibilities of the underlying system compromising the security of the one time password. For example, with the significant market penetration of cell phones, SMS is one of the commonly used methods to deliver OTPs. However, Barkan et al. have shown [1] that an active attack on the GSM protocol can force mobile handsets to switch from the A5/1 cipher to the A5/2 cipher. The A5/2 cipher is considerably weaker, and the key can be recovered after the attack to decrypt message transactions between the mobile handset and the carrier.

Examples

Suppose a piece of security software has a remotely exploitable buffer overflow. For a piece of security software, this is very troubling. A buffer overflow may allow an attacker to gain control of the vulnerable application. Security software is supposed to protect against attackers. It isn't supposed to aid the attacker. However, a buffer overflow does exactly that. While this doesn't appear to happen very often when examining CVEs, a few of them do appear:

9

CVE-2010-0107 - Symantec[1] - Norton Internet Security[1] - buffer overflow. Arbitrary remote code execution CVE-2007-5603 - SonicWall[1] - SSL-VPN NetExtender[1] - buffer overflow. Arbitrary remote code execution CVE-2006-3961 - Network Associates[1] - McAfee Security Center[1] 6.0.23 - buffer overflow, arbitrary remote code execution

Buffer overflows aren't the only issue. Any other software security issue can affect security software, too. Consider, for example, the common use of the Cisco Clean Access[1] NAC product with a self-signed SSL certificate. While this may or may not be the intended deployment by Cisco[1], it is clear that such a deployment occurs, and it provides an avenue of attack. For example, a Man-in-the-Middle attack would be possible with such deployments. Even at the University of South Carolina, I have seen rogue wireless access points which attempt to trick users in inputting their network password to a fake Cisco Clean Access[1] NAC page for wireless network access. Since the SSL certificates for the NAC software were self-signed at the University, it would have been difficult for most users to tell if the connection was hijacked or not.

In our example security program, we do not present a buffer overflow, since the Java programming language makes buffer overflows extremely difficult to exploit. Instead, we opted to demonstrate easier flaws: improper input validation and command injection.

10

Results

We have implemented a simple verifier for S/KEY[1] in Java. Our verifiers are highly restricted in order to show our point. The user database, for example, is always initialized with static data every time that the program is run. Our verifiers also only accept hexadecimal input for passwords. A full implementation of S/KEY is required to support the standard dictionary encoder for S/KEY OTPs as well as hexadecimal input. One can envision the possibility of creating a converter from the dictionary words to the 64-bit hexadecimal string required for our software. In addition, there is no way to externally modify the database without modifying the source code. Each user record is also read-only, which is unusual for an implementation of a one-time password scheme. For this latter "deficiency," two lines of code may be uncommented to produce the desired effect of providing a OTP verifier; the reason that this project is shipped with the lines commented is to demonstrate the correctness of the vulnerable verifier for a "regular" input. One verifier is the "correct" verifier; as it stands, I believe it would be difficult for a regular attacker to manipulate it. The other verifier is immediately vulnerable to a command injection vulnerability, provided that arbitrary usernames may be selected.

The OTP verifiers print debugging information to the standard output if zero or one

11

command line arguments are passed. In particular, for the dummy user database in our code, two users with the same password are stored; this password is printed to the standard output so that the user running the program can easily test the functionality of the code. Two arguments are required for normal operation. To run the program, one would type this at the command line:

java -jar otpbug.jar 1aaf88620391e19b alice

In this case, each verifier looks for the user "alice" and checks the password of "1aaf88620391e19b". Originally, I had intended for the poorly implemented verifier to cause a command injection vulnerability through the user's password. It was difficult to provide an input to trigger the command injection because of the eight-character (=64 bits) restriction. I imagine something like "|rm -r /" could be used, but it was significantly easier to use the user name instead, which, in this case, is unrestricted in length.

Our program uses a dummy database containing two users. The users are "alice" and "bob.tmp ; mkdir hello". One can imagine a scenario in which a program including this password verifier may also allow arbitrary usernames without validation. In such a case, the entire system is vulnerable to the problem that this program demonstrates.

To see the vulnerability in action, one would need to login using the username

12

"bob.tmp ; mkdir hello" and the password "1aaf88620391e19b" on a Unix-like system with OpenSSL in the PATH environment variable. As it is implemented, the password need not be correct to exploit the vulnerability. If the program is combined as an OTP verifier with arbitrary usernames allowed, the system would be vulnerable to anonymous remote code execution.

The program includes two verifier functions, verify and badverify. verify shows a correct implementation, while badverify shows a bad implementation. Both implementations are run when the user starts the program with more than 1 command line argument. badverify requires a Unix-like environment with OpenSSL in the PATH and the standard shell at /bin/sh. When this program is run in the following manner, a new directory will be created because of the command injection vulnerability (assuming that the user database contains a user with the provided username):

java -jar otpbug.jar 1aaf88620391e19b 'bob.tmp ; mkdir hello'

Mitigating factors for this vulnerability include restrictions on possible usernames, running the program in a chrooted environment, reducing the programs available in the environment from which the verifier is run, and reducing the privileges of the user running the verifier.

13

Conditions that may increase the risk include running the program as a privileged user and allowing arbitrary usernames.

This demonstrates a command injection vulnerability and failure to validate user input within security software. If arbitrary usernames are allowed (as intended in the demonstration), then the program would allow arbitrary command execution. Depending on how the username is processed, a program using the "correct" verifier might still be vulnerable to issues such as cross-site scripting.

Conclusion

Our project demonstrates what could go wrong in implementing a security system from scratch. We have shown that security software indeed must follow software security principles. Even though S/KEY[1] is regarded as highly secure, a poor implementation may be vulnerable to serious problems such as command injection through improper input validation. This project doesn't even consider the problem of deployment, although secure deployment is another very important aspect of secure software. If the way security software is deployed leaves it vulnerable to attack by malicious users, then its purpose has been defeated.

14

It is also worth noting that implementing security libraries and security software is a non-trivial task. Security software should be implemented by experienced developers and verified by security experts. A deep understanding of the protocol is often necessary to ensure that all the subtleties of each algorithm are reflected properly in the implementation.

Security protocols and libraries are developed over a long time by a large number of developers, which gives them an advantage over almost any attempt to recreate similar protocols and libraries. It is easier, more useful, and much more secure to simply take advantage of the resources available than it is to try it on your own. The possibility of developing something superior to the preexisting material is low, and it comes at a huge risk.

If more time were permitted in this project, the demonstration OTP verifier would be attached to a real database to allow for a real arbitrary code execution vulnerability. As the user database stands, it does not allow for this.

Group Member Biographies

Alex Wong is a senior Computer Science and Mathematics student at the University of South Carolina. Alex has worked on several large programming projects throughout his academic career and carries experience from his internship at Intel Corporation in the

15

summer of 2008. Alex currently works as an Undergraduate Research Assistant under the direction of Dr. Manton Matthews. As a research assistant, he has developed software to run on Nvidia's CUDA to produce association strengths between documents, and he has also developed software to run on large SMP machines to generate catalogs of graphs. Alex's interests include high performance computing, high availability services, compression, cryptography, security, and network protocols.

Curry Dulcie is from Fort Mill, South Carolina, and is currently in her senior year as a Computer Science major at the University of South Carolina. She has programming experience from her time as a student as well as her experience as a Supplemental Instructor for CSCE 145: Algorithmic Design I. She has also worked as a debugger in the lab portion of the same class.

16

References

1. E. Barkan, E. Biham, and N. Keller, “Instant ciphertext-only cryptanalysis of GSM encrypted communications,” in Proc. Int. Cryptology Conf. (CRYPTO) 2003, pp. 600–616. 2. Ya-Fen Chang , Chin-Chen Chang , Jui-Yi Kuo, A secure one-time password authentication scheme using smart cards without limiting login times, ACM SIGOPS Operating Systems Review, v.38 n.4, p.80-90, October 2004 3. V. Goyal, A. Abraham, S. Sanyal, and S.Y. Han, “The N/ R one time password system.” in Proceedings of International Conference on Information Technology: Coding and Computing (ITCC’ 05), 4-6 April, 2005, vol. 1, pp. 733-738, 2005. 4. N. Haller, The S/KEY One-Time Password System, RFC Editor, 1995 5. Markus Kuhn, OTPW – A one-time password login package, http://www.cl.cam.ac.uk/~mgk25/otpw.html, November, 2003. 6. PKCS #5 v2.1: Password-Based Cryptography Standard. RSA Laboratories, October 5, 2006 7. Aviel D. Rubin, Independent one-time passwords, Proceedings of the 5th conference on USENIX UNIX Security Symposium, p.15-15, June 05-07, 1995, Salt Lake City, Utah

[1]

Names and brands may be the properties of other parties. 17