Module 10 (session hijacking)

Ethical Hacking and Countermeasures Exam 312-50 Certified Ethical Hacker
Session Hijacking
Module X Page 1 of 31 Ethical Hacking and Countermeasures Copyright © by EC-Council
All rights reserved. Reproduction is strictly prohibited
Ethical Hacking
Module X
Session Hijacking
Ethical Hacking (EH)
Module X: Session Hijacking
Exam 312-50 Ethical Hacking and Countermeasures

Session Hijacking
EC-Council
Module Objective
Spoofing Vs Hijacking
Types of session hijacking
TCP/IP concepts
Performing Sequence prediction
ACK Storms
Session Hijacking Tools
Module Objectives
This module covers various techniques, tools and tackles used for Session Hijacking, a rather
common hacker activity. On completion of this module you will be familiar with the following
areas:
• Spoofing Vs Hijacking
• Types of session hijacking
• TCP/IP concepts
• Performing Sequence prediction
• ACK Storms
• Session Hijacking Tools

Session Hijacking
EC-Council
Understanding session hijacking
Understanding the flow of
message packets over the
Internet by dissecting the
TCP stack.
Understanding the
security issues involved in
the use of IPv4 standard
Familiarizing with the
basic attacks possible due
to the IPv4 standard.
At its simplest level, TCP hijacking relies on the violation of trust relationships between two
interacting hosts. Before we go into the details of session hijacking, let us take a look at the TCP
stack and the IPv4 protocol, to understand why this attack is possible.
Consider the everyday scenario when you access the Internet with your browser – say IE. IE
works at the application layer and accepts the initial datagram to be sent across the Internet. The
transport protocol comes into action in the next layer – aptly called the transport layer – and the

Session Hijacking
appropriate protocol header is added to the datagram. Here it is TCP header, as it is the TCP
protocol that is being used. This ensures the reliability of data transported over inherently
unreliable communication platforms, and also controls many of the aspects in the management
and initiation of communication between the two hosts. In the network layer, routers offer the
functionality for the datagram to hop from source to the destination, one hop at a time. This also
sees the IP header being added to the datagram. The final layer that communicated with the
physical hardware is the data link layer. This layer is responsible for the delivery of signals from
the source to the destination over a physical communication platform, which in this case is the
Ethernet. This layer also sees the frame header being added to the datagram.
Now, the headers are peeled back on reaching the destination to reveal the original datagram.
Having understood the TCP stack, let us look at IPv4. The original IPv4 standard needed to
address three basic security issues – authentication, integrity and privacy. Authentication was an
issue because an attacker could easily spoof an IP address and exploit a session. Spoofing was not
restricted to IP address alone, but also extended to MAC addresses in ARP spoofing. An attacker
sniffing on a network could sniff packets and carry out simple attacks such as change, delete,
reroute, add, forge or divert data. Perhaps the most popular among these attacks is the Man-In-
the-Middle attack. 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.

Session Hijacking
EC-Council
A spoofing attack is different from a hijack in that an
attacker is not actively taking another user offline to
perform the attack. he pretends to be another user or
machine to gain access.
Attacker
Bob (Victim) Server
I am Bob!
The early record of a session hijacking is perhaps the Morris Worm episode that affected
nearly 6000 computers on the ARPANET in 1988. This was ARPANET’s first automated network
security incident. 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.
Though this has found reference time and again in the context of worms and denial of service, the
basic working of the Morris worm was based on the discovery that the security of a TCP/IP
connection rested in the sequence numbers and that it was possible to predict them. This is called
blind IP spoofing.
Blind IP spoofing involves predicting the sequence numbers that the victimized host will
send in order to create a connection which appears to originate from the host. Before exploring
blind spoofing further, let us take a look at sequence number prediction.
TCP sequence numbers are used to provide flow control and data integrity for TCP sessions. Every
byte in a TCP session has a unique sequence number. Moreover, every TCP segment provides the
sequence number of the initial byte (ISN), as part of the segment header. The initial sequence
number does not start at zero for each session. Instead, the participants specify initial sequence
numbers as part of the handshake process—a different ISN for each direction—and begin
numbering the bytes sequentially from there.

Session Hijacking
Blind IP spoofing relies on the attacker’s ability to predict sequence numbers as he is unable to
sniff the communication between the two hosts by virtue of not being on the same network
segment. He cannot spoof a trusted host on a different network and see the reply packets because
the packets are not routed back to him. He cannot resort to ARP cache poisoning as well because
routers do not route ARP broadcasts across the Internet. As he is not able to see the replies he is
forced to anticipate the responses from the victim and prevent the host from sending a RST to the
victim. The attacker then injects himself 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 NFS, telnet, IRC, etc.
IP spoofing is relatively easy to accomplish. The only pre-requisite on part of the attacker is to
have root access on a machine in order to create raw packets. In order to establish a spoofed
connection the attacker must know what sequence numbers are being used. Therefore, IP
spoofing forces the attacker to have to predict the next sequence number.
The attacker can use "blind" hijacking, to send a command, but can never see the response.
However, a common command would be to set a password allowing access from somewhere else
on the net. The attack became famous when Kevin Mitnick used it to hack into Tsutomu
Shimomura's computer network. The attack exploited the trust that Shimomura's machines had
with the other 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.

