Non blind IP Spoofing and Session Hijacking: A Diary From the Garden of Good and Evil

Authors: Eric Hines [loki@fatelabs.com]

Jamie Gamble [bit@fatelabs.com]
Date: February 25, 2002

Introduction

This paper makes no assumptions of prior knowledge in TCP session hijacking or blind and non-
blind IP spoofing. We will cover all basics and provide both a novice and advanced introduction
to these topics. Although there are countless papers and books on the subject of TCP/IP, I always
believe that there exists a much less intricate definition that can be provided by other people. We
aim to provide our definition in an effort to hopefully clearly articulate this often convoluted
labyrinth of networking.

First off, what exactly is TCP Hijacking? The meticulous craft of TCP hijacking is simple. The
exploit relies on the violation of trust relationships between 2 communicating hosts. An attacker
can grab unencrypted traffic from a victim’s network-based TCP application, further tampering
with the authenticity and integrity of the data before forwarding it on to the unsuspecting target.

The first phase of solving this labyrinth is to understand the TCP/IP protocol suite. When two
computers on the Internet wish to establish a session with each other, a much more intricate
processes take place other than loading Netscape and hitting [go]. Communication over the
Internet is conducted through packets, a process involving multiple layers. Packets first traverse
down the stack of the sending host, than reverse up the stack at the remote. Each layer in the stack
wraps the packet on the sending side and than unwraps it at each layer on the receiving. This
stack, also known as the TCP/IP Internet model consists of four layers (not to be confused with all
7 layers of the OSI standards model). Each layer of the stack adds its own proprietary "tag" to
each segment of the packet. I have documented the communication processes between stacks in
the below diagram.
1. Application Layer
The application layer is the topmost layer (the request for a Web page in the preceding
example). In this example, the Application layer would be the web browser, Netscape; a
graphical interface to browsing the web.

2. Transport Layer
Below the application layer lays the Transport layer. This layer controls many of the
aspects in management and initiation of communication between two hosts. TCP operates
at the Transport layer ensuring reliability of data transported over inherently unreliable
communication platforms. This layer is responsible for appending the TCP header to the
datagram.

3. Network Layer
Below the Transport Layer is the network layer. Routers providing service at this layer
offer functionality for the journey of data from its source to destination host, one hop at a
time. This layer is responsible for appending the IP header of to the TCP header of the
packet.

4. Link Layer
This layer is primarily responsible for the transport of data from a host to the physical
medium over which it resides. It is responsible for the delivery of signals from source to
destination host over a physical communication platform, which in this case is Ethernet.
This layer appends the frame header to the IP header of the datagram.
The encapsulation of a packet is very simple. Each layer as mentioned previously attaches its own
header to each layer of the packet, in effect ultimately creating a multilayered frame, or packet
that is sent over the wire.

Diagram 1b places the individual technologies in its respective layer in the stack.

Dissecting the (3) Three Way Handshake

When (2) hosts are connected to the same network and host A wishes to communicate with host
B, host A sends out what is referred to as an ARP (Address Resolution Protocol) broadcast. In
order for packets to be routed across the network, host A must know what the MAC Address is of
the destination machine (B). Destination host B responds with it’s MAC address to the ARP
request. After host A receives the destination MAC address of the machine it wishes to
communicate with, it than proceeds to initiate a (3) way handshake with the remote machine. This
can be demonstrated in the below packets.

Host A
O:50:4:ad:5e:63 ff:ff:ff:ff:ff:ff 0806 60: arp who-has
10.0.0.146 tell 10.0.0.154

Host B
0:20:af:68:a:88 0:50:4:ad:5e:63 0806 60: arp reply
10.0.0.146 is-at 0:20:af:68:a:88
Host A
0:50:4:ad:5e:63 0:20:af:68:a:88 0800 60: 10.0.0.154.1103 >
10.0.0.146.23: S 489567416:489567416(0) win 32120

A three way handshake is the first step before two hosts wish to establish communication. The
process is as followed:

