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

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


NEW DIRECTION IN THE MAN IN THE MIDDLE ATTACK
---------------------------------------------
The man in the middle attack is well known attack where you receive/sniff
packets from network, modify them and insert them back to the network.
In fact the routers/gateways do exactly this but they modify only some
IP headers in the IP packets so they do not reassemble data stream.
Furthermore sniffer or host running hunt does not usually act as a router.
Through ARP spoofing we can manage that instead to the router or ordinary
destination host the originator of connection will send traffic to as. But
there is another problem. How to deal with TCP stream that is in IP packets. 
We can try to reassemble it in our user code as most more sophisticated 
sniffers do but this task is very costly (in terms of programming work) and 
to handle full TCP state machine with all its options, features, etc. is not 
simply easy task. We would prefer that this job will do someone else, let 
say Linux kernel. And this is one of the reasons why I like Linux very much. 
We will use the transproxy capability of Linux to reassemble data 
stream from IP packets and the user code will handle only application data 
as does destination host. Even  though the approach is not fully transparent 
currently for source nor destination host and is not able to handle 
connections that are in the progress already but the concept is here and 
with some hooks it would be probably possible to extend it to fully 
transparent solution.


USED TERMINOLOGY
----------------
I use the term "src" (source) host for the host that originated TCP 
connection and "dst" (destination) host for the host to which "src" host 
tries to connect. (It might be sometimes confusing with ARP spoofing 
terminology used in ARP spoof attack - see README). Of course data
can flow from destination to source as well.


ARP SPOOFING AND REDIRECTING THE TRAFFIC
----------------------------------------
One of the method used to redirect traffic on ethernet to hunt program is arp
spoofing. We have to manage to persuade the host that the ethernet hardware
address (MAC) of router or destination host is something different and then 
listen for packets with that fake MAC from source host. The host will think 
the destination is simply on different MAC so we will have the chance to sniff
that packets. This approach has two nice features. One, the destination host
will not receive this traffic unless it is in promiscuous mode (as usually 
isn't), second, we will see the traffic even when we are on completely 
switched port. This concept is already well known from previous versions of
hunt so it is nothing new to as but transproxy support relies on it.


RECEIVING/SENDING DATA FROM/TO SOURCE HOST
------------------------------------------
Now how we can receive packets from src host? We can do that by simply picking
the traffic from interface in promiscuous mode (when we are using fake mac ARP 
spoofing) and try to reassemble it. But there is more sophisticated solution 
(it has some drawbacks though as nothing is at zero cost). If we will use our 
interface mac address as the fake mac address which we will claim is a mac 
address of someone else and convince remote host that our mac address is 
actually mac address of the destination host then the src host will send the 
traffic with the IP address of destination but with our interface MAC address.
In this case we can setup transproxy redirection in kernel so such a traffic 
that come to our mac address with destination (not our) IP address will be 
picked up by kernel and redirected to another TCP port. That means the kernel
will do complete reassembly and TCP state machine and we then can read that
data form the socket to which the traffic was redirected. The transproxy mode
has one nice capability. When we write to that socket back some data then the
IP packets carrying data will have true destination IP address and not the
address of our host. So the source machine can receive our packets with
correct source/destination IP numbers. The connection will really look like
from source to destination (and not from source to our host). Recall that we
are using our interface MAC address because if we used some fake one then
the Linux kernel would not pick up packets from the network for transproxy
delivery.

It would be a nice feature if the Linux interface in promiscuous mode could
pick up and deliver the packets of configurable (not only host interface) MAC
address to the TCP/IP stack for transproxy redirection.


RECEIVING/SENDING DATA FROM/TO DESTINATION HOST
-----------------------------------------------
So we have the traffic from one end (from the host who originated the 
connection). Unfortunately the transparency for destination side is not ready 
yet. Currently the program that runs on our host and receives redirected data
from source has to make some ordinary connections - probably to the
destination host, so the connection will look like from our host to dst host. 
(We would prefer of course that it will look like from source to destination
but it is not done currently).


DEVELOPING TRANSPROXY PROGRAMS
------------------------------
The major feature of using transproxy support in the kernel is the fact
that we do not have to reassemble TCP stream or handle anything behind TCP.
The transproxy user programs that do all the magic with data are ordinary
programs that use socket interface. We just read/write from/to sockets.
There are plenty of books out there to describe how to use sockets. Assigning
proper IP addresses, port numbers etc does Linux kernel. That is nice, isn't
it.


NEW OPTIONS IN HUNT
-------------------
The changes to support all this was done mainly in arp spoof daemon. It now
supports ARP spoof of IP ranges and even hosts that are currently down. So
immediately after the host boots and tries to communicate with some 
destination the hunt automaticly spoof that host. Host that is down (or
disconnected from the network) does not prevent as doing ARP spoof on it.
In the case that host is down the ARP spoof will be simply deferred to the
time host boots and tries to communicate - hunt will inform as that it is 
not able to find MAC address of that host and let as proceed further. But
we do not need these new options if we are spoofing just one host.

New options in ARP spoof daemon menu:
L) List ranges of IP addresses that was inserted through I)
I) Insert IP range of hosts to which you want to insert some fake
   MAC address of a host.