Session Hijacking
EC-Council
With Hijacking an attacker is taking over an existing
session, which means he is relying on the legitimate user
to make a connection and authenticate. Then take over the
session.
I am Bob!
Bob (Victim)
Attacker
Server
Bob logs on to server
Dial in
With IP Spoofing there is no need to guess the sequence number since there is no session
currently open with that IP address. The traffic would get back to the attacker only by using
source routing. This is where the attacker tells the network how to route the output and input
from a session, and he simply sniffs it from the network as it passes by him. Source routing is an
IP option used today mainly by network managers to check connectivity. Normally, when an IP
packet leaves a system, its path is controlled by the routers and their current configuration.
Source routing provides a means to override the control of the routers.
When an attacker uses captured, reverse engineered or brute forced authentication tokens to
take over the control of a legitimate user’s web application session while he is in session, the
session is said to be hijacked. Due to this attack, the legitimate user may loose access or be
deprived of the normal functionality of the web session to the attacker, who now acts with the
user’s privileges.
Since most authentications only happen at the initiation of a TCP session, this allows the attacker
to gain access to a target machine. A popular method is to use source-routed IP packets. This
allows an attacker to become a part of the target – host conversation by deceiving the IP packets
to pass through his system.
The attacker can also carry out the classic man-in-the-middle attack by getting "inline" between
the target and the host using a sniffing program to watch the conversation. A common constituent
of these attacks is the execution of a denial-of-service (DoS) attack against the target / host to stop
it from responding by either forcing the machine to crash, or against the network connection to
result in a heavy packet loss (e.g. SYN flood).

Session Hijacking
Session hijacking is even more difficult than IP address spoofing. In session hijacking, John
would seek to insert himself into a session that Jane already had set up with Mail. John would
wait until Jane established a session, then knock her off the air by some means and pick up the
session as though he was her. As before, John would send a scripted set of packets to Mail but
would not be able to see the responses. To do this, he would need to know the sequence number
in use when he hijacked the session, which could be calculated knowing the ISN and the number
of packets that have been exchanged.
Successful session hijacking is extremely difficult and only possible when a number of factors are
under the attacker's control. Knowledge of the ISN would be the least of John's challenges. For
instance, he would need a way to knock Jane off the air at will. He also would need a way to know
the exact status of Jane's session at the moment he mounted his attack. Both of these require that
John have far more knowledge about and control over the session than normally would be
possible.
However, IP address spoofing attacks can only be successful if IP addresses are used for
authentication. An attacker cannot perform IP address spoofing or session hijacking if per-packet
integrity checking is executed. Similarly, neither IP address spoofing nor session hijacking are
possible if the session uses encryption such as SSL or PPTP, as the attacker will not be able to
participate in the key exchange. Therefore the essential requirements to hijack non-encrypted
TCP communications can be listed as: Presence of non-encrypted session oriented traffic, ability
to recognize TCP sequence numbers and predict the next sequence number (NSN) and capability
to spoof a hosts MAC or IP address to receive communications which are not destined for the
attackers host. If the attacker is on the local segment, they can sniff and predict the ISN+1
number and have the traffic routed back to them by poisoning the ARP cache.

Session Hijacking
EC-Council
Steps in Session Hijacking
1. Tracking the session
2. Desynchronizing the connection
3. Injecting the attacker’s packet
How does an attacker go about hijacking a session? The hijack can be broken down into four
broad phases.
• Tracking the connection
The attacker will wait to find a suitable target and host. He use a network sniffer to track
the victim and host or identify a suitable user by scanning with a scanning tool such as
nmap to find a target with a trivial TCP sequence prediction. This is done to ensure that
because the correct sequence and acknowledgement numbers are captured, as packets are
checked by TCP through sequence and/or acknowledgement numbers. These will later be
used by the attacker in crafting his own packets.
• Desynchronizing the connection
A desynchronized state is when a connection between the target and host is in the
established state; or in a stable state with no data transmission; or the server's sequence
number is not equal to the client's acknowledgement number; or the clients sequence
number is not equal to the server's acknowledgement number.
To desynchronize the connection between the target and host, the sequence number or
the acknowledgement number (SEQ/ACK) of the server must be changed. This can be
done if null data is sent to the server so that the server's SEQ/ACK numbers will advance;
while the target machine will not register such an increment.

