Session hijacking: A method of taking over a user session

Session hijacking:

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. Session hijacking works by taking advantage of the fact that most communications are protected with authentication procedures (by providing credentials) at session setup, but not thereafter. These attacks generally fall into three categories: Man-in-the-middle (MITM), Blind Hijack, and Session Theft.
In MITM attacks, an attacker intercepts all communications between two hosts. With communications between a client and server now flowing through the attacker, he or she is free to modify their content.
In blind hijacking, an attacker injects data such as malicious commands into intercepted communications between two hosts commands like "net.exe localgroup administrators /add EvilUser". This is called blind hijacking because the attacker can only inject data into the communications stream; he or she cannot see the response to that data (such as "The command completed successfully.") Essentially, the blind hijack attacker is shooting data in the dark, but as you will see shortly, this method of hijacking is still very effective.
In a session theft attack, the attacker neither intercepts nor injects data into existing communications between two hosts. Instead, the attacker creates new sessions or uses old ones. This type of session hijacking is most common at the application level, especially Web applications. The session ID is normally stored within a cookie or URL for web applications, so the attacker use other techniques like cross site scripting to capture or steal these cookies to hijack a current active session. The intrusion may or may not be detectable, depending on the user's level of technical knowledge and the nature of the attack. If a Web site does not respond in the normal or expected way to user input or stops responding altogether for an unknown reason, session hijacking is a possible cause.
Session hijacking at the network level is especially attractive to attackers. They do not need host access, as they do with host-level session hijacking. Nor do they need to customize attacks on a per-application basis, as they do at the application level. Network-level session hijacking attacks allow attackers to remotely take over sessions, usually undetected. But successfully hijacking a session at the network level requires more skills and attacker needs to cross many obstacles.

Hijacking a TCP Session:

One of the key features of TCP is reliability and ordered delivery of packets. To accomplish this, TCP use acknowledgment (ACK) packets and sequence numbers. Manipulating these is the basis for TCP session hijacking. To understand the TCP session, we need to focus on what happens when a client establish a connection with the server. Every TCP session initiation starts with a three way handshake. For example, the client first initiates a session with the server by sending a synchronization (SYN) packet to the server with initial sequence number x. The server responds with a SYN/ACK packet that contains the server's own sequence number p and an ACK number for the client's original SYN packet. This ACK number indicates the next sequence number the server expects from the client, this is x+1 (x plus client's original SYN packet size in bytes, normally is one when establishing a session). The client acknowledges receipt of the SYN/ACK packet by sending back to the server an ACK packet with the next sequence number it expects from the server, which in this case is p+1 (the server's initial SYN packet sequence number plus one). The client and server are ready to start exchanging data.

Client	------- SYN, Sequence no x ---------------------->	Server
Client	<----- SYN/ACK, Sequence no p -----------------	Server
	<----- Acknowledgement no x + 1 -------------
Client	----- ACK, Acknowledgement no p + 1 ------->	Server

Once the TCP session is established, then the client starts sending data to the server with the sequence number x + 1. The server acknowledges this packet by sending back to the client an ACK packet with number x + n (n is size of the data sent in bytes) as the next sequence number expected by the server. If the attacker wanted to inject data into the TCP session as the client, he or she would need to: Spoof the client's IP address, determine the correct sequence number that is expected by the server from the client, and inject data into the session before the client sends its next packet. The first and second tasks are easily accomplished, but the third is a bit difficult and not impossible.
Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except that UDP attackers do not have to worry about the overhead of managing sequence numbers and other TCP mechanisms. Since UDP is connectionless, injecting data into a session without being detected is extremely easy.

Web based Session Hijacking:

In web based/application based session hijacking, it is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user's Web application session while that session is still in progress. 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 request 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. For this purpose a session ID is used and shared between the client/user and server, 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.
There are several problems with session IDs. 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. In most applications, after successfully hijacking a session, the attacker gains complete access to all of the user's data, and is permitted to perform operations instead of the user whose session was hijacked. Session IDs can be stolen using a variety of techniques like sniffing network traffic, using Trojans on client PCs, using the HTTP referrer header where the ID is stored in the query string parameters, and using Cross-Site Scripting attacks.

Countermeasures:

Use of strong and random session IDs: Use strong and random session IDs to prevent brute force and guessing techniques.
Limit the session time: Kill the session after few minutes of idle time.
Mutual Authentication: Client certificates can be a strong mitigation against Man in the Middle attacks and session hijacking.
Secured Socket Layer: Using SSL for all communication can mitigate the session hijacking. But, SSL alone does not do the trick to protect session hijacking. You need to have session tokens as part of POST data.
HTTPOnlyFlag: It is a good mitigation to prevent client code accessing cookie even if is not strong mitigation (can be bypassed). You might want to add /secure parameter to prevent them traveling in non SSL channels.
Changing session token: Regenerating cookie information often, or on each request, you should generate it at each POST data request when this data is sensitive.
Regenerating session ID: Upon successful log in a fresh token/ID should be created to mitigate session fixation type attacks.
Use IPSec to prevent TCP based session hijacking: Internet Protocol Security has the ability to encrypt your IP packets based on a Pre-Shared Key or with more complex systems like a Public Key Infrastructure ‘PKI’. This will also defend against many other attack vectors such as sniffing. The attacker may be able to passively monitor your connection, but they will not be able to read any data as it is all encrypted. Remember that, there are IPSEC cracking tools available on the internet that will attempt to guess the PSK and decrypt packets.
Finally, ensure that your application is safe from injection attacks like cross site scripting, reduce the attack surface area of your application and network and follow defense in depth rule.

References:

http://technet.microsoft.com/hi-in/magazine/2005.01.sessionhijacking(en-us).aspx
http://www.securitydocs.com/library/3479
http://seclists.org/webappsec/2009/q1/0078.html