Session hijacking usually refers to the ability to take over a network conversation between the client and the server. For example, a login process to your personal internet banking account, it is called a session that is valid for 15 minutes. In order for a session hijack to be successful, it must involves a passive monitoring process, called sniffing. The attacker must monitor and capture the packets passing through a given network first, before actively trying to inject a packet or frame to act as one of the communicating hosts.
Session hijacking is very similar to spoofing, except there is no guessing involved as all the necessary information are available to the attacker
What does “session hijacking” involve?
The combination of “passive” and “active” actions refers to interception and injection. It allows an attacker to avoid password protections by taking over an existing connection once authentication is completed. This bypass the authentication process, allowing them to perform any action on that system.
An example from sciencedirect.com : For example, if I am sniffing your network, I might be aware that you have a Telnet session between your network management system on address 10.0.0.1 and your key system 10.0.0.100. If I send a series of packets to the NMS on 10.0.0.1 that causes you to drop the connection but at the same time continue to send packets to 10.0.0.100 with a spoofed address of 10.0.0.1, I have hijacked the session.
Why is “session hijacking” a successful cyber-attack option?
Weak session-ID generation algorithm/small session IDs: Most websites use linear algorithms to predict variables such as time or ip address for generating session IDs
Indefinite session-timeout: Session IDs with an indefinite expiration time allows an attacker with unlimited time to guess a valid session ID. The attacker uses static-session IDs ( similar to the “remember me” option ) to the user’s web account after capturing user’s cookie file.
Countermeasures do not work without encryption: Sniffing session ID is easy on a flat network if transport security is not set up/configured properly. During transmission of session ID cookies, the web application needs to use proper SSL encryption, but an attacker could bypass the encryption to capture the session IDs containing the actual logon information through sniffing.
Insecure handling of session IDs: An attacker can retrieve the stored session-ID information by misleading the user’s browser into visiting another site. Before the session expires, an attacker can exploit the information in many ways, such as DNS poisoning, Cross-site scripting (XSS) exploitation and etc.
Computers using the TCP/IP protocol are more vulnerable: All machines running TCP/IP are vulnerable to session hijacking because of the design flaws inherent in the TCP/IP protocol
No account lockout for invalid session IDs: If the website configuration does not implement account lockout, the attack will have unlimited tries to connect with varying session IDs embedded in a genuine URL. This is similar to the concept of a brute force attack.
Session Hijacking Process
1 – Tracking/Tracing the connection/Monitor
The attacker then finds an active session between the target and another machine and places himself between them. Using a sniffer like Wireshark, he captures the traffic and tries to gather information about the session. He then monitors the traffic for vulnerable protocols like HTTP, telnet, rlogin, etc., and tries to find any valid authentication packets passing through.
2 – Desynchronizing the connection
The attacker tries to predict the session id using available information. Now that a target has been chosen, the next step in the session hijacking process is sequence number prediction. Sequence number prediction is a critical step because failing to predict the correct sequence number will result in the server sending reset packets and terminating the connection attempt. If the attacker guesses the sequence numbers wrong repeatedly, the likelihood of detecting the attack increases.
In application-level hijacking, active attacks are pursued to steal the session Id. Man in the middle attack, cross-site scripting, sniffing are used to steal the session id.
Once a session is chosen and sequence numbers predicted, one of the targets has to be silenced. This is generally done with a denial of service attack. The attacker must ensure that the client computer remains offline for the duration of the attack, or the client computer will begin transmitting data on the network causing the workstation and the server to repeatedly attempt to synchronize their connections; resulting in a condition known as an ACK storm.
An attacker can also use a FIN flag, but this will make the server respond with an ACK thus giving away the attack through an ACK storm. This occurs because of a flaw in this method of hijacking a TCP connection. While receiving an unacceptable packet, the host acknowledges it by sending the expected sequence number. This packet generates an acknowledgment packet, creating an endless loop for every data packet, causing a mismatch in SEQ/ACK numbers in excess network traffic with both server and the target trying to verify the right sequence. Since these are zombie packets (packets that do not carry data), re-transmission does not occur if the packet is lost. Since TCP uses IP, the loss of a single packet puts an end to the unwanted conversation between the server and the target.
3 – Injecting the attacker’s packet
The final phase of the session hijack attack entails taking over the communication session between the workstation and server. The attacker will spoof their client IP address, to avoid detection, and include a sequence number that was predicted earlier. If the server accepts this information, the attacker has successfully attacked the communication session.
Countermeasures
In general, session hijacking is very dangerous. The victim is at risk of identity theft, fraud and loss of sensitive information. All the networks using TCP/IP are vulnerable to the types of session hijacking discussed earlier. However, following best practices might protect against session hijacking attacks.
So what are the best practices?
Use Secure Shell to create a secure communication channel.
Pass the authentication cookies over HTTPS connection.
Implement the log-out functionality for user to end the session.
Generate the session ID after successful login and accept session IDs generated by server only.
Ensure data in transit is encrypted and implement defense-in-depth mechanism.
Use string or long random number as a session key.
Use different user name and passwords for different accounts.
Educate the employees and minimize remote access.
Implement timeout () to destroy the session when expired.
Avoid including the session ID in the URL or query string.
Use switches rather than hubs and limit incoming connections.
Ensure client-side and server-side protection software are in active state and up to date.
Use strong authentication or peer-to-peer VPN’s
Use encrypted protocols that are available at OpenSSH suite.
Use firewall and browser settings to confine cookies.
Protect authentication cookies with SSL.
Regularly update platform patches to fix TCP/IP vulnerabilities (Patch management)
use IPsec to encrypt session information
There are many more countermeasures to protect against session hijacking. However, these are just methods to reduce the risks of getting hijacked. There is no “correct” way to prevent yourself from getting hijacked.
Three important approaches to prevent Session Hijacking
HTTP Strict Transport Security ( HSTS )
This is a web security policy that protects HTTPS websites against man-in-the-middle attacks. HSTS policy helps web servers to enforce web browsers to interact with it using secure HTTPS protocol. All insecure HTTP connections are automatically converted into HTTPS connections. Ensuring that all communication between the wbe server and browser is encrypted and all responses are delivered and received from an authenticated server.
Token Binding
When a user logs on to a web application, it generates a cookie with a session identifier. This is called a token. Token binding protects client server communication against session hijacking attacks. The client creates a public-private key pair for every connection to a remote server. When the client connects to the server, it generates a signature using the private key, and sends the signature along with its public key to the server. You may argue that if the attacker obtains the signature, he will be able to regenerate or reuse it for another connection. However, it is not possible as for every new connection, a new pair of public and private keys are used.
HTTP Public Key Pinning ( HPKP )
This is a trust-on-first-use technique used in an HTTP header that allows a web client to associate a specific public key certificate with a particular server to minimize the risk of MITM attacks with fraudulent certificates.
Conclusion
Session Hijacking is a popular cyber-attack and we do not have a “100% defense” against such attacks. Why? This is due to the fact that attackers are innovating new and more sophisticated attack patterns everyday. If we can refer to an analogy, there is no individual who can win in any form of competition ( Formula One races, Chess and etc ) for 20 years straight. Strategies are evolving in a very fast pace and we have to adapt to such environment effectively.
You can read more about Session Hijacking examples at : https://owasp.org/www-community/attacks/Session_hijacking_attack