Session Hijacking
The desynchronizing is preceded by the attacker monitoring the session without
interference till an opportune moment, when he will send a large amount of “null data” to
the server. This data serves only to change the ACK number on the server and does not
affect anything else. The attacker does likewise to the target also. Now both the server and
target are desynchronized.
Another approach is to send a reset flag to the server and tearing down the connection on
the server side. This is ideally done in the early setup stage. The goal of the attacker is to
break the connection on the server side and create a new one with different sequence
number.
The attacker listens for a SYN/ACK packet from the server to the host. On detecting the
packet, he sends an RST to the server and a SYN packet with exactly the same parameters
such as port number but a different sequence number. The server on receiving the RST
packet, closes connection with the target, but initiates another one based on the SYN
packet – with a different sequence number on the same port. Having opened a new
connection, the server sends a SYN/ACK packet to the target for acknowledgement. The
attacker detects (but does not intercept) this and sends back an ACK packet to the server.
Now, the server is in the established state. The target is oblivious to the conversation and
has already switched to the established state when it received the first SYN/ACK packet
from the server. Now both server and target are in desynchronized but established state.
This can also be done using a FIN flag, but this will cause the server to respond with an
ACK and give away the attack through an ACK storm. This results due to a flaw in this
method of hijacking a TCP connection. When receiving an unacceptable packet the host
acknowledges it by sending the expected sequence number and using its own sequence
number. This packet is itself unacceptable and will generate an acknowledgement packet
which in turn will generate an acknowledgement packet, thereby creating a supposedly
endless loop for every data packet sent. The mismatch in SEQ/ACK numbers results in
excess network traffic with both the server and target trying to verify the right sequence.
Since these packets do not carry data they are not retransmitted if the packet is lost.
However, since TCP uses IP the loss of a single packet puts an end to the unwanted
conversation between the server and target on the network.
The desynchronizing stage is added in the hijack sequence so that the target host is kept
in the dark about the attack. Without desynchronizing, the attacker will still be able to
inject data to the server and even keep his identity by spoofing an IP address. However,
he will have to put up with the server’s response being relayed to the target host as well.
• Injecting the attacker's packet
Now that the attacker has interrupted the connection between the server and target, he
can choose to either inject data into the network or actively participate as the "man in the
middle", and pass data from the target to the server, and vice versa, reading and injecting
data as he sees fit.

Session Hijacking
EC-Council
Types of session Hijacking
There are two types of hijacking attacks:
1. Active
In an active attack, an attacker finds an active session
and takes over.
2. Passive
With a passive attack, an attacker hijacks a session,
but sits back and watches and records all of the traffic
that is being sent forth.
Session hijacking can be active or passive in nature depending on the degree of involvement
of the attacker in the attack. The essential difference between an active and passive hijack is that
while an active hijack takes over an existing session, a passive hijack monitors an ongoing session.
Generally a passive attack uses sniffers on the network allowing the attacker to obtain
information such as user id and password so that he can use it later to logon as that user and
claim his privileges. Password sniffing is only the simplest attack that can be performed when raw
access to a network is obtained. Counters against this attack range from using identification
schemes such as one-time password (e.g. skey) to ticketing identification (such as Kerberos).
While these may keep sniffing from yielding any productive results, they do not insure the
network from an active attack neither as long as the data is neither digitally signed nor encrypted.
In an active attack, the attacker takes over an existing session by either tearing down the
connection on one side of the conversation or by actively participating by being the man-in-the-
middle. These have been discussed at length under the discussion covering the various steps
involved in a session hijack.
This requires the ability to predict the sequence number before the target can respond to the
server. Sequence number attacks have become much less likely because OS vendors have changed
the way initial sequence numbers are generated. The old way was to add a constant value to the
next initial sequence number; newer mechanisms use a randomized value for the initial sequence
number.
Examples of active attack include man in the middle attack.

Session Hijacking
EC-Council
TCP Concepts 3 Way Handshake
1. Bob Initiates a connection with the server. Bob sends a
packet to the server with SYN bit set.
2. The server receives this packet and sends back a
packet with the SYN bit and an ISN (Initial Sequence
Number) for the server.
3. Bob sets the ACK bit acknowledging the receipt of the
packet and increments the sequence number by 1
4. The two machines have successfully established a
session.
1
2
3
TCP uses a “three-way handshake”' to establish a new connection. This has been discussed in
detail in module three. For the sake of illustration, let us look at how this exchange shapes up.
Initially, the connection on the client side is in the closed state and the one on the server side is in
the listen state. The client initiates the connection by sending the initial sequence number (ISN)
and setting the SYN flag. Now the client state is in the SYN-SENT state.
On receipt of this packet the server acknowledges the client sequence number, and sends its own
ISN with the SYN flag set. Its state is now SYN-RECEIVED. On receipt of this packet the client
acknowledges the server sequence number by incrementing it and setting the ACK flag. The client
is now in the established state.
On receiving the client’s acknowledgement, the server enters the established state and sends back
the acknowledgment and increments the client sequence number. Closing a connection can be
done by using the FIN or the RST flag.
If the RST flag of a packet is set the receiving host enters the CLOSED state and frees any resource
associated with this instance of the connection. The packet is not acknowledged. Any new
incoming packet for that connection will be dropped.
If the FIN flag of a packet is set the receiving host enters the CLOSE-WAIT state and starts the
process of gracefully closing the connection. When in established state, a packet is acceptable if its
sequence number falls within the expected segment. If the sequence number is beyond the range
of the acceptable sequence numbers, the packet is dropped and an acknowledged packet will be
sent using the expected sequence number.

