A
QUICK INTRODUCTION TO TCP SESSION HIJACKING
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
Original Tutorial
Submitted by Striek for TheTAZZone-TAZForum
Originally posted on June 11th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.