Session hijacking, also known as TCP session hijacking, is a method of taking over a web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user's session ID has been accessed, the attacker can masquerade as that user and do anything the user is authorized to do on the network.
One of the most valuable byproducts of this type of attack is the ability to gain access to a server without having to authenticate to it. Once the attacker hijacks a session, they no longer have to worry about authenticating to the server as long as the communication session remains active. The attacker enjoys the same server access as the compromised user because the user has already authenticated to the server prior to the attack.
HTTP is stateless, so application designers had to develop a way to track the state between multiple connections from the same user, instead of requesting the user to authenticate upon each click in a web application. A session is a series of interactions between two communication end points that occurs during the span of a single connection. When a user logs into an application, a session is created on the server in order to maintain the state for other requests originating from the same user.
Applications use sessions to store parameters that are relevant to the user. The session is kept "alive" on the server as long as the user is logged on to the system. The session is destroyed when the user logs-out from the system or after a predefined period of inactivity. When the session is destroyed, the user's data should also be deleted from the allocated memory space.
A session ID is an identification string (usually a long, random, alpha-numeric string) that is transmitted between the client and the server. Session IDs are commonly stored in cookies, URLs and hidden fields of web pages.
Besides the useful functionality of session IDs, there are several security problems associated with them. Many of the popular websites use algorithms based on easily predictable variables, such as time or IP address, in order to generate the Session IDs, causing their session IDs to be predictable. If encryption is not used (typically SSL), Session IDs are transmitted in the clear and are susceptible to eavesdropping.
The most popular culprits for carrying out a session hijacking are session sniffing, predictable session token ID, man in the browser, cross-site scripting, session sidejacking, session fixation.
The session hijack attack is very stealthy. Session hijack attacks are usually waged against busy networks with a high number of active communication sessions. The high network utilization not only provides the attacker with a large number of sessions to exploit, but it can also provide the attacker with a shroud of protection due to a large number of active sessions on the server.
When cybercriminals have hijacked a session, they can do virtually anything that the legitimate user was authorized to do during the active session. The most severe examples include transferring money from the user’s bank account, buying merchandise from web stores, accessing personally identifiable information (PII) for identity theft, and even stealing data from company systems.
In September 2012, security researchers Thai Duong and Juliano Rizzo announced CRIME, an attack takes advantage of an information leak in the compression ratio of TLS requests as a side channel to enable them to decrypt the requests made by the client to the server. This, in turn, allows them to grab the user’s login cookie and then hijack the user’s session and impersonate her on high-value destinations such as banks or e-commerce sites.
The demonstration showed how an attacker might execute this attack to recover the headers of an HTTP request. Since HTTP headers contain cookies, and cookies are the primary vehicle for web application authentication (after login), this presents a significant attack.
CRIME decrypts HTTPS cookies set by websites to remember authenticated users by means of brute force. The attack code forces the victim's browser to send specially crafted HTTPS requests to a targeted website and analyzes the variation in their length after they've been compressed in order to determine the value of the victim's session cookie. This is possible because SSL/TLS uses a compression algorithm called DEFLATE, which eliminates duplicate strings, as we saw above.
The attack code can't read the session cookie included in the requests because of security mechanisms in the browser. However, it can control the path of every new request and can insert different strings into it in an attempt to match the value of the cookie.
Session cookie values can be quite long and are made up of uppercase letters, lowercase letters and digits. As a result, the CRIME attack code has to initiate a very large number of requests in order to decrypt them, which can take several minutes. However, the researchers have developed some algorithms that make the attack more efficient.
It is important to remember that it is possible for an attacker to steal and reuse session identifiers or other sensitive cookie values when they're stored or transmitted insecurely. While providing 100% protection can be difficult, encryption is the main defense. When a user authenticates, SSL and a secure cookie should be mandatory. When authenticated users visit one or more secure pages, they should continue to be forced to use HTTPS.
Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) can also be very useful in defending your network from session hijack attacks. While implementing these devices can be difficult, the benefits far outweigh the steep implementation costs. IDS/IPS systems look at the data that enters the network and compares it to an internal database of known attack signatures. If the packet is matched against an entry in the IDS/IPS database, the IDS will generate an alert, and the IPS will block the traffic from entering the database.