/*
 * hunt
 *
 * Copyright (C) 1998 kra
 * Designed and implemented by kra <kra@gncz.cz>
 *
 */


DISCLAIMER
----------
Authors are not responsible of any damages this software can cause.


READ FIRST
----------
Please make sure you KNOW what you are doing before using hunt.
It is recommended that you should test how it behaves on some test
connections and then use it wisely.


OVERVIEW
--------
Hunt is a program for intruding into a connection, watching it and resetting 
it. It has several features, which I didn't find in any product like
Juggernaut or T-sight that inspired me in my development.
I found Juggernaut not flexible enough for further development so I
started from scratch (see FEATURES and DESIGN OVERVIEW).
Note that hunt is operating on Ethernet and is best used for connections
which can be watched through it. However, it is possible to do something
even for hosts on another segments or hosts that are on switched ports. 
The hunt doesn't distinguish between local network connections and connections
going to/from Internet. It can handle all connections it sees.

Connection hijacking is aimed primarily at the telnet or rlogin traffic but 
it can be used for another traffic too.
The reset, watching, arp, ... features are common to all connections.


FEATURES
--------
- connection management
	* setting what connections you are interested in
	* detecting an ongoing connection (not only SYN started)
	* Normal active hijacking with the detection of the ACK storm
	* ARP spoofed/Normal hijacking with the detection of successful 
	  ARP spoof
	* synchronization of the true client with the server after 
	  hijacking (so that the connection don't have to be reset)
	* resetting connection
	* watching connection

- daemons
	* reset daemon for automatic connection resetting
	* arp spoof/relayer daemon for arp spoofing of hosts with the ability
	  to relay all packets from spoofed hosts. 
	* MAC discovery daemon for collecting MAC addresses
	* sniff daemon for logging TCP traffic with the ability to search for
	  a particular string
	
- host resolving
	* deferred host resolving through dedicated DNS helper servers.

- packet engine
	* extensible packet engine for watching TCP, UDP, ICMP and ARP traffic
	* collecting TCP connections with sequence numbers and the ACK storm
	  detection.
- misc.
	* determining which hosts are up

- switched environment
	* hosts on switched ports can be spoofed, sniffed and hijacked too


-------------------------------------------------------------------------------
TECHNICAL EXPLANATION
-------------------------------------------------------------------------------
Let me explain some technical issues which I use in hunt and which are
essential for understanding how it works and what you should expect. 
The important terms are IP spoofing, ARP spoofing and ACK storm.
Even if you are familiar with them, you can get some new information.

	IP spoofing - you set the packet source address to the IP address of 
the host you pretend to be.

	ARP spoofing - you set the packet source hardware address 
(source MAC address) to the address of the host you pretend to be.

	Simple Active Attack against TCP connections - It is a well known type 
of attack in which you send a packet with spoofed IP addresses and possibly
also with spoofed ARP addresses (true MAC addresses of client and server - not 
fake ones as explained further). In this way, you can force a command to the 
stream but you are likely to receive the ACK storm (as explained further) 
unless the original client host of the connection is running Linux.

	ARP spoofing - I use this term also for forcing the remote host 
to think that the host I want to be has a different MAC address so the remote 
host sends replies to that MAC address and the original client host is not 
able to receive them (but hunt is watching carefully and handles all 
consequences) (Explaining how to force a host on the network to think that 
the other host has a different MAC I leave as an exercise - I encourage you 
to read the source code). Please note that I use the term ARP spoofing 
instead of the term ARP forcing or something like that. So don't be confused, 
if I say ARP spoofing, I mean using some MAC address of a host or just some 
fake MAC address. Note that ARP spoofing (with my meaning to force some MAC) 
doesn't work on Solaris2.5 because it has expiration timers on ARP entries
so you can't easily force Solaris to drop an ARP entry. The entry usually 
expires after 20min or less (but you have a chance to force it and hunt 
supports this mode). The expiration timers on Solaris are set by:

ndd -set /dev/ip ip_ire_flush_interval 60000	/* 1 min */
ndd -set /dev/arp arp_cleanup_interval 60	/* 1 min */

and I encourage you to ask your netadmin to set the above values on all
Solaris machines. The Win95/NT4sp3, Linux2.0, OSF1 V4.0, HP-UX10.20 are not 
protected in this way so you can easily use the described technique on them 
(actually, they have timers, but they are not operating like in Solaris; 
in fact, only Solaris is the exception). Actually, hunt uses this technique 
such that it wants to force a fake MAC of the server to the client and a fake 
MAC of the client to the server. Then both the server and the client are 
sending packets to that faked MACs (and hunt can of course handle them). 
However, it is sufficient that only one host has a fake MAC of the other host.
The ACK storm can't occur in this situation either. So you can use this 
technique even if one end is Solaris and the other isn't. You will just 
succeed in the other host and that is enough. So the only problem is when the 
connection is between two Solaris machines. However, if there is any root 
connection ongoing you can easily push the commands suggested above without 
ARP spoofing to the connection and alter the expiration timers of the ARP 
cache.


	ACK Storm - The ACK storm is caused by majority of TCP stacks (!!!
Linux2.0 is an exception !!!). Let's imagine that you send some data to an 
ongoing connection to the server (as if sent by the client - with expected seq.
numbers, ... ). The server responds with the acknowledgment of the data you
sent but this acknowledgment is received by the original client too. But
from the original client point of view, the server has acknowledged data
that doesn't exist on the client. So something strange occurred and the 
original client sends the "right" sequence number with ACK to the server.
But the TCP rules say that it is required to generate an immediate 
acknowledgment when an out-of-order segment is received. This ACK should not 
be delayed. So the server sends the acknowledgment of non-existent data to the
client again. And the client responses, ... 
Only if the source host of the connection is Linux then the ACK storm
doesn't occur. Note that if you use ARP spoofing (forcing) then the ACK
storm can't come because one or both ends will send packets with fake
MACs and those packets are received by hunt rather than by the other host.

	Connection Reset - with a single properly constructed packet
you can reset the connection (RST flag in TCP header). Of course, you have
to know the sequence number but it is not a problem for hunt which is watching
all the time. You can reset server, client, or both. When you reset
only one end the other end is reset when it tries to send data to the
first host which will response with RST because of the connection
reset on it.

	Connection sniffing/watching - the simplest thing you can do is to
silently sit in you chair and watch hunt output about any connection which
you choose from the list.

	Connection Synchronization - well, that's one of the main features of 
hunt. If you put some data to the TCP stream (through simple active attack or
ARP spoofing), you desynchronize the stream from the server/original client 
point of view. After some work done on that connection you can just reset it 
or you can try to synchronize both original ends again. That is not an
easy task. The user on the client is prompted to type some chars and some chars
are sent to the client and server. The main goal of all stuff 
is to synchronize the sequence numbers on both client and server again.

	Switch/Segment traffic rerouting - With ARP spoofing you can
even force switch so that it will send you the traffic for hosts
on another segment/switched port. This is because a switch will think that 
the MAC belongs to your port. Be careful if your switch has some security
policy and MACs have been explicitly set up on a per port basis - but in 
fact I don't ever see such a configuration on "ordinary" network.

	ARP-relay daemon - Don't be confused. I use this term for hunt daemon
which is responsible for inserting packets to the network (rerouting) 
of all data it receives from ARP spoofed hosts.

	Switched environment - Well, the hunt is now capable of watching
and hijacking hosts that are on switched ports. In common you can't watch
the hosts traffic on switched ports but if you first ARP spoof them (with
ARP spoof daemon menu) you are able to look at the connections that
are between that hosts. First you do arp spoof and the hosts will send you
the traffic and from that time you can list the connections between them, then
you can watch and hijack them. It is commonly accepted that the switches 
protect your connections again inside intruders and spoofers. Well, that
is still true for carefully setuped switches. The switches that are
plugged to the LAN without any port security configuration are useless in
the job to protect your LAN.


DESIGN OVERVIEW
---------------
	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 MACs and seq. numbers from the 
server point of view and separate MACs and seq. numbers from the client point 
of view. So it is prepared for hijacking. This information (seq. num., MAC, 
...) 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.

Packets to be sent as a response to the network are described by structures 
so you don't have to care about some default fields or checksums. At this time,
functions for TCP, ICMP and ARP traffic are already prepared. (UDP is missing
because I don't use it in any module)

A separate set of daemons is used for host resolving (DNS). That is because
the gethostbyname/gethostbyname_r function is protected by mutex 
(As far as I know - it was so two years ago - I didn't try it now) so you 
can't run it truly parallel in a multithreaded environment. Therefore, the
commonly used workaround is to fire up some helper daemons through fork which 
will run gethostbyname.


-----------------------------------------------------------------------------
USER ENVIRONMENT
-----------------------------------------------------------------------------

Command line parameters
-----------------------
-V		print version
-v		verbose (print pids of created threads)
-i interface	listen on this interface. Default is eth0


Well, the user environment isn't graphical but I believe that you will like
it.

In the title of all menus is some status information about hunt.
First, there is an indication with which menu you are working. Second, the 
number of packets received by hunt is shown. Hunt pre-allocates some buffers
for packets; the status of free and allocated buffers is displayed as
the third value. The number of free buffers is low for a high loaded network
or the ACK storm or if you have poor hardware. In my case, for example,
the numbers 63/64 were normally indicated meaning that only one buffer was 
used, but after the ACK storm, I have something like 322/323. Note that the 
buffers once allocated are not freed. The low number of free buffers can also 
mean some bug in hunt but I think I carefully debugged all modules to this 
kind of bug. The last indicator reports which daemons (actually threads)
are running. They are: R - reset daemon, Y - arp relayer, S - sniffer,
M - MAC discoverer. If you switch on the verbose option you get additional 
information about how many packets were dropped - they were fragments 
(see the bugs) or were malformed, and how many packets belong to other 
protocols than TCP, UDP, ICMP and ARP.
In the prompt for user input is indicator that will tell you through '*' char 
that hunt added new connection(s) to the connection list since last connection
listening.

General interface
-----------------
In all menus the x key works as escape.
The network mask is denoted by the ip_address/mask notation where mask is the 
number of 1's on the left side of the network mask. For example, 0.0.0.0/0 
means everything and 192.168.32.10/32 means only that host.

For most modules is used:
l) list items
a) add item
m) modify item
d) delete item
They will be referred in this text as l) a) m) d)