Host A: SYN
Host B: SYN + ACK
Host A: ACK

So now that you understand what a packet is, how it's created, and have a pretty good
understanding of the TCP/IP stack, lets move on to the design flaws in IPv4 that allows our attack
to take place.

Background on IPv4

IPv4 allows for trivial replay attacks, session hijacking, and several other man-in-the-middle
(MITM) attacks caused by sniffing packets off the wire. The original IPv4 standard provides
problems in (3) three areas:

1. Authentication
2. Integrity
3. Privacy

Definitions

1. IP spoofing - IP spoofing involves forging one's source IP address. It is the act of using one
machine to impersonate another. Many applications and tools in UNIX systems rely on source IP
address authentication.

2. ARP spoofing - ARP spoofing involves forging the packet’s source hardware address (MAC
address) to the address of the host you are pretending to be.

3. Simple Active Attack against TCP connections - An attack in which the attacker does not merely
eavesdrop but takes action to change, delete, reroute, add, forge or divert data. Perhaps the best-
known active attack is Man-In-the-Middle.
History of the Morris Worm
In 1988, the ARPANET had its first automated network security incident, usually referred to as
"the Morris worm" (4). A student at Cornell University (Ithaca, NY), Robert T. Morris, wrote a
program that would connect to another computer, find and use one of several vulnerabilities to
copy itself to that second computer, and begin to run the copy of itself at the new location. Both
the original code and the copy would then repeat these actions in an infinite loop to other
computers on the ARPANET. This "self-replicating automated network attack tool" caused a
geometric explosion of copies to be started at computers all around the ARPANET. The worm
used so many system resources that the attacked computers could no longer function. As a result,
10% of the U.S. computers connected to the ARPANET effectively stopped at about the same
time.

Blind Versus Non-Blind IP Spoofing

Blind IP spoofing has been around for quite some time. Robert T. Morris (Author of the
notorious Morris Worm) originally noticed that the security of a TCP/IP connection rested in the
Sequence numbers and that it was possible to predict them. Blind IP spoofing is defined here as
predicting the sequence numbers which will be sent to an unsuspecting host in order to create a
connection which appears to originate from the said host. Blind IP spoofing relies on the attacker
to predict sequence numbers because he is unable to sniff the communication between the (2) two
hosts. The attacker is not on the same network segment and is injecting herself into the
communication by predicting what sequence number the remote host is expecting from the
victim. This is used extensively to exploit the trust relationships between users and remote
machines, these services include r-services, NFS, telnet, IRC, etc.

Non blind TCP/IP spoofing can have the same effect as blind IP spoofing, but can be used for a
number of different purposes. We define non blind spoofing in this paper to be impersonating a
connection from another machine, but not using prediction to find the sequence numbers. This
method is used when the attacker is typically on the same network segment as the victim host,
allowing her to sniff the packets between the 2 hosts making the NSN (next sequence number)
available to the attacker.

Blind IP Spoofing

IP spoofing is relatively easy to accomplish. All one has to do is have root access on a machine
which will let him create RAW packets. Crafting IP and UDP packets is rather simple, as is
creating individual TCP packets. In order to establish a TCP connection (spoofed), you must
know what sequence numbers are being used. Blind IP spoofing forces the attacker to have to
predict the NSN.

The attack became famous when Kevin Mitnick used it to hack into Tsutomu Shimomura's
computer network. The attack he used exploited the trust that Shimomura's machines had with
another network. By SYN flooding the trusted host, Mitnick was able to establish a short
connection which was then used to gain access through traditional methods.
Besides being used to compromise machines, IP spoofing has been used extensively in DoS
attacks. The most famous of these (which we will also talk about later), is SYN flooding. The
majority of the DoS attacks that use spoofed IP's do not use TCP connections, or even TCP (SYN
flooding being an exception), so they are relatively easy to implement.

Non Blind TCP/IP Spoofing

1. Target - Host we want to talk with