Session Hijacking
EC-Council
Sequence Numbers
Sequence Numbers are very important to provide
reliable communication but they are also crucial to
hijacking a session.
Sequence numbers are a 32-bit counter, which means
the value can be any of over 4 billion possible
combinations.
The sequence numbers are used to tell the receiving
machine what order the packets should go in when they
are received.
Therefore an attacker must successfully guess the
sequence number to hijack a session.
We have seen the three-way handshake in TCP. TCP provides a full duplex reliable stream
connection between two end points. A connection is uniquely defined by the quadruple (IP
address of sender, TCP port number of the sender, IP address of the receiver, TCP port number of
the receiver).
Every byte that is sent by a host is marked with a sequence number (32 bits integer) and is
acknowledged by the receiver using this sequence number. The sequence number for the first byte
sent is computed during the connection opening. It changes for any new connection based on
rules designed to avoid reuse of the same sequence number for two different sessions of a TCP
connection.
We have sent the increment of sequence number in our discussion of the three way handshake.
What happens when the initial sequence number is predictable? When the TCP sequence is
predictable, an attacker can send packets that are forged to appear to come from a trusted
computer. These forged packets can compromise services, whose authentication is based on IP
addresses. Attackers can also perform session hijacking to gain access to unauthorized
information.
Naturally, the next step was to tighten the OS implementation of TCP and introduce randomness
in the ISN. This was done by the use of pseudo-random number generators (PRNGs). PRNGs
introduced some randomness when producing ISNs used in TCP connections. However, because
of the implications of the Central Limit Theorem, adding a series of numbers together provided
insufficient variance in the range of likely ISN values, thereby allowing an attacker to disrupt or
hijack existing TCP connections or spoof future connections against vulnerable TCP/IP stack
implementations.

Session Hijacking
This implied that systems relying on random increments to make ISN numbers harder to guess
were still vulnerable to statistical attack. In other words, with the passage of time, even computers
choosing random numbers will repeat themselves, because the randomness is based on an
internal algorithm that is used by a particular operating system. Once a sequence number has
been agreed to, all following data will be the ISN+1. This makes injecting data into the
communication stream possible.
If a sequence number within the receive window is known, an attacker can inject data into
the session stream or choose to terminate the connection. If the attacker knows the initial
sequence number, he can send a simple packet to inject data or kill the session if he is aware of
the number of bytes transmitted in the session this far.
As this is a difficult proposition, the attacker can guess a suitable range of sequence numbers and
send out a number of packets into the network with different sequence numbers – but falling
within the range. Relate this point with the discussion of the FIN packet being used to close a
connection in the previous discussion. Since the range is know, it is likely that at least one packet
will be accepted by the server. This way, the attacker need not send a packet for every sequence
number, but resort to sending an appropriate number of packets with sequence numbers a
window-size apart. But how does he know how many packets are to be sent?
This is obtained by dividing the range of sequence numbers to be covered by the fraction of the
window size that is used as an increment. Why was this possible despite the introduction of
PRNGs? The problem lay in the use of increments themselves, random or otherwise, to advance
an ISN counter, making statistical guessing practical. The result of this is that remote attackers
can perform session hijacking or disruption by injecting a flood of packets with a range of ISN
values, one of which may match the expected ISN. If an attacker can predict how a host selects
ISNs, it's possible to conduct two types of attacks, known as IP address spoofing and session
hijacking. The more random the ISNs are, the more difficult it is to carry out these attacks.

Session Hijacking
EC-Council
Programs that perform Session
Hijacking
There are several
programs available that
perform session hijacking.
Following are a few that
belongs to this category:
• Juggernaut
• Hunt
• TTY Watcher
• IP Watcher
• T-Sight
The "Man in the Middle" or "TCP Hijacking" attack is a well known attack where an attacker sniffs
packets from network, modifies them and inserts them back into the network.
There are few programs/source codes available for doing a TCP hijack.
• Juggernaut,
• T-Sight and
• Hunt belong to this category

Session Hijacking
EC-Council
Hacking Tool: Juggernaut
Juggernaut is a network sniffer that can be used to
hijack TCP sessions. It runs on Linux Operating
systems.
Juggernaut can be set to watch for all network traffic or
it can be given a keyword like password to look out for.
The main function of this program is to maintain
information about various session connections that are
occurring on the network.
The attacker can see all the sessions and he can pick a
session he wants to hijack.
Juggernaut is basically a network sniffer that can also be used to hijack TCP sessions. It runs
on Linux and has a Trinux module as well. Juggernaut can be activated to watch all network
traffic on the local network, or can be set to listen for a special "token".
For example, Juggernaut can be configured to wait for the login prompt, and then record the
network traffic that follows (usually capturing the password). By doing so, this tool can be used to
historically capture certain types of traffic by simply leaving the tool running for a few days, and
then the attacker just has to pick up the log file that contains the recorded traffic. This is different
than regular network sniffers that record all network traffic making the log files extremely huge
(and thus easy to detect).
But the main feature of this program is its ability to maintain a connection database. This means
an attacker can watch all the TCP based connection made on the local network, and possibly
"hijack" the session. After the connection is made, the attacker can watch the entire session (for a
telnet session, this means the attacker sees the "playback" of the entire session. This is like
actually seeing the telnet window).
When an active session is watched, the attacker can performed some actions on that connection,
besides passively watching it. Juggernaut is capable of resetting the connection (which basically
means terminating it), and also hijacking the connection - allowing the attacker to insert
commands in the session or even to completely take the session into his/her hands (resetting
connection on the legitimate client).

