RE: Cisco uplinkfast Dummy frame (Mac address spoofing)

Correct me if Im wrong but this inspects l3 to l2 bindings. ARP is different
from BPDU's. I don't think this would prevent rouge bpdu's

I did manage to test it using a basic BPDU frame and it does work to some
degree. The MAC addresses are instantly updated in all CAM tables on the l2
domain. Communications to the real destination instantly drop and all
communications are forwarded to the new switch. The port spamming the BPDU's
becomes the new destination. It causes a MACFLAP_NOTIF however I'm not for
sure if particular BPDU values would prevent such notifications and the
switch would view the BPDU's as a legitimate uplinkfast dummy frame.

This method would only work if you had a l2 core obviously but none the less
it is a proof of concept.

-Matt George

From: garry baker [mailto:baker.garry_at_gmail.com]
Sent: Wednesday, October 20, 2010 10:01 PM
To: Matthew George
Cc: groupstudy
Subject: Re: Cisco uplinkfast Dummy frame (Mac address spoofing)

would this defeat the kind of attack you are talking about?

Dynamic ARP inspection is a security feature that validates ARP packets in a
network. It intercepts, logs, and discards ARP packets with invalid
IP-to-MAC address bindings. This capability protects the network from
certain man-in-the-middle attacks.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/1
2.2_55_se/configuration/guide/swdynarp.html

--
Garry L. Baker
"There is no 'patch' for stupidity." - www.sqlsecurity.com
On Wed, Oct 20, 2010 at 6:41 PM, Matthew George <mgeorge_at_geores.net> wrote:
I bought up this topic in #Cisco on Freenode and no one has ever heard of
this being done nor can i find any documentation whatsoever regarding the
uplinkfast dummy frame.
So I was reviewing some bridging and switching topics and noticed an
interesting abnormality in the uplinkfast dummy frame. This frame is sent
out the new root port of a switch during an uplinkfast reconvergence with
the destination mac 0100.0ccd.cdcd and sourced from each dynamic mac address
in cam table entry of the originating switch. This is used to ensure
reconvergence time of the cam table on the upstream switches during the
event of a uplinkfast failover. Otherwise uplinkfast is useless right? Why
transition to the next available root port immediately if upstream cam
tables are not going to be updated immediately to reflect the l2 topology
change(s)?
None the less. After reading about this frame, Cisco documents it as a frame
that is forwarded throughout the entire l2 domain, in which case this frame
is processed by the SP then forwarded out all forwarding ports. (I'm
assuming)
The dilemma i run into is; can this frame be crafted in a way to cause a L2
denial of service attack or even the ability to sniff traffic destined to a
server on a network by poisoning the CAM table on all switches on the
network simultaneously.
If indeed the frame is spammed across the entire l2 domain and forces Cisco
switches (only cisco) to update their cam tables to the new spammed MAC
address then this would cause l2 traffic to traverse the network in a
different path.
I've attempted to craft the packet but I've been successful as I'm not for
sure what all fields are required/associated with the uplinkfast dummy frame
as I've not had the ability to capture a uplinkfast dummy frame in the act.
(I'll have to put wireshark to work)
Ultimately the question is; Is there a security mechanism in place on the
Cisco SP to prevent such attacks using spoofed uplinkfast frames?
If no security exist to prevent such spoofing someone would easily be able
to craft frames spammed to a switch with lets say the source mac address of
the DNS servers on a network and the destination mac address of the packet
as the uplinkfast multi-cast destination (0100.0ccd.cdcd) in which case it
would be spammed throughout the l2 domain forcing updates of the cam tables
on every cisco switch thus changing the l2 transit path for traffic destined
to that MAC. After all, in modern networks DNS is practically a critical
role. A Network without DNS could a nasty outage as many app's and services
such as email rely on DNS.
-Matthew George
Blogs and organic groups at http://www.ccie.net