TAZ Forum Community

A Quick Introduction to TCP Session Hijacking

The concept of TCP session hijacking has been around for roughly 20 years now, and a multitude of papers have been written on the subject. Unfortunately, I have not seen one that accurately draws a distinction between the different types of attacks. I make an attempt to distinguish hijacking attacks in this paper, classifying them by the person who either published them or made them possible for the community as a whole. Some variations for each different attack will be discussed, and the benefits and drawbacks of each attack, and its variations, will be discussed. Hopefully this paper will leave you with a better understanding of TCP session hijacking then you have now.

Morris Attack

This is the original form of TCP session hijacking, originally proven in a 1985 paper written by Robert T. Morris in a paper entitled "A Weakness in the 4.2BSD Unix€ TCP/IP Software". This paper outlined the method by which initial sequence numbers in a TCP connection can be accurately predicted. By predicting the initial sequence number, Morris was able to spoof the identity of a trusted client to a server, without requiring any communication from the server. Since 1985, initial sequence numbers have become much harder to predict, although it still possible on most modern operating systems with some effort. For a discussion on the prediction of initial sequence numbers on modern operating systems, see "Strange Attractors and TCP/IP Sequence Number Analysis", listed at the bottom.

Upon receiving a packet with the SYN bit set, a server will respond with a SYN,ACK packet. The header of this packet will contain the sequence number which is intended to be used by the client to reconstitute the data sent over the stream in the correct order. The client, upon correctly receiving all the data within an established window, will acknowledge this data by sending a TCP acknowledgment packet (ACK bit set and no data), with the acknowledgment field set to the sequence number of the last correctly received byte of data, plus one; this will be the sequence number of the next expected byte.

In the Morris attack, we first bring the client offline, or cause it to become otherwise unresponsive; it is then unable to respond to the SYN,ACK packet sent by the server. If the client is not brought offline first, it will respond to the unexpected SYN,ACK packet with a RST packet, aborting our connection attempt. We then initiate a TCP connection to the server, posing as the client. We accomplish this by spoofing the source address on our outgoing TCP packets to be that of the client. Since we cannot receive the reply to this SYN packet, and therefore cannot learn the initial sequence number chosen by the server, we must already be aware of it, as if we do not acknowledge the SYN,ACK packet with the correct acknowledgment number, a connection cannot be established. It is the ability to predict the sequence number chosen by the server that this attack relies upon. After a certain delay (in the order of a few milliseconds), we send an ACK packet back to the server, as if we had received and read the SYN,ACK packet it sent the client. The acknowledgment field of this packet will contain the sequence number we already know the server will choose, plus one. The server now believes it is communicating with the client.

This attack isn't really session hijacking at all, since there is no session to hijack in the first place. However, it is often discussed when describing hijacking attacks, and is generally thought of to be in the same category. This is the attack used by Kevin Mitnick in 1995. Ten years after the vulnerability was made public, network stacks were still vulnerable to accurate initial sequence number prediction.

Variations

We can make this attack significantly easier if we can somehow cause the traffic between client and server to pass through us. This can be done by either situating ourselves logically between them, or if the server supports source routing, we can cause its reply packets to go through us first. We can also use ICMP redirect packets to advertise ourselves as the gateway by which to reach the other victim. By seeing the return traffic from the server to the client, we relieve ourselves of the both need to predict the initial sequence number and of the need to take the client offline, as we can simply not forward the traffic.

If this is a local attack, and we are in the same broadcast domain as the client and the server, we can spoof MAC addresses in such a manner as to cause the communications to pass through us at the data link layer. MAC address spoofing could also be used to ensure the client and server cannot communicate. Simply tell each of them that the other is at a nonexistent address.

Joncheray Attack

This attack was originally published in 1995 by Laurent Joncheray, in a paper titled "Simple Active Attack Against TCP". Since then it has been known simply as the Simple Active Hijack attack. It is designed to circumvent authentication mechanisms which take place during the beginning of a session, by creating a desynchronized state between client and server, and rewriting packets between them.

Assuming we are on the same local segment as both the client and the server, we begin the attack by waiting for a connection to open between client and server. We allow the connection to open normally, however, once the connection has been opened, we begin our attack. We send a packet to the server, posing as the client, resetting the connection. Once the connection has been reset, and therefore closed, we open a new connection with the same parameters as the first one. By doing this, we are desynchronizing the sequence numbers that client and server have chosen to use, rendering them unable to directly communicate using this stream. We listen for communication between these two hosts, and rewrite packets as necessary to trick them into believing they are communicating with each other. This will allow us to wait for credentials to be exchanged before delivering the attack payload. Once these credentials have been exchanged, and the server therefore trusts the client, we can inject data into the stream as desired to carry out the attack.