2. Victim - Host we want to impersonate
3. Attacker - Our machine

Non blind TCP/IP spoofing is spoofing a connection from the Victim to Target by a third party,
Attacker. In order to do this we have to make the assumption that we can find the sequence
numbers being passed from Target to Victim without predicting them, and also that we can
prevent Victim from sending an RST (connection reset) packet to Target.
The most important part of this attack is to be able to find the sequence numbers sent from Target
to Victim. We will assume that Attacker and Victim are on the same network, allowing us to sniff
the packets sent from Target. Later we will talk about using another machine to do this, and other
techniques besides network sniffing. While Attacker and Victim are assumed to be on the same
LAN, Target can be anywhere in the world, it really doesn’t matter. Later we will see that if
Target is further away from Victim, it is to our advantage.

The first stage of this attack is to prevent Victim from sending RST packets to host Target once
we start our attack. This will be discussed later in the paper, so for the interim we will just
assume that we have already done that.

Next we must initiate the 3-way handshake between Attacker (Victim) and Target. So, a spoofed
TCP packet with the SYN flag set is sent to Target, who responds to Victim with a SYN and an
ACK. At this point we must sniff the traffic off of the wire to find what sequence number Target
will expect to be replied with, and then craft an ACK packet using that information.

After the connection is established, the process of spoofing packets, sniffing them off the wire,
and then crafting replies continues until we terminate the connection. All of the while, Target
will think that she is talking to Victim, and Victim will not know anything about what is
happening unless the admin on that machine is able to spot the odd traffic traveling to and from
this machine.

Blocking the RST's

The major task we are faced with is that Target will discover that it is not in fact talking to Victim.
Typically when a computer receives a TCP packet which it did not request (other than a SYN
trying to open a connection), a RST packet is sent back, which terminates the connection. Since
we want to establish a connection with Target, the last thing that we need is for Victim to ruin our
fun by sending the RST packet to Target. This brings about the question of prevention.

SYN Flooding

This was originally accomplished in blind IP spoofing attacks by SYN flooding Victim, so that it
would not be able to process the packets sent to it from Target. While this technique will work,
we have to be careful not to flood the network causing our network sniffer to drop packets on the
Attacker machine. Also, if we put a lot of stress on the network we will be slowing down the
overall speed of our connection between Attacker (Victim) and Target. It would be possible to
SYN flood Victim incrementally, which would prevent Victim from responding to Target,
allowing us to pick up the required packets between Target and Victim easier.

The problem with this technique is that the port which Target is sending the packet to Victim on
must be open. If it is not open, we cannot create the SYN flood. The work around for this would
be to use a specific source port in the connection, which is known to be open on Victim. This
would work, but it would be suspicious to see a connection to port 23 from port 137, or port 80.
Also, the person administrating the Victim could easily notice the DoS attack against him. Since
this method uses a denial of service attack, and it requires us to craft packets with unusual source
to destination ports, I wouldn't advise using it unless you just want a short term impersonation,
and do not want to make it a regular occurrence.

MITM

If we can have Victim forward its packets though Attacker, we would be able to filter out the
RST's and wouldn't have to worry about sniffing the network. We can do this a number of ways,
one such avenue is by using ARP poisoning, ICMP redirects, ICMP router advertisements, or by
faking the MAC of the victim. Once we have Victim sending its traffic through us, we can easily
filter out whatever we want. In order to do this, we would have to setup IP forwarding on our
machine, which should not be too much of a problem if we are living in the UNIX world.

Another trick is to have the upstream route Victim’s traffic through us. Doing this would in
theory attract a lot more attention to us then we would typically want.

Firewall

In a perfect world, we would have control over a firewall between Target and Victim which
would let us block RST packets from Victim to Target. Having this occur in the wild is not very
likely, but it can happen.

Remote implementation