List/Watch/Reset connection
---------------------------
You can obtain the list of connections tracked by the hunt packet engine. 
Which connections are tracked is specified in the options menu. You can 
interactively watch or reset these connections. You can also perform 
hijacking on them (next two menu items).

ARP/Simple hijack
-----------------
ARP/Simple hijack offers you an interactive interface for the insertion of data
to the selected connection. You can perform ARP spoofing for both connection 
ends, for only one end or you can not to do it at all. If you don't do ARP 
spoofing then you probably receive the ACK storm after typing the first char. 
When you do ARP spoofing, it is checked if it succeeds. If not, you are 
prompted if you want to wait until it succeeds (you can interrupt this 
waiting through CTRL-C of course). After inserting some data to the connection
you type CTRL-] and then you can synchronize or reset the connection. 
If you choose synchronization, the user is prompted to type some chars and 
after he does so the connection will be in the synchronous state. You can 
interrupt the synchronization process with CTRL-C and then you can reset 
the connection. Note that CTRL-C is used widely for interrupting an ongoing 
process. The CTRL-] (like telnet) is used for finishing the interactive 
insertion of data to the connection. The ARP/Simple hijack doesn't 
automatically reset the connection after it detects the ACK storm so you have 
to do it yourself. Note also that ARP/Simple hijack works with the ARP relayer
(as described further) so that other connections are not affected. Normally, 
if you ARP spoof two servers then the ARP/Simple hijack handles only one 
selected connection between these two hosts but other connections between 
these two hosts look like they freeze. If you start the ARP relayer,
then these other connections are handled and rerouted through. So other
connections from one spoofed host to the other are not affected at all. It is
recommended to run ARP relayer if you do ARP hijacking of two servers.
Note that if you ARP spoof (force) some client MAC to the server
then only connections going from the server to that client are affected. Other
connections from the server to other machines are untouched.