This attack has the benefit of not requiring us to take the client offline first. Indeed, we need the client's communication data to make the attack work. It also has the problem of what is known as an "ACK storm", which can easily give the attack away. This storm is caused by the server acknowledging the data that we send to it. The server will send its acknowledgment packets to the client. The client, upon receiving these packets, will notice that the acknowledgment number is incorrect, and send an ACK packet back with the correct sequence number in an attempt to re-establish a synchronized state. This response is itself invalid, as the sequence number it contains was never sent by it. Hence, another ACK packet is returned. This loop continues indefinitely, until one of the ACK packets is lost in transit. A single character injected into a telnet session can create hundreds of ACK packets in the resulting storm.

This attack is also known as a man-in-the-middle attack, and can be used to trick users into allowing us to bypass encryption methods employed at higher levels. If we can send the client and server our own encryption keys, we simply need to decrypt the traffic with one key, and re-encrypt it with the other. Although it is quite technically easy to detect an attack like this, most applications will offer the user the choice of continuing despite the suspected attack. Users who ignore this warning are susceptible to this attack, despite the encryption employed.

Variations

To prevent the resulting ACK storm, if we are on the same local segment as the client and server, we can poison their ARP caches so the ACK packets in the storm will be sent to an invalid hardware address. Once the session has been established and credentials exchanged, we poison the caches by sending unsolicited ARP replies to both hosts with bogus addresses. These hosts will now not receive the packets responsible for the storm.

If we are not on the same segment, the attack becomes much more difficult. We must find a way to force both the client and the server's traffic to pass through us. This can be done with source routing, however, as most routers have this capability disabled. We could also place ourselves on the path between client and server. If we are between client and server, we can also filter out the packets responsible for the ACK storm. We can also modify routing tables on intermediate routers with ICMP redirect packets.

It is also possible to simply take the client offline with some other attack. Once the session has been established, we really have no more need for the client. If we are not concerned about discovery by disabling the client, this becomes a viable option. It would also prevent the ACK storm.

Krauz Attack

This attack is named after the author of Hunt, a tool used for session hijacking. In this attack, we simply watch communications between hosts and inject data as necessary, forging the source address on our packets to appear as the client to the server. It has the benefit of not creating a desynchronized state, so we can therefore return the session back to the client and gracefully make our escape if need be. Some trickery must be employed to make this happen on the client side, but it is possible. It is designed to be executed on a segment local to both the client and the server. Unfortunately, this attack cannot be used to bypass encryption schemes used with applications such as SSH, as the session keys are encrypted before being delivered, and we are not altering traffic - rather, we are simply injecting it. This is what makes the attack so effective - we do nothing until we actually inject our data, so neither client nor server has any warning of the impending attack.

Variations

It is entirely possible to execute this attack if we are not local to client or server, if we can force their traffic to be routed through us. This also is usually done either with source routing, routing table modification, or by taking control of a host between them. MAC spoofing and ARP cache poisoning also come in quite handy, as these can be used to prevent the ACK storm this attack is subject to. All these methods, however, could warn the victims of the attack, which nullifies one of the major benefits of this attack - surprise. If we have no desire to return the session back to the client, we can also take the client offline by some means, preventing the ACK storm but warning the client of the attack.



Conclusions

TCP session hijacking is still a very real threat, despite advances made in both initial sequence number generation and network design. To defend against these attacks, we can take several steps. We should disable source routing on host machines, as this would disable a major channel by which attackers can place themselves between victims. Using switched environments, as well as static port-to-MAC-address assignments, can go a long way to preventing ARP spoofing and cache poisoning attacks. These are three of the major weaknesses in TCP that make hijacking attacks possible. ICMP redirects should be either disabled or filtered, or we need to take steps to ensure that no communications are established to a host for which a redirect is active.

Layer 3 encryption is also a major deterrent to these attacks, also known as IPsec. This encrypts the data needed by the attacker to pull off every one of these attacks. It is generally the best method by which to defend against hijacking attacks. Passive detection can also be used, by watching for associated ACK storms, or any of the techniques discussed here to set up a hijacking attack. Hijacking attacks are far too simple if steps are not taken to reduce their likelihood.

This tutorial is licensed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivs 2.5 license