Session Hijacking
EC-Council
Hacking Tool: Hunt
http://lin.fsid.cvut.cz/^kra/index.html
Hunt is a program that can be used to listen, intercept,
and hijack active sessions on a network.
Hunt Offers:
• Connection management
• ARP Spoofing
• Resetting Connection
• Watching Connection
• MAC Address discovery
• Sniffing TCP traffic
Hunt is designed by Kra. The development model is based on a packet engine (hunt.c) which
runs in its own thread and captures packets from the network. The packet engine collects
information of TCP connections/starting/termination, sequence numbers and MAC addresses. It
collects the MAC addresses and sequence numbers from the server point of view and separate
MAC addresses and sequence numbers from the client point of view. So it is prepared for
hijacking. This information (seq. num., MAC, etc.) is available to modules so they don't have to
analyze and collect it.
Modules can register functions with the packet engine, which are then invoked when new packets
are received. A module function determines if the module is interested in a packet or not and can
place the packet in a module specific list of packets. A module function can also send some packet
to the network if it is desirable to do it very fast. The module (usually in some other thread so it
needs to be scheduled to be run) then gets packets from the list and analyzes them. In this way,
you can easily develop modules, which perform various activities. Refer to the appendix section
for learning the features offered by hunt.
Brief Overview of the Daemons / threads that are used by the exploit:
• Reset daemon - used to perform automatic resets of ongoing connections that hunt can
see. User can describe which connections should be terminated by giving src/dst
host/mask and src/dst ports.
• ARP daemon - used to do ARP spoofing of hosts. User can enter src and dst addresses and
desired src MAC. The dst is then forced to think that src has src MAC. User can use some
fake MAC or better MAC of host that is currently down.

Session Hijacking
• Sniff daemon - can log specified packets. The sniff daemon can also search for a simple
pattern (string) in the data stream. User can specify which connection he is interested in,
where to search (src, dst, both), what he wants to search, how many bytes he wants to log,
from what direction (src, dst, both) and to what file should the daemon write.
• MAC discovery daemon - MAC discovery daemon is used to collect MAC addresses
corresponding to the specified IP range.
Features of the hunt exploit:
• Connection Reset - With a single properly constructed packet the user can reset the
connection (RST flag in TCP header). User can reset server, client, or both. When user
resets only one end the other end is reset. This is because when it tries to send data to the
first host it will respond with RST as the connection is already.
• Connection sniffing/watching – User can watch hunt output for any connection which he
chooses from the list that hunt displays on the console.
• ARP-relay – User can insert packets to the network (rerouting) it receives from ARP
spoofed hosts.
• Connection Synchronization - This is one of the main features of hunt. If the user inputs
some data to the TCP stream (through simple active attack or ARP spoofing), he can
desynchronize the stream from the server/original client point of view. He can also
synchronize the connection after his objective is met. The main goal behind this is to
synchronize the sequence numbers on both client and server again.
• Switch/Segment traffic rerouting - With ARP spoofing the user can force the Switch to
send the traffic for hosts on another segment/switched port. This may not work if the
Switch has some security policy and MACs have been explicitly set up on a per port basis
but in reality this configuration is hardly done on an "ordinary" network.
• ACK Storm - The ACK storm is caused by majority of TCP stacks. We have discussed this
in session hijacking steps.

Session Hijacking
EC-Council
Hacking Tool: TTY Watcher
http://www.cerias.purdue.edu
TTY-watcher is a utility to monitor and control users on
a single system.
Sharing a TTY. Anything the user types into a
monitored TTY window will be sent to the underlying
process. In this way you are sharing a login session with
another user.
After a TTY has been stolen, it can be returned to the
user as though nothing happened.
(Available only for Sun Solaris Systems.)
TTY-Watcher is a utility to monitor and control users on a single system. It is based on our
IP-Watcher utility, which can be used to monitor and control users on an entire network. It is
similar to advise or tap, but with many more advanced features and a user friendly (either X-
Windows or text) interface
TTY-Watcher allows the user to monitor every tty on the system, as well as interact with them by:
1. Sharing a TTY. Anything the user types into a monitored TTY window will be sent to the
underlying process (and consequently echoed back to the real owner of the TTY). In this
way, the user is "sharing" a login session with another user.
2. Termination. At the click of a button (or an escape sequence with the text interface), the
current connection can be instantly terminated.
3. Stealing. Another click of the button allows the user to "steal" the monitored TTY. The
TTY will continue to function as normal for the TTY-Watcher user, but the real owner of
the TTY will see no output, and his keystrokes will be ignored.
4. Returning the TTY. After a TTY has been stolen, it can be returned to the user, as though
nothing happened.
5. Sending the user a message. A message can be sent to the real owner of the TTY without
interfering with the commands he's typing. The message will only be displayed on his
screen and will not be sent to the underlying process.
Aside from monitoring and controlling TTYs, individual connections can be logged to either a raw
logfile for later playback or to a text file. Currently TTY-Watcher works under SunOS 4.x and
Solaris 2.x systems.

