|
Brought to you by:
Suppliers of:
|
|
|
| |
| HTTP session-id s take an important role in almost any web site today. This paper presents a cryptanalysis of Java Servlet 128-bit session-id s and an efficient practical prediction algorithm. Using this attack an adversary may impersonate a legitimate client. Through the analysis we also present a novel, general space-time tradeoff for secure pseudo random number generator attacks. |
| |
Credit:
The information has been provided by Zvi Gutterman.
The original article can be found at: Hold Your Sessions: an Attack on Java Servlet Session-id Generation
|
| |
Introduction:
At the root of many security protocols, one finds a secret seed which is supposedly generated at random. Unfortunately, truly random bits are hard to come by, and as a consequence, often security hinges on shaky, low entropy sources. In this paper, we reveal such a weakness in an important e-commerce building block, the Java Servlets engine.
Servlets generate a session-id token which consists of 128 hashed bits and must be unpredictable. Nevertheless, this paper demonstrates that this is not the case, and in fact it is feasible to hijack client sessions, using a few legitimately obtained session-id s and moderate computing resources.
Beyond the practical implication to the thousands [16] of servers using Servlets, this paper has an important role in describing an attack on a pseudorandom-number-generator (PRNG) based security algorithm and in demonstrating a nontrivial reverse engineering procedure. Both can be used beyond the Servlets attack described henceforth.
Web server communication with clients (browsers) often requires state. This enables a server to remember the client s already visited pages, language preferences, shopping basket and any other session or multi-session parameters. As HTTP [9] is stateless, these sites need a way to maintain state over a stateless protocol. Section 2 describes various alternatives for implementing state over HTTP. However, the common ground of all these schemes is a token traversing between the server and the client, the session-id.
The session-id is supported by all server-side frameworks, be it ASP, ASP.net, PHP, Delphi, Java or old CGI programming. Session-id s are essentially a random value, whose security hinges solely on the difficulty of predicting valid session id's. HTTP session hijacking is the act where an adversary is able to conduct a session with the web server and pretend to be the session originator. In most cases, the session-id s are the only means of recognizing a subscribing client returning to a site. Therefore, guessing the unique session-id of a client suffices to act on its behalf.
Driven by this single point of security, we set out to investigate the security of session-id s deployments, and as our first target, we have analyzed the generation of session-id s by Apache Tomcat. Apache [2] is an open-source software projects community. The Apache web server is the foundation s main project. According to Netcraft [16] web study of more than 48, 000, 000 web servers, the Apache web server is used by more than 67% of the servers and hence the most popular web server for almost a decade. At the time of this writing (April 2004), sites such as www.nationalcar.com, www.reuters.com, www.kodak.com and ieeexplore.ieee.org are using Java Servlets on their production web sites.
In many of these sites, the procedure for an actual credit-card purchase requires a secure TLS [8] sessions, separated from the "browsing and selection" session. However, this is not always the case. For example, Amazon's patented [10] one-click checkout option permits subscribing customers to perform a purchase transaction within their normal browsing session. In this case, the server uses a client s credit-card details already stored at the server, and debits it based solely on their session-id identification.
In either of these scenarios, an attacker that can guess a valid client id can easily hijack the client s session. At the very least, it can obtain client profile data such as personal preferences. In the case of a subscriber to a sensitive service such as Amazon's "one-click", it can order merchandise on behalf of a hijacked client. Briefly, our study of the generation of Java Servlets session-id s reveals the following procedure. A session-id is obtained by taking an MD5 hash over 128- bits generated using one of Java s pseudo-random number generators (PRNG).
Therefore, two attacks can be ruled out right away. First, a brute force search of valid session-id s on a space of 2128 is clearly infeasible. Second, various attacks on PRNGs, e.g., Boyar s [6] attack on linear congruential generators, fail because PRNG values are hidden from an observer by the MD5 hashing. Nevertheless, we are able to mount two concrete attacks. We first show a general space-time attack on any PRNG whose internal state is reasonably small, e.g., 264 280. Our attack is resilient to any further transformation of the PRNG values, such as the above MD5 hashing. Using this attack, we are able to guess session-id s of those Servlets that use the java. util .Random package, whose internal PRNG state is 64-bits. Beyond that, our generic PRNG attack is the
first to use space-time tradeoffs, and may be of independent interest. Our second attack is on the seed-generation algorithm of Java Servlets. Using intricate reverse engineering, we show a feasible bound for the seed s entropy. Consequently, we are able to guess valid session-id s even when Servlets are using the java. security .SecureRandom secure PRNG (whose internal state is 160 bits).
The paper is organized as follows. In Section 2 we describe the HTTP state mechanisms. In Section 3 we describe and analyze the Tomcat session-id generation algorithm. Java hashCode() study is presented in Section 4. In section 5 we present our attacks on the session-id. We conclude in Section 6.
|
|
|
|
|
