Re: Cisco uplinkfast Dummy frame (Mac address spoofing)

Matthew,

I've read your post both on here and in the INE forums and I'll just paste
my comments in both forums.

Hi Matthew,

I've read your post on groupstudy also. I think the key here is that the
uplinkfast dummy frame, is not necessarily a bpdu.. its a dummy ethernet
frame sent to a multicast mac address...

I do not believe the switch processed the frame, because if the switch
processed the frame, how would it be forwarded onto the other switches in
the layer 2 domain?

Now, I could be completely wrong here but my interpretation of how uplink
fast works is

1. Dummy Ethernet Frames are sent to a multicast mac address which is not
recognised by the switches.. those dummy frames are sent using the mac
addresses which are reachable via this switch.

2. the source address of the ethernet frame is added to the cam table for
that port, against the relevant VLAN. I think if the link that has gone down
was physically down, the mac address would of been removed, if not you may
get a link flap notification but essentially the mac will not be reachable
out of the new interface, instead of having to wait 300seconds for it to
time out.

3. the upstream switch sees the dummy frame, and because it has a multicast
mac address as the destination which is NOT processed by the switch it will
be flooded out all interfaces within the same broadcast domain, which is
normal layer 2 behaviour..

I haven't labbed this up to confirm and I haven't read any documents to
refresh my memory so this is all of the top of my head, but it makes sense
to me because only edge node switches are configured for uplinkfast... I
guess it is possible for cisco to configure every version of IOS to process
the frame, but then you'd be stuck with having to use cisco switches
throughout your entire environment... if the frame is a dummy that isn't
processed but flooded then all switches no matter what vendor should be able
to update efficiently.

So no, in your case it is not a bpdu and therefore BPDU filter nor bpdu
guard will help. BPDU filter actually just ignores bpdus all together and
may potentially cause a loop in the network, if configured under the
interface level.

I think to protect your network from such attacks, port security would be
your answer because port security allows you specify which mac address is
associated to the port and the maximum amount of mac's on a port.

802.1x should stop this kind of attack, provided your attacker is not an
authenticated user!

HTH,

Garth

On Thu, Oct 21, 2010 at 10:53 AM, Andrey Tarasov <andyvt_at_gmail.com> wrote:

> You can achieve the same effect by sending any valid Ethernet frame with
> spoofed source MAC to unknown MAC as destination. It will get flooded over
> L2 domain and all switches will learn new location of source MAC. Port
> security is usually the answer to this problem.
>
>
> On 10/20/2010 7:10 PM, Matthew George wrote:
>
>> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Oct 21 2010 - 20:14:06 ART