Session Hijacking
EC-Council
Hacking Tool: IP watcher
http://engarde.com
IP watcher is a commercial session hijacking tool that
allows you to monitor connections and has active
countermeasures for taking over a session.
The program can monitor all connections on a network
allowing an attacker to display an exact copy of a
session in real-time, just as the user of the session sees
the data.
IP-Watcher is a network security and administration tool that can control any login session
on the network. IP-Watcher is an extremely valuable tool for investigating suspicious activity,
obtaining evidence of misuse, and even stopping malicious users before they do any damage.
This network monitoring tool can be used to inspect the data being transferred between two
hosts. It can monitor all the connections on a network, allowing the user to display an exact copy
of a session in real-time, just as the user of the session sees the data. IP-Watcher features a simple
interface that displays all the sessions it "sees" as well as statistics about the network. IP-Watcher
can monitor any connection on a TCP port.
IP-Watcher can monitor and interact with any connections traveling through the subnet on which
it is running. To accomplish this, IP-Watcher uses a new technique called "IP-Hijacking," which is
intercepting and "spoofing" packets on the IP level. Conversely, IP-Hijacking can be performed
from any machine on a network. The use of active sniffing and a user interface in IP-Watcher
allows a large number of new and far more difficult to defend against attacks than previously
known. These attacks range from simple denial of service on a host or network wide basis, to
information compromise, to full host compromise.
Some of the attack scenarios and features as taken from the risks section on the IP-Watcher
webpage are given below.
• Network (passive) sniffing is easier than ever with IP-Watcher

Session Hijacking
Passwords can be stolen for any given connection. If the password was missed, an
attacker could kill the connection and wait for the user to login again. Most users don't
find network crashing unusual, and will login again without a second thought.
• Active sniffing is more dangerous than any other network attack. Active sniffing exploits a
vulnerability inherent in TCP/IP. Therefore, it's not easily fixed. TCP/IP is based upon
establishing a connection and that connection remaining immutable. Active sniffing
allows connections to be terminated or even "stolen" from the legitimate user.
• Perhaps 99% of the hosts connected to the Internet are vulnerable
The only hosts not vulnerable to an active sniffer attack are those using fully encrypted
connections for all transactions. These sites are rare due to the lack of exportable, easy to
install, portable, well-designed encryption systems.
• Smartcards are a waste of money
Because smartcards (or other one time or challenge response authentication systems)
only verify the user's identity at a particular point in time, the connection is vulnerable to
an active sniffing attack after the real user has authenticated himself. As a result, sniffing
or guessing passwords isn't necessary and these are the only attacks Smartcards protect
against.
• Source address access control doesn't work
Many systems support the use of .rhosts or /etc/hosts.equiv files as a "security measure."
The rationale is if the user doesn't need to type his password, it can't be sniffed. With an
active sniffer, the connection can simply be taken over without the need for password
sniffing.
• Source address filtering doesn't work
Most firewalls control access based upon the source address of an incoming connection.
Once the connection passes the filters of the firewall, it is granted access to a service.
After a connection has been granted access to a service, that connection can be taken over
by an active sniffer, bypassing any firewall filtering mechanisms.
• Kerberos authentication without encryption is worthless
By default, many Kerberos clients authenticate themselves using a strong encryption
system. Unfortunately, after authentication, the client and server revert to an
unencrypted, unauthenticated communication channel (telnet does this by default, for
example). These connections can be easily taken over, rendering the Kerberos
authentication worthless.

Session Hijacking
Denial of Service
IP-Watcher allows the user to individually terminate TCP connections at the press of a button.
More general network control is provided through the Firewall feature of IP-Watcher. It allows
the user to configure patterns of network traffic that will be automatically terminated. For
example, all traffic from a specific host into a given subnet can be killed.
These features are available through IP-Watcher's ability to create network traffic with faked
source and destination addresses. As a result, any individual connection traveling through the
user's network, regardless of source or destination, can be killed.
Denial of service attacks have always been a problem, although many are fairly easy to fix or
avoid. Packet insertion through active sniffing is a problem that is impossible to fix without
serious modifications of the TCP/IP design.
Scenarios
• An attacker takes control of a machine and waits for someone to log on to a particularly
interesting machine. The attacker could then automatically deny service from the
administrative network to prevent the security administrators from logging in, and
potentially discovering the intruder.
• Attackers want to steal the "root" password on a given machine. They automatically deny
service to that particular host from all machines except from the administrative network.
When the system administrator gets calls from users complaining that the host is down,
he or she will likely log in to investigate.
• If connection existed before IP-Watcher was executed, and the attacker wanted to obtain
the password for that particular account without taking over the connection, he could
terminate that particular connection. When IP-Watcher terminates a connection, it looks
to users like the network had a fault, users will simply log in again. When they do so, their
passwords can be stolen.
Information Compromise
Network sniffers have allowed users to record network traffic for a long time, however their
primary limitation is the vast amount of traffic that is recorded. Sniffers recovered from several
hackers toolkits have simplistic schemes to limit the amount of recorded data either by expiring
after a certain amount of time or after a certain amount of traffic has been exchanged over
individual connections. IP-Watcher allows the user to select individual connections that are
interesting and log them either as pure text or as raw packet data. Therefore, if a connection is
"interesting", it can be individually chosen to be logged in its entirety.