Simple hijack
-------------
Simple hijack allows you to insert a command to the data stream of the 
connection. When you insert the command, hunt waits for it to complete up to 
a certain timeout and if the ACK storm doesn't occur, you are prompted for 
the next command. After that, you can synchronize or reset the connection. 
Note that you can use the interactive interface to simple hijack when you use 
ARP/simple hijack without ARP spoofing but if you use full interactive 
interface of ARP/simple hijack without ARP spoofing you are likely to get the 
ACK storm immediately after typing the first char. So this mode of hijacking 
is useful when you have to deal with the ACK storm because it sends your data 
to the connection in a single packet. When the ACK storm is in progress it is 
very hard to deliver other packets from hunt to the server as the network 
and server are congested.


DAEMONS
-------
I call them daemons but they are actually threads.
All daemons can be started and stooped. Don't be surprised when you
insert or modify some rule in a daemon and it does nothing. The daemon is
not running - you have to start it. All daemons are by default stopped
even though you can alter the configuration. Common commands in the daemons 
menu are:
s)	start the daemon
k)	stop the daemon
l)	list configuration items
a)	add config. item
m)	modify config. item
d)	delete config. item


Reset daemon
------------
This daemon can be used to perform automatic resets of ongoing connections 
that hunt can see. You can describe which connections should be terminated 
by giving src/dst host/mask and src/dst ports. The SYN flag off means that
all specified connections should be terminated (even ongoing). The SYN
flag on means that only newly started connections are reset. So the
connections that are in progress are not affected. Don't forget to start the 
daemon.

