Provided by: hunt_1.5-6_amd64 bug

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  o,0t(ashnew-linesoor asmhex num.). options submenu you can set how to
              log new lines (

       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.

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.

DEBIAN

       This manpage was converted from internal documentation by Jon Marler <  jmarler@debian.org
       > for the Debian GNU/Linux operating system.

                                                                                          HUNT(1)