Session Hijacking
Scenarios
• A particular machine on the network holds the source code for a proprietary program.
Connections to that machine could be selectively logged and pieces of source code that
users are editing can be stolen.
• After login, a user does a variety of tasks before "su"ing to root. If the connection is being
watched or logged, the root password is stolen.
• An administrator suspects a sniffer has been installed and looks for large files on his file
system. Since IP-Watcher selectively logs connections, only small log files are required,
and won't be found.
Host Compromise
In the past, network sniffers merely allowed an intruder to capture passwords. IP-Watcher allows
the user to interact with existing data streams by allowing him to take over (hijack) the
connection from client to server. To the client, a hijacked connection looks like a network
slowdown, and to the server, the connection looks no different. As a result, one-time passwords
are no longer valuable, as the threat to connections does not come solely from monitoring.
Scenarios
• A user logs in to a valuable machine using a one-time password. The intruder hijacks the
connection and inserts several back doors before terminating the user's connection. The
user suspects nothing, as network slowdowns are common.
• A connection was started before IP-Watcher was run. As a result, the authentication
information is not available. The intruder hijacks the connection and adds a backdoor.
• A router filters incoming connections based upon their source address. The intruder is
from an address that is not allowed by the filter. Therefore, he runs IP-Watcher from a
nearby network provider and monitors a connection from a non-filtered host through the
router. The intruder then hijacks that connection and uses the pre-authenticated
connection for whatever he wishes. The router continues to let packets through, and the
real connection initiator suspects nothing, as network slowdowns are common.

Session Hijacking
EC-Council
T-Sight
http://engarde.com
T-Sight, an advanced intrusion investigation and
response tool for Windows NT and Windows 2000 can
assist you when an attempt at a break-in or compromise
occurs.
With T-sight, you can monitor all your network
connections (i.e. traffic) in real-time and observe the
composition of any suspicious activity that takes place.
T-Sight has the capability to hijack any TCP sessions on
the network.
Due to security reasons Engarde Systems licenses this
software to pre-determined IP address.
T-sight, an advanced intrusion investigation and response tool for Windows NT and
Windows 2000 can assist when an attempt at a break-in or a compromise occurs. While T-sight is
not an automatic intrusion detection system, it does have an alarm system that will activate when
certain transactions take place as an added benefit.
T-sight offers a comprehensive set of reporting and graphing features that will assist with post-
mortem compromise analysis, fraud, waste and abuse audits and network administration.
T-sight assumes that the users have a basic idea of what constitutes suspicious activity on their
networks, yet the program gives the option of viewing connections by "Interest Level." It is
specifically designed to investigate that activity and then let the user take action to stop the attack
(take over or terminate the connection). Firewalls do not stop attacks originating internally or
identify internal fraud, waste and abuse, but T-sight does. Indications of a firewall compromise
will be evident in T-sight's data display. T-sight supplements the authentication program, which
can be circumvented through session hijacking or a backdoor left by a hacker.
Real-time Monitoring: It can interpret connections for telnet, rlogin, ftp, smtp, smb, rsh and http.
Initially, the program presents a completely customizable interface listing the connections
established on the network. The Main Window will display a Major List of protocols, source or
destination IP addresses, and a Minor List containing all active connections. The user can specify
the types of connection data displayed in the Minor List - source and destination IP
address/port/host, start and end times, and last transaction, which can all be sorted, eliminated
or moved as part of the interface.

Session Hijacking

Session Hijacking
This window plays back the connection as it actually transpired, including keystroke timing,
retransmissions, etc.
In the large, white, window the user can see all of the data sent by the server to the client. The line
immediately underneath that contains the data sent by the client to the server. The bar chart
represents the percentage of this connection that has already been played.
Along the right side of the window, the section marked "CT:" displays the "Current Time." That is,
if the user were watching this connection as it happened on the network, which is the time that
would be shown on the clock. The next section, marked "LP:" shows the time of the last packet.
This is useful to show if there is an ACK war, or other extraneous packets being sent which don't
include printable data. The next section, "NP:" shows the time of the next packet.

