NAME¶
hunt - Network security auditing tool.
SYNOPSIS¶
hunt [-V] [-v] [-i interface]
DESCRIPTION¶
This manual page documents briefly the
hunt command. This manual page was
written for the Debian GNU/Linux distribution because the original program
does not have a manual page. Instead, it has documentation in the GNU Info
format; see below.
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. You may want to select "options" and then
"add conn policy entry" as by default only telnet connections are
monitored.
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.
COMMAND LINE PARAMETERS¶
-V Print Version
-v Verbose (print pids of created threads)
-i interface Listen on this interface. Default is eth0
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 */
- 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,
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¶
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,0 (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, Linux 2.1, Linux 2.2, Solaris 2.5.1, NT4sp3/4, Win95, OSF V4.0D, HPUX
10.20, IRIX 6.2
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.
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.
DEBIAN¶
This manpage was converted from internal documentation by
Jon Marler <
jmarler@debian.org > for the Debian GNU/Linux operating
system.