ARP daemon
----------
Here you can do ARP spoofing of hosts. You enter src and dst addresses and 
desired srcMAC. The dst is then forced to think that src has srcMAC. You can 
use some fake MAC or better MAC of host that is currently down. You just want 
that the hosts will send you all the data (so you can even look at packets 
that are on a different segment or switched port that you will not normally 
see) The ARP module looks carefully for packets which will break ARP spoofing 
of hosts and handle them but you can even specify the refresh interval for ARP 
spoofing but it is not necessary to do it. Set the refresh interval only if 
you are experienced with some bad or strange behavior of spoofed hosts.
Also there is the possibility to test the hosts for successful spoof with
the ability to force that spoof - it is recommended to test the ARP spoof
if something looks like it is wrong or the computer doesn't send the traffic
to the hunt. The force option is handful if the first spoofing packets
are discarded with switch so if you are running hunt against hosts on
switched ports you can try to run the force mode by example for 10s and
then break it with CTRL-C if the spoof continues to fail.
The ARP relayer daemon is used to perform ARP relaying of ARP spoofed 
connections. When you insert some ARP spoof of hosts the ARP spoofing is 
performed immediately even if the relayer isn't running!!!. But if the ARP 
spoofing succeeds, the connections will look like they freeze. For rerouting
(not IP routing !) these connections through your hunt you need to start 
the ARP relayer. The relayer works well with ARP/simple hijack so once you 
have hosts ARP spoofed with ARP relaying you can easily do ARP/simple 
hijack which will detect that the hosts are already ARP spoofed and takes 
over the connection immediately. With this technique you can easily become
man in the middle from the beginning of the connection even though your 
host with hunt isn't an IP gateway. I encourage you to write other 
application specific protocol handlers for the man in the middle attack as it 
is really simple with this framework.

Sniff daemon
------------
The purpose of the sniff daemon is to log specified packets.
The sniff daemon can also search for a simple pattern (string) in the data 
stream (see the bugs section). You can specify which connection you are 
interested in, where to search (src, dst, both), what do you want to search, 
how many bytes you want to log, from what direction (src, dst, both) and to 
what file should the daemon write. All logged files are stored in the .sniff 
directory. The default file name for logging is composed of the host and port 
names. In the options submenu you can set how to log new lines (\r,\n)
(as new-lines or as hex num.).

MAC discovery daemon
--------------------
This daemon is used to collect MAC addresses corresponding to the specified 
IP range. You can enter the time after which the daemon will try collecting 
again (default is 5min).


Host up menu
------------
The host up module determines which hosts are up (with TCP/IP stack).
You just specify the IP range and that space is then searched for running 
hosts.
It is capable to determine which hosts have network interface in
promiscuous mode. The promiscuous mode usually shows that the host is
running some kind of sniffer/network analyzer.

Options menu
------------
In the options menu you can tune different things:

l) a) m) d) list/add/mod/del connection policy entry
	First of all you can select which connections should be tracked. The
	default setting is to look at telnet connections from all hosts but 
	you can adjust this behavior by the specification of src/dst 
	address/mask src/dst port pairs. With commands: l) a) m) d) you set 
	what you are interested in.

c) connection listening properties
	You can set whether the	sequence numbers and MACs of ongoing 
	connections will be displayed during connection listening.

h) host resolving
	You can turn on resolving of hosts to their names. As the resolving
	is deferred you don't get the names of hosts immediately.
	Just try to list connections several times and you will
	see the hosts names. (I used this deferred approach because I 
	didn't want any delay of interface that the resolving can cause).

r) reset ACK storm timeout
	This timeout is used in simple hijack to automatically reset the
	connection after the ACK storm is detected. Note that you can receive
	the ACK storm even in arp/simple hijack in case you don't perform 
	ACK spoofing of any host.