Session Hijacking
EC-Council
Remote TCP Session Reset Utility
TCP Session Reset is a very easy task using the utility. It is needed to start up the remote TCP
session reset, providing the IP address and the read-write community string of the machine on
which the TCP reset is to be administered. On connecting connect, and a list of active TCP
connections will be visible. Now that the connections are listed, the connections to be reset by
selecting 'Break' from the toolbar.
Similarly, one can also reset all the TCP sessions in one go, by highlighting all TCP sessions and
selecting "Break Selected Sessions" from the "Session" menu.
More features to TCP Session Reset are expected in the next major release.
• Reverse DNS lookup the IP addresses for each session.
• Display "well known" port names.
• Auto-refresh the list of TCP sessions.
• Automatically reset sessions based on client IP address.

Session Hijacking
EC-Council
Dangers posed by Hijacking
1. Most computers are vulnerable
2. Little can be done to protect against it
3. Hijacking is simple to launch
4. Most countermeasures do not work
5. Hijacking is very dangerous.
One-time passwords (Smartcards, S/Key, challenge response)
All one-time password schemes are vulnerable to connection hijacking. Once the user/service has
authenticated itself, their connection can be taken over.
Kerberos
Kerberos services rarely have encryption enabled by default. Consequently, their security is only
as good as a one-time password scheme is subject to hijacking.
Source Address Filtering Router
If a great deal of a network's security is dependant upon filtering packets from
unknown/untrusted sources, then that network is vulnerable to source address spoofing and
connection hijacking. An untrusted host could insert itself in midstream into a pre-existing
connection.
Source Address Controlled Proxies
Many proxies control access to certain commands based upon the source address of the requestor.
The source address is easily vulnerable to active sniffers.
Unfortunately, there are no easy steps, yet, that can be taken to secure your network from active
sniffing. Although, by simply becoming aware that this threat exists, we feel that most people are
better prepared to make intelligent security decisions for their network than those who are
uninformed.

Session Hijacking
EC-Council
Protecting against Session Hijacking
1. Use Encryption
2. Use a secure protocol
3. Limit incoming connections
4. Minimize remote access
5. Have strong authentication.
When practical, limit successful sessions to specific IP addresses. This usually only works
when dealing with an intranet setting where the IP ranges are predictable and finite.
Re-authenticate the user before critical actions are performed (i.e. a purchase, money transfer,
etc.)
If possible, try to limit unique session tokens to each browser instance (e.g. generate the token
with a hash of the MAC address of the computer and process id of the browser, etc.)
Follow the same general set of countermeasures to prevent Replay and Brute Force attacks.
Use x.509 certificates to prevent more traditional types of TCP traffic predictable sequence
number hijacking
• Force all incoming connections from the outside world to be fully encrypted. Attackers
outside of your network will have a much more difficult time if passwords aren't sniffable,
and sessions can't be hijacked.
• Force all connections to critical machines to be fully encrypted. The latest telnet package
allows administrative policies like this to be enforced. Kerberos doesn't allow policies to
be enforced, but will allow encrypted communications, as will SRA telnet/FTP (sometime
soon) and the new STEL (which is currently in beta test) from CERT-IT.
• Force all traffic on your network to be encrypted. Again, Kerberos will help somewhat,
but won't solve all problems (especially not denial of service). Newer systems such as
SKIP will help a great deal, but they are in their infancy.

Session Hijacking
• Use encrypted protocols, like those found in the OpenSSH suite
• The OpenSSH suite includes the ssh program which replaces rlogin and telnet, scp which
replaces rcp, and sftp which replaces ftp. Also included is sshd which is the server side of
the package, and the other basic utilities like ssh-add, ssh-agent, ssh-keygen and sftp-
server.
• Use strong authentication (like Kerberos) or peer-to-peer VPN's.
• Configure the appropriate spoof rules on gateways (internal and external).
• Monitor for ARP cache poisoning, by using IDS products or ARPwatch.

Session Hijacking
EC-Council
Summary
In the case of a session hijacking an attacker relies on the
legitimate user to connect and authenticate and then take
over the session.
In spoofing attack, the attacker pretends to be another
user or machine to gain access.
Successful session hijacking is extremely difficult and only
possible when a number of factors are under the attacker's
control.
Session hijacking can be active or passive in nature
depending on the degree of involvement of the attacker in
the attack.
A variety of tools exist to aid the attacker in perpetrating a
session hijack.
Session Hijacking could be very dangerous and there is a
need for implementing strict countermeasures.
Summary
Recap
• In the case of a session hijacking an attacker relies on the legitimate user to connect and
authenticate and then take over the session.
• In spoofing attack, the attacker pretends to be another user or machine to gain access.
• Successful session hijacking is extremely difficult and only possible when a number of
factors are under the attacker's control.
• Session hijacking can be active or passive in nature depending on the degree of
involvement of the attacker in the attack.
• A variety of tools exist to aid the attacker in perpetrating a session hijack.
• Session Hijacking could be very dangerous and there is a need for implementing strict
countermeasures.

Module 10 (session hijacking)

More Related Content

What's hot (18)

Similar to Module 10 (session hijacking) (20)

More from Wail Hassan (20)

Recently uploaded (20)

Module 10 (session hijacking)