TCP Hijack (tcphijack) is a tool that allows to hijack a TCP
connection and inject arbitrary data in the TCP conversation. This tool
was written as a proof of concept to measure router response to a spoofed
update message using BGP.

To use it, the machine where tcphijack runs on must be able to see the
TCP conversation that it wants to hijack.

A quick example is the best way to illustrate how to use tcphijack:

* Telnet to machine X from machine Y. Log in.

* On machine A (Attacker), run tcphijack like this

$ sudo ./tcphijack -d 500 -c <IP of X> -s <IP of Y> -p telnet \
                   -P payload.txt

The different switches have the following meaning:

-d 500 is a 500 msecs. delay before sending our payload, once we have
   sync'ed with the conversation and have all the data we need to
   hijack it (sequence and acknoledge numbers, port numbers, etc.)
-c for specifying the client's IP address (or hostname)
-s for specifying the server's IP address (or hostname)
-p is the port number to use. Symbolic port names are valid too
   (/etc/services is queried.)
-P is for specifying the payload (a file with the payload, actually)

There's a -t option that can be used to specify a "trigger" file. The
trigger file causes injection to be delayed until a TCP segment arrives
with a payload that is identical to what's in the trigger file.

* In the telnet session, press the space key. This will cause the
telnet client (machine Y) to send ' ' (0x20) to the server (machine
X), which will then reply with the echo of the space. At this point
tcphijack knows all the details it needs to know about the state of the
TCP conversation to be able to hijack the TCP session and inject our
payload.

* Finally tcphijack sends our payload. If the payload file (payload.txt)
has a command, it will be executed as if it was typed by the user using
the telnet session from machine Y.

* Please note that a severe ACK storms happens after we have hijacked
the TCP conversation because the server acknowledges a TCP segment that
the real client never sent, so both server and client keep sending ACKs
to each other, until after several minutes someone gives up and resets
the TCP connection.

* As always, tcpdump is your friend - it'll show you exactly what's
happening on the wire.

Eloy Paris
Cisco Systems Critical Infrastructure Assuarance Group (CIAG)
Questions to: ciag-tools@cisco.com

$Id: README,v 1.5 2003/07/15 17:58:01 peloy Exp $
