====

			      frel

			      ====

What is frel?
-------------------

Frel is a modified version of fragrouter. It is designed to facilitate
fragmentation in an attack scenario. The basic goals are:    

* To increase awareness in the security community of current risks
concerning NIDS (network intrusion detection system)

* To encourage the NIDS vendors to improve their offerings.

Essentially this code is a proof of concept to show that the IP
address reported by a typical NIDS is probably not too useful. Not
only can the attack machine be a single host, but its interface can be
reconfigured to be any address on the subnet. By using simple spoofing
techniques, the attacker can even make it seen the attack seems to be
coming from another innocent machine on the same subnet.

As with fragrouter, frel is just a one-way fragmenting router. IP
packets get sent from the attacker to frel, which transforms them into
a fragmented data stream to forward to the victim.

             attack                  fragmented attack 
   +-------+        +------------+                      +--------+
   | hax0r |------->|   frel     |- - - - - - - - - - ->| victim |
   +-------+        +------------+           |          +--------+
                                             V
       	                              +------+------+
                                      | network IDS |
                                      +-------------+

Frel has three modes of operation:

1) Vanilla  fragrouter 2-machine configuration
2) Single machine configuration
3) Partial takeover configuration



How does it work?
-----------------

To properly use and configure frel, it helps to have a basic
understanding of what's going on.

A dummy entry is manually added to the attack machine's arp
cache. Then routing is reconfigured so that the stack sends all
packets out to this (non-existent) machine.

Frel sniffs the out-going packets (using tcpdump-style libpcap),
reformats them, and ships them on to the real default router for the
LAN. The routing for the LAN hasn't changed, so responses come
straight back to our interface.

Partial takeover mode is an extension of the same technique. The
attacker reconfigures his machine (A) to have the same address as
another innocent machine (T) who is also located on the same Lan. The
Lan router's (R) arp cache is poisoned using some standard tool such
as Dug Song's arpspoof (available in the dsniff tools package).

This means that A can ship packets to R and the packets will appear to
come from T.

In this mode frel is configured to look at certain ports only. Here
are the possibilities:

1) A sends a packet on an intercepted port. The packet is forwarded
and appears to come from T.

2) A sends a packet on another port. The packet is not forwarded and A
has a timeout.

3) T sends a packet on another port. Router R returns the response to
A who forwards it to T. T goes on as usual.

4) T sends a packet on an intercepted port. For TCP sessions, A's
stack will generate a RST. This is sniffed by frel who forwards a copy
to R and another copy (suitably modified) to T. This effectively shuts
down T on the intercepted ports.
 

Problems with partial takeover mode
-----------------------------------

During testing of partial takeover mode, I saw a Solaris stack finally
decide to arp to find out if it was really talking to the right
machine after all.

This will probably undo the arp cache poisoning in the router. So if
your machine jams while you are working, you might have to redo the
arp poisoning, and maybe even manually reset TCP sessions on the T
machine (using for instance tcpkill from the dsniff package by Dug
Song).

Best of all to takeover a quiet machine without much traffic on the
ports that interest you.

Watch out when you do the arp cache poisoning on the router. If you
play your cards right, you might even shut the entire Lan down by
cutting off its connectivity to the outside world. Not very stealthy
at all.



To make it more stealthy
------------------------

Well just how stealthy do you want to be?

0) Just to state the obvious, when you attack in mode 2 (same machine
configuration), you will probably want to reconfigure the interface to
use some "other" address on the subnet. Then if the NIDS spots the
attack, it will show that some other non-existent host is
attacking. This is probably important even in a Dhcp environment since
lease times can be long sometimes.

1) At least on Linux, you can add a filter to stop the stack from
actually sending the original attack packets on to the wire. This
should save you if a NIDS is running on the same subnet.

2) You could use gated to inject appropriate routing updates into the
friendly neighbourhood router. Then your attack packets could seem to
be coming from a subnet that normally is located in China or some
other far-off place in the network.

3) The code could be modified to do mac-level spoofing. In fact, frel as
it stands does a bit of this (as long as your kernel supports it -
some vanilla BSD kernels won't). In partial takeover mode, the packets
that are legitimately for the other machine (T above) are modified to
look as if they came directly from the LAN router (R).

4) If you are running as root on somebody else's machine (A) that you
have (ahem) borrowed for the occasion, you might want to be more
sophisticated as to the routing that you specify. For instance, if the
victim machine (V) is on subnet S, you could add a specific host route
to send only packets destined for V to the dummy arp address. Then
normal traffic on A will be forwarded as usual, while attack traffic
will go through frel and then on to V.

5) Be aware that some stacks (especially Solaris) send out a
gratuitous arp to announce to the world that they have been
reconfigured. This can poison the arp cache before you are ready for
the traffic. As well, this arp tends to cause console and syslog
messages. As a workaround, you might consider turning off arp support
on the interface. However I haven't tested this and it could cause
other difficulties.


What systems does frel support?
-------------------------------------

Frel should be fairly portable, relying on libpcap and libnet for
packet capture and raw IP packet construction. The dummy arp kludge
should work on most, if not all IP stacks.

Frel has been successfully tested on

	- OpenBSD 2.x
	- Redhat Linux 5.x



Avoiding code bloat and other varia
-----------------------------------

1) I have honestly tried to keep the code small.

For this reason, frel asks for MAC addresses instead of their IP
equivalents.

Also the partial takeover function is what I would call a poor man's
packet inserter. It has none of the elegant bells and whistles that
you would find in, say, hunt. But it does prove my point quite nicely.

2) You can use frel in a single subnet configuration where the victim
machine V is on the same subnet as the attack machine A. To do this,
reconfigure A so that from its point of view, the original subnet is
divided in two parts, with V on the other subnet. In this
configuration, V becomes the "lan router" since that is where you want
frel to send the fragmented packets.

3) Don't try to get too fancy by using IP aliasing on attack machine's
interface. The Libnet routines look at the original interface.

4) When you stop frel with ctl-C, it tends to leave behind jobs in the
background. Don't forget to kill these off. We'll clean this up in a
future version.



Who can use frel?
-----------------

Frel keeps the original fragrouter license. This is a BSD-style
license, and is included in the accompanying LICENSE file. Please read
the license to make sure it's okay to use it in your circumstances.

Contact info?
-------------

Please send bug reports, comments, or questions about this software to
<lorgor@yahoo.com>.

Please do not bother Dug Song or the Anzen people about bugs in my
code.


---
$Id: README,v 1.3 2001/01/13 22:30:29 asdfg Exp $