Taranis
-------
Code by Jonathan Wilkins <jwilkins@bitland.net>
Original concept by Jesse <jesse@bitland.net>
Thanks to Skyper@segfault.net for his assistance

URL: http://www.bitland.net/taranis

Summary
-------
Taranis redirects traffic on switch hardware by sending spoofed ethernet 
traffic.  This is not the same as an ARP poisoning attack as it affects
only the switch, and doesn't rely on ARP packets.  Plus, it is virtually
invisible because the packets it sends aren't seen on any other port on
the switch.  Evading detection by an IDS that may be listening on a 
monitoring port is as simple as changing the type of packet that is sent 
by the packet spoofing thread.

How it works
------------
Here's a diagram of a typical network which I am going to refer to in the 
rest of this article.

Host A     Host B      Host C
(user)   (attacker)   (mail server)
  |          |           |
  \________  |  ________/
           \ | /
           Switch

Switches are built to allow uplinking (when you connect another switch or hub 
into a port instead of a single computer).  As long as there is a way for
this to be configured automatically, the switch is probably vulnerable to this
exploit.

When run, taranis will start sending packets with the mail server's ethernet 
address as the source ethernet address and the attacking machine's real 
ethernet address as the destination address.  When the switch sees this 
packet it will update it's internal table of port->ethernet address mappings.  
(This is called the CAM table.  For more information on how the CAM table
is updated check, http://routergod.com/gilliananderson/
For the record, CAM apparently stands for Content Addressable Memory, an 
extremely generic term) The switch will not forward the packet to any other 
ports as the destination ethernet address is set to an ethernet address 
already associated with the current port.

This internal table looks something like this:

Port 1: 01:00:af:34:53:62
Port 2: 01:e4:5f:2a:63:35 00:c1:24:ee:62:66 ...
Port 3: 11:af:5a:69:08:63 00:17:72:e1:72:70 ...
Port 4: 00:14:62:74:23:5a
...

As far as the switch is concerned, it has a hub connected on that port, and
it just saw a packet from one host on that hub to another host on the same
hub.  It doesn't need to forward it anywhere.

Now that we are seeing traffic destined for the mail server, what can we do
with it?  The initial idea was to perform a man in the middle attack, but 
this proved to be more difficult than anticipated.  (see the comments for
switchtest at the end of this file)  Instead taranis spoofs enough of a pop
or imap session to get a client to authenticate by sending it's username
and password.

Taranis will store this authentication information to a logfile.  To see 
everything displayed in a nicer format run:
  cat taranis.log | sort | uniq

Configuration
-------------
Taranis was developed under FreeBSD 4.3.  It also builds under OpenBSD and
Linux.  If you port it to another platform, send me diff's and I'll integrate
them into the release.

You will require a patch to your kernel to allow you to spoof ethernet source
addresses under FreeBSD and OpenBSD.  LibNet has one for OpenBSD and for 
FreeBSD < 4.0.  I have updated this patch for FreeBSD 4+ and it is included 
in this archive as if_ethersubr.c.patch.  You can use it as follows.. 
- su root
- cd /usr/src/sys/net
- patch < if_ethersubr.c.patch
and then rebuild your kernel

Switchtest
----------
Switchtest was written during the development of Taranis.  It is included in
case someone wants to test their switches and ip stacks.  We weren't able to
find a switch that defaulted to hub mode when confronted with lots of packets
with random source ethernet addresses.  Maybe someone else will.

It also tries a man in the middle attack.  This shouldn't work as it is based
on resending traffic to ethernet broadcast or ethernet multicast addresses.
If a target IP stack is vulnerable, I'd like to hear about it.

We had discussed the possibility of a generalized man in the middle attack.
It is postulated that you could do a decent job of the attack by redirecting 
traffic for a while, and queueing the packets, then resetting the switch (with 
an arp request) and then sending the queued packets, then redirecting again.

This will probably cause a lot of packet drops, but tcp applications may be
able to continue in the face of this..

FAQ
---
Q: Where does the name come from?
A: Taranis was the name of a god in ancient Gaul.  Whenever I can't think of
   a name I randomly grab something from www.pantheon.org.

Q: Why do I keep getting PCAP open errors?
A: You're not root or your kernel doesn't have a pcap compatible way of 
   capturing packets.  Perhaps your network is not ethernet.

Q: Why am I not seeing packets from the target machine?
A: There are several possibilities:
   1. Your system is not spoofing ethernet traffic.  Check the output with
      ethereal (http://ethereal.zing.org/) or tcpdump (www.tcpdump.org)
      If you are using tcpdump use the -e flag to display the link level
      addresses
   2. If the system you are on is spoofing the ethernet frames correctly
      it is possible that the switch has a delay before it will switch the
      port associated with an ethernet address.  Some switches also have 
      a lock in mode, where they will not accept any changes to their
      CAM table.

