Session Hijacking

Contents

Description

Session hijacking is when an attacker takes over a TCP session between two machines, quite often in midstream, and usually for the purposes of either stealing information or disrupting or inhibiting the flow of information.
Because authentication only occurs at the start of TCP session, an attacker can use captured, brute –force, or a reverse-engineered session ID to seize control of a legitimate user’s Web application session while the session is still in progress.
A session ID is an identification string (usually a long, random, alphanumeric 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 popular Web sites use algorithms based on easily predictable variables, such as time or IP address to generate the session IDs, causing them to be predictable. If encryption is not used (typically, SSL), session IDs are transmitted in the clear and are susceptible to eavesdropping.
Session hijacking involves an attacker using brute force captured or reverse-engineered session IDs to seize control of a legitimate user's session while that session is still in progress. 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 also be stolen using script injections, such as cross site scripting. The user executes a malicious script that redirects the private user's information to the attacker.

In blind hijacking, the attacker injects such data as malicious commands into intercepted communications between two hosts commands such as “net.exe localgroup administrators /add EvilAttacker.
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).
In a session theft attack, the attacker neither intercepts nor injects data into existing communication between two hosts.
The attacker creates new sessions or uses old ones.
This type of session hijacking is most common at the application level, especially Web applications.
Session hijacking at the network level is especially attractive to attackers. They don't 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.
Successfully hijacking a session at the network level requires an attacker to overcome various obstacles.

In 2001, a vulnerability was reported in Sun's NetDynamics application server platform, where a user who authenticates with NetDynamics receives a session id and a random unique identifier.
This session id and identifier remain active for up to 15 s after the user logs in, and a subsequent user can make use of those credentials to hijack the logged-in account.

Most testing of session-hijacking vulnerabilities is begun by looking carefully at all protocols in use your system and determine what information they exchange and how. In the clear? How is the remote server identified? Is authentication done only at the start of a session?
If your system authenticates your user only at start of a session, and after which the system on the other side of the connection is trusted, Your system is most likely vulnerable to a session-hijacking attack.
Once you have a good idea of what your system does, you can use one of the session-hijacking and man-in-the-middle (MITM) tools available. to see if you can demonstrate the vulnerability. A good tool to try is Ettercap (http://ettercap.sourcefoixe.neta