So far we have assumed that the host we are impersonating and the machine under our control is
on the same network. This is assumed by saying that we can sniff or intercept the traffic of the
impersonated host. The attack becomes much more dangerous once we realize that the machine
we are coming from does not have to be on the local LAN as the impersonated host, but possibly
half way across the would. There are a number of ways which this can be accomplished, several
of which are discussed below.

As we have seen numerous times in the past with applications such as Back Orifice, Netbus, and
with many DDoS clients, it is not very hard to compromise remote machines and have them do
our bidding. In this case, we would be using a remote host which is on the same LAN as the
impersonated host to disable any attempts by our unsuspecting victim to send RST packets to the
machine we want to talk with, gather the data necessary for the attack (ie: Sequence numbers),
and transmit this information back to us. This will create a 4'th player in our attack, and would
slow our impersonated connection down, but it has its advantages. By making use of a 4th
machine, we can make it more difficult for the phoney connection to be traced back to us. There
are a number of methods which we could employ which would hide our machines IP from the 4th
host, such as having the information we need being passed onto an IRC server.
With the introduction of raw sockets in Windows XP, this method has the potential of becoming a
lot more popular.

Besides hijacking another machine to do our dirty work for us, it is possible for us to be on
another network from the impersonated machine and still receive the data meant for him. Two
such techniques currently exist. One is that we can use RMON to sniff the traffic for us (if the
service is installed on that network). By using RMON, we can see the data heading to our
impersonated host, since RMON is an SNMP sniffer. The main problems arise if the network
topology is using switches, and also if there is large amount of data traveling over the
impersonated host’s network. In a case where the network that the impersonated host is on is
transmitting and receiving a lot of data, RMON has been known to drop packets rather quickly,
and slow down the machine it is running on significantly.

The second way of accomplishing our goals in this fashion is to spoof routing traffic so that we
can receive the data meant for the impersonated host. This is considerably easy if we are on the
same network (as in behind the router which handles the exterior routing), and it is using an
interior routing protocol such as RIP v1. Even if the network is using RIP v2 or OSPF we might
be able to sniff the clear text password used by the routers and then go about with our devious
plans.

Implications

The implications of an attacker using non blind IP spoofing against a host is rather vast. The
most obvious is that once these techniques are adopted while trivially by Skript Kiddies, network
administrators and law enforcement can no longer just rely on logs to trace an intruder down.
While it is possible that the interested parties might find enough information on the impersonated
host’s network to be able to piece together what has happened, and still track us down, it is very
unlikely. If the impersonated host was running syslogd, it would be quite slick to send it false
messages which make it appear that another machine has attacked and rooted it. This would
throw the authorities off the trail because they would now have a reason to believe that the
intruder came from another machine which had nothing to do with the attack. Needless to say,
we believe that these techniques create a reasonable doubt in many criminal hacking cases.

For instance, if I was using this technique to purchase goods online using stolen credit cards
numbers, I could make it appear that the person requesting the goods was on a different computer.
This can be used to make a lot of good people look very bad. What if I knew who’s computer I
was impersonating and ordered the stolen merchandise to their address?

Conclusion
Reading this paper you begin to slowly learn about the paradigm shift taking place in the
technological advancements being made by today’s Blackhat’s. Those that are not versed enough
in the black arts of session hijacking are being spoon fed easy-to-use, menu-driven scripts that
automates the task of session hijacking. Needless to say that as time goes on, as the weapons used
by the enemy advance, so must the forensic analysis capabilities of security engineers.

The second paper in this series will focus specifically on using hunt to hijack TCP sessions.
Appendix

Hunt
A TCP/IP Hijacking Utility that can be downloaded separately or installed with Trinux
http://trinux.sourceforge.net/tools.html

Fate Research Labs

http://www.fatelabs.com

Snort IDS
http://www.snort.org

DSNIFF
http://www.monkey.org/~dugsong/dsniff

Eric Hines (“Loki”) Jamie Gamble

Founder, Chief Research Scientist Senior Research Scientist
Fate Research Labs Fate Research Labs
Email: loki@fatelabs.com Email: bit@fatelabs.com