s) simple hijack timeout for next cmd
	Simple hijack has not an interactive connection interface. That
	means you write the whole command which will be inserted into
	the connection data stream. If no data is transferred through the
        connection up to this timeout, you are prompted for the next command.

q) ARP request/reply packets
	Number of request or reply packets hunt will send when it is doing
	arp spoofing.
	
t) ARP request spoof through request
	Option whether hunt will send ARP spoof request or ARP spoof reply
	when it receives broadcasted ARP request which will break ARP spoof.

w) switched environment
	Some optimization for switched environment. It works perfectly for non
	switched environment also.

y) ARP spoof with my MAC
	Set the originating MAC address of sent spoofed ARP to my (hunt) 
	ethernet MAC - sometimes helps in switched environment.
	
e) learn MAC from IP traffic
	You can enable that MAC addresses will be learned from all
	IP traffic not just from ARP.
	
p) number of printed lines per page in listening
	Self explanatory

v) verbose on/off
	Self explanatory
	
----------------------------------------------------------------------------
TESTED ENVIRONMENT
----------------------------------------------------------------------------
HUNT program requirements:
- Linux >= 2.2
- Glibc with linuxthreads 
- Ethernet

Tested hosts:
Linux 2.0, 2.1, 2.2, Solaris.2.5.1, NT4sp3/4, Win95, OSF V4.0D, HPUX 10.20,
IRIX 6.2, pSOS

Tested network equipment:
BayNetworks 28115, 28200, 300 switches
3Com SuperStack II 3000, 1000 switches


SECURITY NOTES
--------------
Please note the already known truth that telnet and similar programs which send
passwords in clear text are vulnerable to the described attacks. Programs 
using one time passwords are also easily attacked and in fact they are useless 
if someone can run a program like hunt. Only full encrypted traffic isn't 
vulnerable to these attacks but note that you can become a man in the middle 
if you use ARP spoofing (forcing) without the ACK storm and you can try to do 
something. Also unconfigured switch doesn't protect you from sniffing or 
hijacking. It is necessary to carefully configure port security on the switches
in order to protect the computers on the switched ports.

Detecting attacks isn't an easy task. For ARP spoofing there are
tools which can detect it. The ACK storm is detectable by some sophisticated
network analyzers (you can detect the pattern of the ACK storm or the
statistics of ACKs without data). If you run hunt on your network you can 
detect the ACK storm because the hunt can detect the ACK storm pattern.


PERFORMANCE NOTE
----------------
Make sure you are running hunt on idle machine with sufficient power
(I used PII-233 with 128MB RAM) and without any other packet
analyzer because if you use advanced features like arp spoofing or hijacking
hunt needs to reply fast with it's own packets inserted into the traffic on 
the network.


DOWNLOAD
--------
This software can be found at 

http://www.gncz.cz/kra/index.html

or at 

ftp://ftp.gncz.cz/pub/linux/hunt/


KNOWN BUGS
----------
- some structures are poorly locked through mutexes
- if you watch connection then some escape sequences from that connection
  can influent your terminal. Note that your terminal is named "Linux"
  ("xterm" - if you run it from X, ...) but the escape sequences are
  for the client side terminal which may or may not be Linux so you can get
  some mess.
- sniff is not capable to search for a pattern which crosses the packet 
  boundary. That means it can't search for a pattern of the user typed input 
  as this input is usually transferred with 1B data long packets.
- hunt doesn't support defragmentation so the IP fragments have to be dropped.


BUG FIXES, SUGGESTIONS
----------------------
Please send bug descriptions, patches, suggestions, new modules or
successful stories to kra@gncz.cz


ACKNOWLEDGMENTS
---------------
I would like to thank Sven Ubik <ubik@fsid.cvut.cz> for his invaluable 
input and feedback.


--------------------------------------------------------------------------
FINAL WORD
--------------------------------------------------------------------------
Note that this software was written only for my fun in my free time and it 
was a great exercise of TCP/IP protocols. I am now familiar with seq. numbers,
ACKs, timeouts, MACs, checksums, ... to the finest level. As I have some
pretty good background this "hunt" challenge made me think that I hadn't
known TCP/IP as great as I had thought. You are welcome to read the source
code and to try to modify it or write your own modules.