R) Remove IP range spoof of hosts
T) Test IP range spoof of hosts

These options can be used with normal connection sniffing and hijacking of 
course. Use rather l,i,r,t options (lower case) when you are spoofing just
single host.


TRANSPROXY SUPPORT PROGRAMS
---------------------------
There are new directories and programs.

tpsetup/transproxy is a program to start transproxy mode in Linux kernel.
Make sure you have compiled the kernel with transproxy support (you have to
enable IP_FIREWALL option and ALWAYS_DEFRAGMENT and IP_TRANSPARENT_PROXY
options when you compile the kernel) and have ipchains installed. The 
knowledge how plain transproxy works (from the user point of view) is of
course big plus for you and you will then be able to understand what is going
on and what I am actually describing. The script contains two variables that
control on which port it listens and to which port the traffic will be
redirected.

The DST_PORT is the port to which ordinary clients (source hosts) tries to 
connect.
The DST_PORT_PROXY is the port to which the data are redirected and on which 
listens transproxy user program that does all the black magic with data stream.

tpserv/tpserv is a program that implements the proxy, the attack or whatever 
you want to call it. It just listens on DST_PORT_PROXY that is configurable 
with -p option and receives the reassembled data stream from kernel. Currently 
this program supports a mode in which echoes everything back to the src host 
or the mode in that it connects to destination to which the client wanted to 
connect and relay everything from client to that destination and everything 
from destination to the client. (See the limitations on how the connection 
will look like on destination host). It is possible to insert some code to
this program to modify data from/to source/destination (but this you will have
to do yourself)

The tpserv program supports these options:
-v 	verbose		  (prints connections)
-vv	even more verbose (prints connections and received/send packets)
-D	daemon mode
-c	connection mode (default is echo mode)


HOW IT WORKS TOGETHER
---------------------
Here is small example how to use it. Of course as always with hunt, think
before and then run or modify it.

1. At the beginning run tpsetup/transproxy program.
   The default destination port is 7000 and redirecting port is 7044
   
2. Run tpserv/tpserv -v    (or -vv)

3. Run hunt and enter arp spoof daemon menu. Do not start the daemon unless
   you modify the tpsetup/transproxy script
   "i" insert the single arp spoof in this order:
   	- IP address (name) of your gateway
	      or IP address (name) of destination host if the host is in the
	      same IP subnet as source host
   	- as fake mac address enter 'my' or enter your interface MAC address
	- enter IP address (name) of source host (client) from which you want
	  to receive data - connections.
	- optionally enter refresh interval
   "t" test if the spoof was successful
   
4. from the source host try to run telnet 1.1.1.1 7000
   (or telnet destination_name 7000) and type some chars. The chars should be
   echoed back by tpserv program.
   
You can then play little bit with DST_PORT setting in setup/transproxy script
and/or -c option of tpserv program or change tpserv to modify data going
from/to source/destination.


FEATURES
--------
- the connection from source looks like from source to destination
- the Linux kernel does all the TCP/IP processing
- the user code does not have to deal with raw TCP stream and implements
  only user data processing/modification


LIMITATIONS
-----------
- we have to use our host MAC address as fake spoofing MAC address,
  the traffic from source to destination will have this MAC address
- traffic to the destination is originated form our host so it really looks
  like from our host to destination if used.
- it is possible to start only from newly created connections, it is not
  possible to handle ongoing connections

Be aware of limitations. As I said it does not work fully transparent so
maybe you will be little bit disappointed that the destination host does not
see the original client IP address. Maybe this limitation will be removed
in the future but I do not promise anything ;-)


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