Re: switch jamming

[Jeff Nathan <jeff () wwti com>]

Blue Boar wrote:
>

This looked like a great point to interject.

> Just a minor point, in case there is someone out there reading this
> thread, and this is new to them.
>
> There are two widely-understood ways to make a switch send traffic your
> way that it normally wouldn't, for the purpose of sniffing.  One is to
> attempt to cause the MAC address cache to roll over (the is the CAM table
> in the Cisco world.)  The other is to poison the ARP cache of one or more
> nodes in the same broadcast domain as the sniffer.  The latter is not an
> attack against the switch itself per se, but rather the ARP stack of
> the victims.  The small bit of confusion (terminology usage, really) is
> that people are referring to the MAC address cache rollover attack
> as an ARP attack as well.  The frames that cause the problem do not
> have to be ARP packets, though they could be if you want.

There is at leat one other mechanism to do this.  Cisco routers were
vulnerable to having the ARP cache entry for any of their own Ethernet
interfaces overwritten which resulted in a complete DoS of all ARP
functionality on the router itself.  By populating the router's ARP
cache appropriately and using unicast ARP requests OR replies (per the
RFC ARP doesn't care whether a reply or request updates its cache), you
can fairly quietly become the man in the middle until the ARP entires in
the router's cache expires.

http://jeff.wwti.com/blackhat-2001/sonic_boom.txt

> The original poster did not say whether he would have legitimate
> control over the switch, nor what he wanted to monitor traffic for.
>
> Neither of the above mentioned attacks are permanent, nor 100%
> reliable.  You're taking advantage of a race condition in
> a broadcast medium.  You have to keep re-injecting the spoofed
> frames/packets in order to maintain your monitoring, since the
> MAC tables and ARP caches will eventually time out.
>
> So, if your goal is to grab the occasional password, or to see
> part of a TCP connection so that it can be hijacked, then the
> above attacks may be suitable.  You won't need all of the
> traffic all of the time to accomplish that.

The question of how to protect against ARP attacks hasn't touched on the
ability of your network ID system (snort's arpspoof preprocessor for
example) to detect attempted overwrites, etc.  Assuming a switch copies
frames to a span port unmolsted, your network ID system can detect
overwrite attempts and other ARP anomalies on the broadcast domain.

[...]
>                                         BB

-Jeff

-- 
http://jeff.wwti.com            (pgp key available)
"Common sense is the collection of prejudices acquired by age eighteen."
- Albert Einstein