[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]

..[ Phrack Magazine ]..
.:: Taranis read your e-mail ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ]
Current issue : #57 | Release date : 2001-08-11 | Editor : Phrack Staff
IntroductionPhrack Staff
Phrack LoopbackPhrack Staff
Phrack Line NoisePhrack Staff
Editorial policyPhrack Staff
IA64 shellcodepapasutra
Taranis read your e-mailjwilkins
ICMP based OS fingerprintingOfir Arkin & Fyodor Yarochkin
Vudo malloc tricksMaXX
Once upon a free()anonymous author
Against the System: Rise of the RobotsMichal Zalewski
Holistic approaches to attack detectionsasha
NIDS on mass parallel processing architecturestorm
Hang on, snoopystealth
Architecture spanning shellcodeeugene
Writing ia32 alphanumeric shellcodesrix
Cupass and the netuserchangepassword problemD.Holiday
Phrack World NewsPhrack Staff
Phrack magazine extraction utilityPhrack Staff
Title : Taranis read your e-mail
Author : jwilkins
                             ==Phrack Inc.==

               Volume 0x0b, Issue 0x39, Phile #0x06 of 0x12

|=-------------------------=[ T A R A N I S ]=---------------------------=|
|=------------------------=[ Jonathan Wilkins ]=-------------------------=|

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

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

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
First, some history.  Back in the old days, we had 10base5, or thick Ethernet.
The 10 prefix meant that it was 10 Megabit and the 5 postfix indicated that
the maximum cable length was 500 meters.  It used a coaxial cable, much like 
cable TV uses. (The difference is in the maximum impedence of the cable, TV 
cable is 75 ohm, ethernet is 50 ohm)  Coaxial cable consists of a central wire 
which is surrounded by a layer of insulator, which is enclosed in a shield 
made of thin stranded wire.  This is all encased in another thinner insulating 
layer.  A thick Ethernet network had a shared backplane and then a series of 
trancievers that plugged into it.  If the shared portion of the cable broke,
or rodents happened to chew through it, then the entire network went down.
Since the cable was usually strung throughout the ceiling and walls it was 
quite inconvenient to fix.  Long runs of cable had to be augmented by a 
repeater, which was just a little device that boosted the signal strength.

A 10base5 network looked something like this:

             Shared backplane
 X-+------+------+------+------+------+-X  (+ - Tranciever)
   |      |      |      |      |      |    (X - Terminator)
   |      |      |      |      |      | 
 Host   Host   Host   Host   Host   Host
   A      B      C      D      E      F

This was replaced by thin Ethernet (10base2, which means that it was 10Mbit and
had a maximum cable length of 200 meters)), which was based on a shared 
cable but didn't require trancievers and so was less expensive.  (10base2 was
also known as cheapernet)  It was also vulnerable to the rodent attack.

10base2 looked something like this:

      Host   Host   Host   Host   Host
        A      B      C      D      E

         (X - terminator which is just a 50 ohm resistor)
         (. - BNC Connector, T shaped piece of metal that
              connected two pieces of cable with a computer)

Then came 10baseT, or Twisted Pair Ethernet.  This was based around a star
topology.  The reason for the name is clear when you see a diagram.

Host A     Host B      Host C
  |          |           |
  \________  |  ________/
           \ | /
       Switch or Hub
           / | \
  /~~~~~~~~  |  ~~~~~~~~\
Host D     Host E      Host F

Now if rats happened to chew through a network cable, only one computer would 
lose network connectivity.  If a giant rat happened to eat the network hub, 
it was easy to crimp new ends on the twisted pair cable and buy a new hub.

An Ethernet Frame header looks like this:

|    |    |    |    |    |    |    |    |    |    |    |    |    |    |
0                             6                             11        13
Bytes 0-5   are the Destination Address
Bytes 6-11  are the Source Address
Bytes 12-13 is  the Type Code (IP is 0x0800)

All of the discussed ethernet types (10base5, 10base2 and 10baseT) are based 
around a shared medium.  This means that packets are broadcast to every 
connected machine.  It also means that when one device is sending, no other
devices can send.

To increase bandwidth, switches were created.  Ethernet switches only forward 
packets to the port (a port is the hole you plug the cable into) that the 
packet is destined for.  (This means all ports in the case of a broadcast 
packet)  This meant that more total packets could be sent through the network 
if a switch were used than if a hub was used.

Switches and hubs are built to allow uplinking (when you connect another switch
or hub into a port instead of just a single computer).  In the case of a hub,
this just means that there are more machines sharing the available bandwidth.
In the case of a switch it means that the internal traffic from one hub won't
be seen on other ports.  It also means that multiple ethernet addresses can be 
on each port and that the switch must contain a list of all of the ethernet 
addresses that are on a given physical port and only forward traffic to the 
port that the destination host is on.  It would be silly to require a network 
administrator to track down the ethernet addresses for each of the connected
machines and enter them manually to build this list, so switches generate this 
list automatically by watching network traffic.  

As long as there is a way for this to be configured automatically, the switch 
is probably vulnerable to this attack.

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   | Ethernet Addresses 
Port 1 | 01:00:af:34:53:62                        (Single host)
Port 2 | 01:e4:5f:2a:63:35 00:c1:24:ee:62:66 ...  (Hub/Switch)
Port 3 | 11:af:5a:69:08:63 00:17:72:e1:72:70 ...  (Hub/Switch)
Port 4 | 00:14:62:74:23:5a                        (Single host)

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

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 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..

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
   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.

Q: Did [insert network type here] really look like that?
A: No. But I have no ascii graphics skills.  When I get a chance I'll track 
   down some real pictures and post them at:

|=[ EOF ]=---------------------------------------------------------------=|

[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]
© Copyleft 1985-2021, Phrack Magazine.