Guest

Cisco Catalyst 6500 Series Switches

STP MiTM Attack and L2 Mitigation Techniques on the Cisco Catalyst 6500

  • Viewing Options

  • PDF (9.7 MB)
  • Feedback

Authors:

Kevin Lauerman, CCSP, CISSP 80877
Jeff King, CCIE 11873, CCSP, CISSP 80875

Introduction

The purpose of this paper is to identify how easily the Spanning-Tree Protocol (STP) can be compromised to allow eavesdropping in a switched corporate environment and how to mitigate this vulnerability using L2 security features that are available on the Cisco® Catalyst® 6500.

The Spanning Tree Protocol (STP) Man in The Middle (MiTM) attack compromises the STP “Root Bridge” election process and allows a hacker to use their PC to masquerade as a “Root Bridge,” thus controlling the flow of L2 traffic. In order to understand the attack, the reader must have a basic understanding of the “Root Bridge” Election process and the initial STP operations that build the loop free topology. Therefore, the first section of this document, Overview of the STP Root Bridge Election Process, will be devoted to providing a simplified explanation of 802.1d STP operations as it pertains to understanding the STP MiTM attack. If you require a more comprehensive overview of STP, please review the LAN Switching Chapter of the Cisco Catalyst 6500 Configuration Guide on Cisco.com.

The second section of this document, STP MiTM Attack Guide, is intended to be used as a step by step guide to demonstrate how a single Windows XP laptop running VMware can be easily provisioned to host a Linux Ubuntu OS with a variety of different L2 monitoring and attack tools. This single device, with the addition of dual USB Ethernet NICs in the foreign OS(Ubuntu), can now be used to simulate both the attack PC(Ubuntu/2 NICs) and the victim PC(Windows XP / 1 NIC), allowing an easy demonstration of STP MiTM vulnerabilities.

The final section of this document, Mitigation Techniques for STP Attacks, will identify how the documented STP MiTM attack, and other attacks, can be thwarted on a Cisco Catalyst 6500 by using either the “BPDU Guard” Feature or the “Root Guard” Feature. It will include best practices on the use of these features and the differences in their operation.

Overview of STP Root Bridge Election Process

The STP algorithm/protocol was developed to create loop-free topologies in L2 Networks. It begins this process by electing a Root Bridge from among all the interconnected switches. The switch that is elected as the Root Bridge becomes the base (or root) of the spanning tree from which all the branches are built.

The election process begins with every switch multicasting a specialized type of L2 Frame, called a “Configuration Bridge Protocol Data Unit (BPDU),” and forwarding this packet out each of its ports announcing itself as the Root Bridge. Each switch’s Configuration BPDU contains a field called the Root Identifier, its Bridge Identifier, which is the determining factor in the Root Bridge Election process. The switch with the highest priority Root Idenitifier (in reality the switch that advertises the lowest value) becomes the Root Bridge. The Bridge Identifier is comprised of a 2 byte priority field, with the default value set to 32768 (Cisco Default Value), followed by the 6 Byte MAC address of the switch. By virtue of the 2 byte priority field being set to a default value, the switch with the lowest MAC Address becomes the Root Bridge should all switches advertise the same priority value.

Listed in Table 1 are the full complement of STP BPDU fields that make up a configuration BPDU. The highlighted fields assist in identifying the root bridge and aid in the calculation of the least cost path to the root bridge. This particular BPDU identifies that the sender of this BPDU is the Root Bridge (both the Root ID and the Senders Bridge ID are the same) and that from the Root Bridges perspective its cost to itself is 0. Once adjacent switches realize that this Config BPDU is superior and belongs to the Root Bridge, they stop forwarding out their own BPDUs announcing themselves as the Root Bridge. They will modify this BPDU with their Bridge ID as the sender, add their cost to the root (0 + their cost to root) and forward this modified BPDU out all other ports except the one port that provides the best path to the Root Bridge (Root Port).

Table 1. STP Fields in 802.1D Configuration BPDU

Field

Value

Description

Protocol Identifier

Spanning Tree Protocol (0x0000)

BPDU Type

Configuration

(Identified as a Configuration BPDU as opposed to a TCN BPDU)

BPDU Flags

0x00

Root Identifier

32768 / 00:00:00:00:00:01

(Bridge ID of the Root Bridge)

Root Path Cost

0

Bridge Identifer

32768 / 00:00:00:00:00:01

(Senders Bridge ID)

Port Identifier

0x8303

Message Age

0

Max Age

20

Hello Time

2

Forwarding Delay

15

Figure 1.

Figure 1 represents the beginning stages of the Root Bridge Election process. You will notice that initially all bridges consider themselves to be the root and transmit a Config BPDU declaring themselves to be the Root (Root ID), with a cost to themselves of 0 (Root Path Cost) and their Bridge ID as the sender (Bridge Identifier). There are several other STP fields that make up part of a Config BPDU (see Figure 1) but these fields are the most significant ones (in the order of precedence) that are used to determine both the Root Bridge and the least cost path to the Root Bridge. Bridge 1 in Figure 1 has the lowest MAC address among the participating switches and will therefore be elected the Root Bridge.

During the Root Bridge Election process, each switch will receive and transmit Configuration BPDUs on each of its ports local LAN segments until it is able to determine the best configuration message that was either received on that port or could be transmitted by it (its Configuration BPDU) on that port. The best configuration message would be, in the order of precedence, the message that contained the lowest Root ID, then the lowest cost, then the lowest sending Bridge ID and lastly the lowest value port ID as the least significant tie breaker. If the switch receives a better BPDU than it would transmit on one of its ports, it doesn’t continue to forward BPDUs on that port. Rather, that port will either become a “Root Port” or a “Blocked Port.”

You will notice in Figure 2 that once a “Root Bridge” has been elected and the Spanning Tree Topology has been determined (which ports are Root Ports, Designated Ports and Blocked Ports), “Configuration BPDUs” continue to be generated and flow in one direction away from the “Root Bridge” (out Designated Ports).

Figure 2.

Based on a comparison of received configuration messages and transmitted configuration messages on each port, each bridge is able to independently determine the identity of the root bridge—the best Config BPDU received among all its ports. In the example provided in Figure 2, Bridge 1 will not receive a better configuration message on any of its ports than it could transmit and will continue to transmit configuration BPDUs out all of its ports indefinitely—it has the lowest MAC address (it is the Root Bridge) and thus each of its ports are the closest port on the LAN segment to the “Root Bridge” (Designated Port). Bridge 2, Bridge 3, and Bridge 4 will quickly identify Bridge 1 as the Root Bridge and will stop forwarding BPDUs out of the one port on each bridge that provides the best path from them to the Root Bridge ( Root Port) — their ports facing Bridge 1 will have received the very best configuration message when compared to the configuration messages received on all other switch connected ports and compared to configuration messages that they could transmit. Now that they have determined the Root Bridge, they will calculate their cost to the Root Bridge. The Root Path Cost value in BPDU received on Root Port + their cost to the root (lets say the metric is hop count in this example) and start forwarding BPDUs out all other ports except their “Root Port” announcing Bridge 1 as the “Root Bridge” along with their calculated cost to the “Root Bridge.” All ports that are transmitting a better configuration message than what they are receiving on their LAN segment will become the “Designated Bridge/Designated Port” on that LAN segment and will continue to forward BPDUs. Those ports that are receiving a better configuration message than what they would transmit on a LAN segment will become either a “Root Port” or will be put in a “Blocked Port” status as they represent redundant connections in the network—backup “Root Port.” You will notice in Figure 2 that Bridge 2 is the Designated Bridge/Designated Port on the LAN Segment that connects it to Bridge 3 as it had a better configuration message to transmit than it was receiving from Bridge 3. Bridge 2 is sending a Bridge ID that was lower than Bridge 3. Bridge 3 received a better configuration message than it could transmit on its LAN Segment to Bridge 2 and since it does not provide the best path to the “Root Bridge” (there is already a Root Port on Bridge 3 that provides the best path to Bridge 1) it represents a redundant connection that must be blocked.

Figure 3.

This explanation of STP and the “Root Bridge” election process has been simplified for this document but should be enough to understand how easy it would be to control the flow of traffic in your network by manipulating the Root Bridge election process. Figure 3 illustrates that the location of the “Root Bridge” in your network is significant to L2 traffic flow.

If left to chance, allowing the “Bridge ID” with the lowest MAC address to be the determining factor in the “Root Bridge” election process could lead to a less optimal path for L2 traffic forwarding. You could see from Figure 3 under the Non-Optimal Traffic Flow heading that if an “Access Layer” switch happened to have the lowest MAC address and as a result became the “Root Bridge,” then the resulting data path created by STP could force communications between devices (plugged into different Core switches) to be re-routed through the Access Layer switch. As a result, two servers that should be communicating over a high speed 10Gbps connection between Core switches would be communicating through the Access Layer switch over a 1Gbps connection.

It is more beneficial to control the “Root Bridge” election process, so that a switch in the center of your network (a Core switch) would be elected as the “Root Bridge” (depicted in Figure 3 under the Optimal Traffic Flow heading). This can be accomplished by setting the two byte priority field in the “Bridge ID” to some value that is lower than the default priority value of “32768” for either of the Core switches. This would assure upon switch power up, that the MAC Address portion of the Bridge ID does not become the determining factor in the Root Bridge election process.

In summary, this brief overview is by no means comprehensive and is at best a simplified explanation of STP and the Root Bridge election process. Please refer to the “LAN Switching Chapter” of the Cisco Catalyst 6500 Configuration Guide for a more comprehensive explanation of STP—covering all STP Port States (Blocking, Listening, Learning, Forwarding, Disabled), STP Port Roles (Root Port, Designated Port, Alternate), Topology Change Notification BPDUs (TCN BPDUs), STP Protocol Timers and the various flavors of STP that exist, either as IEEE specs or as proprietary vendor extensions.

STP MiTM Attack Guide

This guide provides step by step instructions on how to compromise the STP “Root Bridge” election process on a L2 network in order to divert the flow of network traffic through a hackers PC masquerading as a L2 switch that has claimed the “Root Bridge” role.

The attack will be depicted in three Attack Stages/Sections as identified below:

Stage I—Connecting Dual NICs

Stage 2—Bridge Dual NICs via Ettercap

Stage 3—“Root Bridge” Takeover via Yersinia

Each of the above Attack Stages/Sections will be organized as follows:

Overview of the attack: Describes the attack stage scenario

Diagram of the Attack: Diagram depicting the attack and the results in one view

Attack Results/6509E: Status of STP on 6509E

Attack Results/6509-svcmod: Status of STP on 6509-svcmod

Step by Step Guide: Step by Step instructions for launching this stage of the attack

The following equipment/software was used in this test scenario:

Lenovo T61P (Victim and Hacking Machine)

Windows XP SP2

- Intel 82566 Internal Gigabit Ethernet Adaptor (Victim PC)

- VMware Server Console 1.0.9 Build-156507

VMware Image/Ubuntu 9.04

Arbor Networks USB Hub

- USB FastEthernet Adaptor/Linksys Model USB300M (Hacker PC)

- USB FastEthernet Adaptor/Linksys Model USB300M (Hacker PC)

Ettercap (Hacking Software)

Yersinia (Hacking Software)

Wireshark (Sniffer Software)

packETH (Sniffer/Packet Editor & Generator)

** It might be noted that a USB hub was used because both Linksys FE Adaptors would not be recognized when connected to two separate USB interfaces in the Lenovo. I am uncertain as to why this was the case. The Linksys USB adaptors were recognized and functioned properly when placed in adjacent ports in the USB hub as depicted in the picture on the next page.

** The Linksys FE adaptors were recognized and usable only by the Ubuntu OS and not by the native OS (Windows XP).

** Please see the Appendix at the end of this document for Step by Step instructions on downloading and installing the Ubuntu Hacking Applications that are used in this test scenario.

** The Wireshark application and the packETH application were not used in this test scenario. Wireshark could have been used in the last stage of the attack to capture information from the Telnet Session (we used Ettercap for this). The packETH application could have been used to capture BPDUs, Edit BPDUs and generate BPDUs (Yersinia was used for this).

Cisco Catalyst 6509 (Hostname = 6509E)

WS-SUP720-3B

- IPSERVICES/Version 12.2(33)SXH3

WS-X6148A-GE-TX

** 6509E configuration is available at the end of this document

Cisco Catalyst 6509 (Hostname = 6509-svcmod)

WS-SUP720-3B

- IPSERVICES/Version 12.2(33)SXH3

WS-X6548

** 6509-svcmod configuration is available at the end of this document

Connecting Dual NICs—STP MiTM Attack / Stage I

Overview of Connecting Dual NICs—STP MiTM Attack / Stage I

In the first stage of the STP MiTM attack a hacker connects their PC with dual NICs to VLAN 7 on each of the Cisco Catalyst 6500s as depicted in Figure 4. You will notice in the diagram on the next page that the STP topology only changes from the perspective that port Gi1/14 on switch 6509E and port Fa7/3 on switch 6509-svcmod are now assuming a “Designated Port” role and are in a data “Forwarding” state. This is the expected STP role and STP state of any port that has a workstation connected to it. A switch port that never receives a “Config BPDU” or never receives a superior “Config BPDU” represents the closest port on that LAN segment to the “Root Bridge” and assumes a “Designated Port” Role (it is the Designated Bridge on that LAN segment). Prior to the Dual NIC connection, neither port Gi1/14 on switch 6509E nor port Fa7/3 on switch 6509-svcmod would have appeared in the STP table.


It should be noted at this point that all workstations depicted in Figure 4 are part of the same hardware platform—Lenovo T61P Laptop. The Victim workstation, however, is running on the native Windows XP SP2 operating system while the hackers PC is running on a Ubuntu 9.04 Vmware Image hosted by the native operating system. (The integrated Gigabit NIC on the Lenovo is only recognized on the native Windows XP operating system while the Dual USB NICs are only recognized by the hosted Ubuntu operating system.)

Figure 4.

6509E Results of Connecting Dual NICs

STP Topology upon connecting Ubuntu Eth1 to port Gi1/14 on 6509E

** The “Root ID” and “Bridge ID” are comprised of both the 2 byte Priority and 6 byte MAC Address Fields. The “Root ID” listed below would be represented in HEX as 8000.0009.7b62.1087.

** A significant item to note from the output of the “sh spanning-tree vlan 7” command on switch 6509E is that the “Root ID” and the “Bridge ID” are different (Indicating that this switch is not the “Root Bridge”). Switch 6509-svcmod is the “Root Bridge” for VLAN 7 because its “Bridge IDs” MAC address 0009.7b62.1087 is a smaller value than switch 6509Es MAC address 00d0.0139.dc07.

** You should also note the role of port Gi1/48 (Root Port) which is an ISL trunk port on switch 6509E that connects it to switch 6509-svcmod. There can only be one “Root Port” per bridge and that “Root Port” represents the port that has the best path to the “Root Bridge”. Switch 6509-svcmod is the “Root Bridge” and port Gi1/48 represents the port with the best path to the “Root Bridge.”

** In the STP root election process, the bridge with the highest priority bridge ID—lowest priority value— wins and in the event of a tie the bridge with the lowest MAC address wins. Given that all switches default bridge priority value is the same—32768—the bridge MAC address becomes the determining factor. Listed below is the output of the “show spanning-tree vlan 7” command from the perspective of switch 6509E. The 6509-svcmod switch wins the Root Bridge Election process with the lowest MAC address for VLAN 7.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768 < Default Cisco Priority Value
Address 0009.7b62.1087 < This is the Bridge MAC Address for VLAN 7 on “6509-svcmod”
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768 < Default Cisco Priority Value
Address 00d0.0139.dc07 < This is the Bridge MAC Address for VLAN 7 on “6509E”
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Desg FWD 19 128.14 P2p < Switchport to Eth1 on Unbuntu Vmware Station
Gi1/48 Root FWD 19 128.48 P2p < Trunk connection to port Fa7/1 on 6509-svcmod

Bridge IDs Generated at VLAN Creation on 6509E

** The Bridge IDs for each VLAN are generated at VLAN creation. The “show spanning-tree bridge” command on each switch will identify the Bridge IDs generated for each VLAN. If left to chance, the lowest bridge ID in a VLAN will be the root bridge. This may not always provide the most optimaltraffic path.

** Notice that the last byte of the MAC Address in the “Bridge ID” (bold text) designates the VLAN of that “Bridge ID”


6509E#sh spanning-tree bridge
Hello Max Fwd
Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 32768 00d0.0139.dc 01 2 20 15 ieee
VLAN0007 32768 00d0.0139.dc 07 2 20 15 ieee
VLAN0010 32768 00d0.0139.dc 0a 2 20 15 ieee
VLAN0020 32768 00d0.0139.dc 14 2 20 15 ieee
VLAN0050 32768 00d0.0139.dc 32 2 20 15 ieee
VLAN0255 32768 00d0.0139.dc ff 2 20 15 ieee
----------------------Not complete Output--------------------------

6509-svcmod Results of Connecting Dual NICs

STP Topology upon connecting Ubuntu Eth2 to port Fa7/3 on 6509-svcmod

** The “Root ID” on switch 6509-svcmod matches the “Bridge ID” on 6509-svcmod. This indicates that switch 6509-svcmod is the “Root Bridge” on VLAN 7.

** Notice that all the port roles on the “Root Bridge” are “Designated Ports.” Designated Ports represent the port on each LAN Segment that is closest to the “Root Bridge.” Since switch 6509-svcmod is the “Root Bridge” all of its ports will assume the “Designated Port” role.

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768 < Default Cisco Priority
Address 0009.7b62.1087 < This is the Bridge MAC Address for VLAN 7 on “6509-svcmod”
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768 < Default Cisco Priority
Address 0009.7b62.1087 < This is the Bridge MAC Address for VLAN 7 on “6509-svcmod”
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim Windows XP workstation
Fa7/3 Desg FWD 19 128.771 P2p < Switchport to Eth2 on Ubuntu Vmware Station Bridge IDs generated at VLAN creation on 6509-svcmod

** Notice how the last 4 bits of the MAC Address in the “Bridge ID” (bold text) designate the VLAN of that “Bridge ID.”

6509-svcmod#sh spanning-tree bridge
Hello Max Fwd
Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 32768 0009.7b62.108 1 2 20 15 ieee
VLAN0007 32768 0009.7b62.108 7 2 20 15 ieee
VLAN0008 32768 0009.7b62.108 8 2 20 15 ieee
----------------------Not complete Output--------------------------

Connecting Dual NICs Step by Step Instructions

You will need to edit the Virtual Machine Settings to add a USB controller. A USB controller is used to enable two USB NICs in Vmware that won’t be recognized by the host operating system — Windows XP. The USB NICs that were used for this testing were both Linksys FastEthernet USBs -- “Model USB300M. They will only be recognized by the Ubuntu Operating System.


Next click add and then follow the prompts for the Hardware Wizard to add hardware to your Ubunutu Vmware Workstation.

Select the USB Controller and hit next.


You will now have a two port USB controller available for use. We will enable our USB Ethernet NICs when we start the Vmware session while disregarding the Windows prompts to configure the USB Ethernet NICs. We now have a single laptop that can be used as both the victim and the attacker. The Victim machine (Windows XP) will only recognize and use the Integrated Lenovo Gigabit NIC while the hacker’s PC ( Ubuntu 9.04) will only recognize the Linksys USB FastEthernet NICs.

Start your Ubuntu Vmware Station.


Follow this sequence of selections to enable your USB Ethernet NICs “VM”> “Removable Devices” > “USB Devices” and look for the Identifier for your particular USB Ethernet NIC. We used dual Linksys USB 300M 10/100 NICs for our testing. These are represented as “ASIX Electronics USB devices.” You need to perform this step twice to add dual NICs.

We are repeating the last step to add the second USB NIC while the Vmware station is booting. If you don’t see the first NIC enabled, you may have to repeat this step.

These check marks verify that the Vmware station accepted the NICs.


You should see your USB NICs displayed at the lower right hand side of the screen upon booting.

Bridge Dual NICs via Ettercap – STP MiTM Attack / Stage II

Overview of Bridging Dual NICs via Ettercap – STP MiTM Attack / Stage II

In the second stage of the STP MiTM attack that is depicted in Figure 5, the hacker PC uses a hacking application called “Ettercap” to bridge and sniff the connections between its dual NICs in VLAN 7. The hacker PC is now just a bump in the wire that connects switch 6509E to switch 6509-svcmod via ports Gi1/14 and Fa7/3 respectively. The switches will start receiving each other’s “Configuration BPDU” over the connection and port Gi1/14 will receive a superior “Configuration BPDU” from port Fa7/3 that will result in port Gi1/14 placing itself in a “Blocking” state. Port Gi1/14 is a redundant connection that provides an alternate path to the “Root Bridge” but does not represent the best path “Root Port” to the “Root Bridge” from the perspective of switch 6509E. Remember, there can only be one “Root Port” per bridge. The Spanning Tree Protocol has done its job by eliminating a loop condition!

What determined that port Gi1/48 had a better path to the “Root Bridge” (Root Port) than port Gi1/14 on switch 6509E? All other “configuration BPDU” information being equal, it came down to the Port ID (see Table 2 below). Ports Fa7/1 and Fa7/3 were both transmitting the same information to ports Gi1/48 and Gi1/14 respectively, except for their unique port IDs. Port Fa7/1 has a lower Port ID (769) than port fa7/3 (771)—the Port ID is actually a two byte value made up of a port priority (128 in bold text) and port number (769 and 771 respectively in bold text) but the port priority would not be relevant as it would be the same value on all switch ports. The Port number portion of the Port ID became the tie breaker!

Table 2.

Config BPDU Gi1/48 received from Fa7/1 Config BPDU Gi1/14 received from Fa7/3
Root ID - 32768 0009.7b62.1087 = Root ID - 32768 0009.7b62.1087
Cost - 0 = Cost – 0
Bridge ID - 32768 0009.7b62.1087 = Bridge ID - 32768 0009.7b62.1087
Port ID - 128.769 (Decimal Value) < Port ID - 128.771 (Decimal Value)

Although bridging the hacker’s PC dual NICs with “Ettercap” didn’t allow it to sniff traffic or change the topology of the L2 forwarding path, as the redundant connection was terminated by blocking on port Gi1/14, this didn’t necessarily have to be the case. If port Fa7/3 on switch 6509-svcmod would have had a lower Bridge Port # than port Fa7/1 on switch 6509-svcmod then port Gi1/14 on switch 6509E would have received a better “Configuration BPDU” from port Fa7/3 on switch 6509-svcmod than what was received on port Gi/1/48 on switch 6509E from port Fa7/1 on switch 6509-svcmod. This would have meant that port Gi1/14 on switch 6509E would have became the “Root Port” (the port with the best path to the “Root Bridge”) and port Gi1/48 on switch 6509E would have represented the “blocked” redundant connection. All traffic traversing the switches would have passed through the hacker PC and therefore could have been sniffed without the hacker’s PC attempting to claim the “Root Bridge” role. Actually with more stealth than assuming a “Root Bridge” role!

Figure 5.

6509E Results of Bridging Dual NICs in Ettercap

STP Topology Changes on 6509E resulting from Bridging Dual NICs in Ettercap

** We are seeing the same result below as we would expect to see if we had used a single cable to connect port Gi1/14 on switch 6509E to port Fa7/3 on switch 6509-svcmod. This connection represents a redundant connection between the switches and STP places the Gi1/14 port in a blocking status to avoid a bridging loop.

** Why is port Gi1/14 blocked as opposed to port Gi1/48? All things being equal in the Conf BPDUs (“Root ID,” “Root Path Cost,” “Bridge ID”) being received from Fa7/3 and Fa7/1 respectively, it came down to the lowest unique port ID (Fa7/3 had a port ID of 771 and Fa7/1 had a port ID of 769). The Port ID on the received BPDUs became the tie breaker.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Altn BLK 19 128.14 P2p < Ettercap Bridged to Fa7/3 on 6509-svcmod /Port has changed
Its STP Port State to “Blocking.”
Gi1/48 Root FWD 19 128.48 P2p < Trunk connection to port Fa7/1 on 6509-svcmod

6509-svcmod Results of Bridging Dual NICs in Ettercap

STP Topology Changes on 6509-svcmod resulting from Bridging Dual NICs in Ettercap

** Notice the highlighted Port IDs in the STP Column Heading of “Prio.Nbr” in the below output. Port Fa7/1 has a lower Port ID than Port Fa7/3 which forces port Gi1/48 on switch 6509E to remain active while blocking Port Gi1/14 on switch 6509E. Ports Gi1/48 and Gi1/14 on switch 6509E have received superior BPDUs from both Fa7/1 and Fa7/3, respectively, on switch 6509-svcmod (Root Bridge) but only the port that has the best path to the Root Bridge can be the “Root Port” on switch 6509E. All things being equal in the received Conf BPDU (“Root ID,” “Root Path Cost,” and “Bridge ID”), the “Port ID” becomes the determining factor!

** We will see in stage three of the attack that the hex respresentation for the Port ID on Port Fa7/1 is “8303.” The Port ID is a two byte value that represents both a priority value and a port number. The priority value would be the same on all switch ports, so the port number portion of the Port ID becomes relevant.

6509-svcmod#sh spanning-tree vlan 7

VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim Windows XP workstation
Fa7/3 Desg FWD 19 128.771 P2p < Ettercap Bridged to Gi1/14 on 6509E

Bridging Dual NICs via Ettercap Step by Step Instructions

You can launch the first phase of our attack with the Ettercap application. It can be found both under the “System Tools” and “Internet” applications.

Once ettercap is launched, we select “Bridged sniffing” to allow bridging between our dual NICs - Eth1 & Eth2. This is high stealth and allows us to be a bump on the wire.


Ettercap recognizes the two configured NICs and offers them as possible bridged connections.

Start sniffing the bridged connection.


The status screen verifies that Bridged Sniffing has been started.

We have successfully completed Bridging the dual NICs, so lets get ready to view connections.

Why can’t we see connections travelling over our Bridged NICs? Yes, the Spanning Tree Protocol is at work. Refer back to Figure 5 to see how bridging between the dual NICs via Ettercap has modified the STP topology. Leave the “Connections” window open. We will be coming back to view connections in Stage III of the attack, upon claiming the “Root Bridge” role and altering the flow of L2 traffic.

“Root Bridge” Takover via Yersinia – STP MiTM Attack / Stage III

Overview of “Root Bridge” Takover via Yersinia – STP MiTM Attack / Stage III

In the third stage of the STP MiTM attack depicted in Figure 6, the hacker PC launches a second hacking application called “Yersinia” that will craft and transmit a “Configuration BPDU” out each of its dual NICs (eth1 and eth2) that will be superior (Root ID/Bridge ID MAC address will be a lower value) to the “Configuration BPDU” transmitted by the current “Root Bridge” (6509-svcmod) on VLAN 7. The hacker PC will appear to be a new switch connected to the network that has been elected as the “Root Bridge”. The STP topology will change as a result and intercommunication between the switches will be forwarded through the new “Root Bridge” (Hacker PC). This will allow a telnet session to the Cisco Catalyst 6509E from the Victim PC on port Fa7/2 of switch 6509-svcmod to flow through the hacker PC and be intercepted by “Ettercap.”

You will notice in Figure 6 that some STP topology changes have taken place that will change the flow of L2 traffic in the network. Port Gi1/14 on switch 6509E and port Fa7/3 on switch 6509-svcmod are now assuming a “Root Port” role with an STP state of “forwarding” as they are directly connected to the Hacker PC and represent the best path to the new “Root Bridge.” This has forced the Gi1/48 port on switch 6509E to transition from a “Root Port” role with an STP “forwarding” state to an “Alternate” role with an STP “blocking” state. It has a received a superior “Configuration BPDU” from port Fa7/1 on switch 6509-svcmod (switch 6509-svcmod has a lower Bridge ID than switch 6509E) but doesn’t represent the best path (Root Port) on switch 6509E to the “Root Bridge.”


The Yersinia application assures that it will generate a superior “Configuration BPDU” by first sniffing the wire to determine the “Bridge ID/Root ID” of the current “Root Bridge” on the L2 network. It will then craft/fabricate its own “Configuration BPDU” manipulating the MAC Address portion of the “Bridge ID/Root ID” to be similar to the current “Root Bridge” while being a lesser value. This makes it difficult for network administrators that are casually browsing the network to determine that the “Root ID/Bridge ID” of the “Root Bridge” has changed. Please see Table 3 for the subtle differences in the “Root ID/Bridge ID” of switch 6509-svcmod on VLAN 7 as compared to the “Root ID/Bridge ID” of the hacker PC assuming the newly elected “Root Bridge” role.

Table 3.

Switch

VLAN

Root ID/Bridge ID

6509-svcmod

7

8000.0009.7b62.1087

Hacker PC/Yersinia

7

8000.0009.7b61.1087

You will notice in the “Root Bridge” Takeover via Yersinia Step by Step Instructions that there appears to be a more obvious attack choice titled “Claiming Root Role with MiTM” as opposed to the attack choice used in this lab of just “Claiming Root Role.” The “Claiming Root Role with MiTM” STP attack is listed as a Denial of Service (DOS) attack but when tested didn’t appear to work—it generated no “Configuration BPDU” whatsoever. It was discovered through testing that the STP MiTM attack could be implemented with both the use of “Ettercap” (Bridging the NICs) and “Yersinia” (Generating the BPDUs).

Figure 6.


6509E Results of “Root Bridge” Takeover via Yersinia

STP Topology Changes on 6509E after “Root Bridge” takeover via Yersinia

** Notice that port Gi1/14 on switch 6509E has now assumed the “Root Port” role with an STP state of “Forwarding.” It has to have the best path to the “Root Bridge” because it is connected to Eth1 on the hacker PC (Root Bridge).

** Notice that port Gi1/48 on switch 6509E has now transitioned from a “Root Port” role with a STP “forwarding” state to an “Alternate” role with a STP “blocking” state. It no longer provides the best path to the “Root Bridge” from the 6509E and it is receiving a superior BPDU from port Fa7/1 on switch 6509-svcmod. It represents a redundant connection that STP will block.

6509E#sh spanning-tree vlan 7

VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b61.1087 < “Root ID” crafted/fabricated by Yersinia Appliction
Cost 19
Port 14 (GigabitEthernet1/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Root FWD 19 128.14 P2p < Ubuntu Workstation Eth1 (New Root Port)
Gi1/48 Altn BLK 19 128.48 P2p <Original Trunk port is now blocking for VLAN 7

6509-svcmod Results of “Root Bridge” Takeover via Yersinia

STP Topology Changes on 6509-svcmod after “Root Bridge” takeover via Yersinia

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768 < Default Priority
Address 0009.7b 61.1087 < Yersinia generates a lower MAC address to become root
Cost 19
Port 771 (FastEthernet7/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768 < Default Priority
Address 0009.7b 62.1087 < Old Root Bridge MAC Address loses root preference
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p <Trunk Port is Designated Port
Fa7/2 Desg FWD 19 128.770 P2p < Victim Windows XP workstation
Fa7/3 Root FWD 19 128.771 P2p <Ubuntu Workstation Eth2 (New Root Port)

“Root Bridge” Takeover via Yersinia Step by Step Instructions

Open a terminal windown under Applications > Accessories.

Give yourself kernel privileges by entering the “sudo su” command and providing the kernel/supervisor password. Then launch the Yersinia application by typing “yersinia –G”

Select the STP packet capture screen by clicking the “STP” label at the top of the screen. You will notice that Yersinia has already recognized a “config bpdu” forwarded by the Root Bridge. You can recognize from the below partial output from a “show spanning-tree bridge” on the root bridge (CAT6509-svcmod) that the bridge/root id is from VLAN 7—notice that the last 4 bits in hex in the bridge ID represent the VLAN value.


6509-svcmod#sh spanning-tree bridge

Hello Max Fwd
VLAN Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 32768 0009.7b62.1081 <<VLAN 1 2 20 15 ieee
VLAN0007 32768 0009.7b62.1087 <<VLAN 7 2 20 15 ieee

Yersinia is capturing a “config bpdu” from the Root Bridge in preparation for an attack.

Option to spoof the source MAC address. It is set by default to MAC Spoof. It doesn’t matter how you set this option in the yersinia GUI as it will spoof regardless.


We need both interfaces available to launch a MiTM STP attack. Click the “Edit Interfaces” button and enable the eth2 interface by checking the box.

You can now see “config bpdus” from the root bridge on eth2. You are now ready to assume the Root Bridge Role!


Click launch attack in the upper left corner. Since you were in the capture viewing screen for STP, you should be provided with a list of attacks for STP. You will want to select the “Claiming Root Role” attack. Don’t select the “Claiming Root Role with MiTM” attack. We don’t want to DOS Attack the system. We want to snoop on conversations transiting the switches over VLAN 7.

If you want to see packet details, look in the lower left hand corner for a packet dissection. This is the “config bpdu” from the root that was observed on eth1. I have dragged this window up for viewing.


Packet details for the “config bpdu” captured on eth2. (See highlighted packet below)

This packet (see highlighted packet below) is the attack packet generated by the Ubuntu Workstation on eth1 claiming this bridge as the root bridge. Compare the Rootid/Bridgeid to the eth1 packet two rows above it. Don’t forget that the first 2 bytes of the Rootid/Bridgeid is the priority of the bridge—hex 8000 = 32768(default switch value) and that the last 6 bytes of the Rootid/Bridgeid are the MAC address of the bridge. If the Bridge priorities are equal, which is the default setting on all switches, the determining factor is the lowest MAC address between the competing bridges. Yersinia generates a lower bridge MAC address than the existing “Root Bridge” to claim the “Root Bridge” role. Compare the values in the 4th byte of the 6 byte MAC address that follows the priority bits, “62” above compared to “61” below, sniffed by Yersinia 8000.0097B621987, generated by Yersinia 8000.0097B611987.


The same is true on eth2. We have generated the same “config bpdu” and have claimed the root role.

Notice that after we started claiming the “Root Bridge” Role on Eth1 and Eth2 that a topology change notification bpdu—TCN bpdu—was captured on both eth1 and eth2. This is verification that a topology change is taking place due to the new root election process. A “TCN BPDU” unlike a “Configuration BPDU’ is forwarded toward the “Root Bridge.”


The same “TCN bpdu” is also seen on eth2.

A telnet from the victim machine, connected to switchport fa7/2 on “CAT6509-svcmod,” to the Cisco Catalyst 6509E will now be compromised. The victim has a telnet session open to the Cisco Catalyst 6509E and has issued a “show spanning-tree vlan 7” command. The hacking machine has altered the STP Topology, and therefore the telnet session between the switches will have to travel over the new root ports—Gi1/14 and Fa7/3—and through the hacking machine in order to traverse the switches.


Here is the captured Telnet session from Ettercap on the Hacking machine. We can double click on the highlighted connection to see the session details.

Here are the details of the session/conversation split out between the two participants. There are selection tabs listed below the viewing screen that allow you to manipulate the conversation. We will be selecting the “Join Views” to get a single view of the whole conversation.


It is more obvious from this joined view that we have captured passwords that were part of the initial authentication into this telnet session. The same could have been accomplished using a packet sniffing product such as Wireshark.

Mitigation Techniques for STP Attacks

The two best methods for thwarting the documented STP MiTM attack, in which a rogue workstation starts generating superior Configuration BPDUs in order to elect itself as the Root Bridge, would be enabling either the Cisco Catalyst “BPDU Guard” or “Root Guard” feature.

The Cisco Catalyst “BPDU Guard” feature is the most comprehensive STP protection mechanism as it doesn’t allow any device sitting behind a “BPDU Guard” enabled interface to influence the STP topology. On a “BPDU Guard” enabled interface, the first reception of any type of BPDU will force the port into an “err-disable” state of “Interface is down, line protocol is down (err-disabled).” The port will remain in this “err-disable” state until an administrator manually resets it via a “shutdown”/”no shutdown” cli command on the interface. This will keep a user device, using either Yersinia or a packet generator tool such as Packeth, from generating a fabricated BPDU in an attempt to either cause an STP DOS attack or to claim the Root Bridge role. The feature should be enabled on all interfaces that will not connect to other switches (user interfaces) and therefore shouldn’t be involved in STP. User devices (Workstations/Laptops) don’t generate BPDUs and shouldn’t be participating in determining the L2 topology.

The Cisco Catalyst “Root Guard” feature is also enabled on an interface by interface basis but will only stop data from being forwarded on an interface while it is receiving superior Config BPDUs. It prevents a port from becoming a “Root Port” or “Blocked Port.” If a “Root Guard” enabled interface receives a superior BPDU, the port is placed in an STP “Blocking” state for being “root-inconsistent” and will not forward traffic as long as it continues to receive superior BPDUs. The “blocking (root-inconsistent)” state will have no affect on the status of the interface (a “show interface” command will display that the “interface is up, line protocol is up”) but will rather affect the STP status of the switch port. Once the interface stops receiving superior config BPDUs, the port will transition back to a data forwarding state without any intervention by an administrator. This feature should be enabled on all interfaces that will connect to other switches that you want to remain “Designated Ports” (Bridge port on the LAN Segment closest to the Root Bridge). It will keep that port from transitioning to a “Root Port” (Bridge port that has the best path to the Root Bridge/only one root port per nonroot bridge) or “Blocked Port” (Backup Root Port) status. Although not the preferred mitigation technique to be used on a user switch port, since other types of BPDUs (TCN BPDUs) can be generated that can create a DOS attack which won’t place the interface in a root-inconsistent state, it was used in our STP MiTM scenario to differentiate its functionality from BPDU Guard.

The BPDU Guard Mitigation and Root Guard Mitigation sections that follow will walk through each phase of the documented STP MiTM attack with the respective mitigation technique enabled. Each section will identify the appropriate configuration commands for enabling the respective feature along with the results viewed on the console and the output of various show commands (show spanning-tree vlan 7 and show interface ) during each stage of the STP MiTM Attack (Stage I – Connecting Dual NICs, Stage II – Bridging NICs with Ettercap, and Stage III – Yersinia attempting election as Root Bridge). Each respective section will also identify what it takes to recover from the mitigation technique once the attack has ended.

BPDU Guard Mitigation

Figure 7. Mitigation: BPDU Guard Configuration/Dual NIC Connection

The above diagram depicts Stage I of the MiTM attack where a hacker’s PC with dual NICs attaches to switch ports that belong to VLAN 7 on both Cisco Catalyst 6500 switches. This time, however, BPDU Guard is enabled on both switch ports (Gi1/14 and Fa7/3) with the interface configuration command “spanning-tree bpud guard enable.” There is an alternate method of enabling BPDU Guard with the Global command “spanning-tree portfast bpduguard default.” This enables BPDU guard on every interface that has been configured for portfast with the “spanning-tree portfast” command.

You will notice in the above diagram that switches transmit BPDUs to determine whether they are connected to another switch that is participating in STP. Workstations don’t participate in STP and don’t transmit BPDUs. Since the switches aren’t receiving BPDUs on their PC connected switch ports (Gi1/14 and Fa7/3), neither of the ports will transition to an “err-disabled” status. Both switch ports assume a “Designated Port” Role with a status of “Forwarding” which is normal for a switch port connected to a user device that never receives an incoming BPDU.

BPDU Guard Configuration

6509E “BPDU Guard” Configuration

BPDU Guard - Interface Configuration on 6509E
**Configure/enable BPDU guard on every interface that is connected to a user device.

Configuration commands to implement BPDU guard on interface gi1/14

6509E#config t
6509E(config)#int gi1/14
6509E(config-if) #spanning-tree bpduguard enable

Complete interface configuration after adding BPDU Guard on interface gi1/14

interface GigabitEthernet1/14
switchport
switchport access vlan 7
switchport mode access
spanning-tree bpduguard enable

Alternate Method of Enabling BPDU Guard with a Global Command on 6509E

**Configure “portfast” on all switchports that will be connected to user devices. This is a common practice for all non-switch connected interfaces. The global configuration command turns on “BPDU Guard” for all switch interfaces that have been configured for “portfast.”

Global configuration/Interface configuration commands to implement BPDU guard on interface gi1/14

6509E#config t
6509E(config)# spanning-tree portfast bpduguard default (Global Command)
6509E(config)#int gi1/14
6509E(config-if)# spanning-tree portfast (Interface Command)
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on GigabitEthernet1/14 but will only have effect when the interface is in a non-trunking mode.

Complete Global /Interface configuration after adding BPDU Guard on interface gi1/14

spanning-tree portfast bpduguard default (Global Command)
interface GigabitEthernet1/14
switchport
switchport access vlan 7
switchport mode access
spanning-tree portfast (Interface Command)

Spanning Tree Status after configuring portfast on 6509E

**Notice how configuring portfast on an interface changes its Type as “Edge P2P.”
6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 480
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Desg FWD 19 128.14 P2p Edge < Hacker PC Eth1 / Portfast changes type of interface
Gi1/48 Root FWD 19 128.48 P2p < Trunk connection to port Fa7/1 on 6509-svcmod
6509-svcmod “BPDU Guard” Configuration

BPDU Guard - Interface Configuration on 6509-svcmod

**Configure/enable BPDU guard on every interface that is connected to a user device.


Configuration commands to implement BPDU guard on interface fa7/3

6509-svcmod#config t
6509-svcmod(config)#int fa7/3
6509-svcmod(config-if)# spanning-tree bpduguard enable

Complete interface configuration after adding BPDU Guard on interface fa7/3

interface FastEthernet7/3
switchport
switchport access vlan 7
switchport mode access
no ip address
spanning-tree bpduguard enable

Alternate Method of Enabling BPDU Guard with a Global Command on 6509-svcmod

**Configure “portfast” on all switchports that will be connected to user devices This is a common practice for all non-switch connected interfaces. The global configuration command turns on “BPDU Guard” for all switch interfaces that have been configured for “portfast.”

Global configuration/Interface configuration commands to implement BPDU guard on interface fa7/3

6509-svcmod#config t
6509-svcmod(config)# spanning-tree portfast bpduguard default (Global Command)
6509-svcmod(config)#int fa7/3
6509-svcmod(config-if)# spanning-tree portfast (Interface Command)
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet7/3 but will only have effect when the interface is in a non-trunking mode.
Complete Global /Interface configuration after adding BPDU Guard on interface fa7/3
spanning-tree portfast bpduguard default (Global Command)
interface FastEthernet7/3
switchport
switchport access vlan 7
switchport mode access
no ip address
spanning-tree portfast (Interface Command)

Spanning Tree Status after configuring portfast on 6509-svcmod

**Notice how configuring portfast on an interface changes its Type as “Edge P2P.”

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim PC
Fa7/3 Desg FWD 19 128.771 Edge P2p < Hacker PC Eth2 / Portfast changes “Type” of interface
Figure 8. Mitigation: BPDU Guard/Bridging NIC’s with Ettercap

The above diagram depicts Stage II of the STP MiTM attack where a hacker’s PC running Ettercap bridges the connections from the dual NICs that are attached to both of the Cisco Catalyst 6500s. The intended result of bridging the connections through the hacker’s PC is to make it appear to the switches that a cable has been connected between them. The switches don’t realize that a hacker’s PC sits between their connection and is capable of sniffing all traffic.

You will notice from the above diagram that since both switches are forwarding BPDUs that are being received by the other switch, the switch ports are immediately placed into an “err-disabled” state. The end result of an interface in an “err-disabled” state is that the Interface is “down” and the line protocol is “down” until an administrator does a “shutdown” and then “no shutdown” to re-enable the interface. This attack has been stopped before it could reach Stage III—where “Yersinia” would be used to generate Superior Config BPDUs claiming the Root Bridge Status.

BPDU Guard Mitigation/Recovery Results

6509E “BPDU Guard” Mitigation Results

Console Message on Cisco Catalyst 6509E after bridging connection with Ettercap

**Console message immediately fires upon bridging connections as port Gi1/14 receives a BPDU from port Fa7/3 on switch 6509-svcmod.

Console Messages on the 6509E after bridging connection with Ettercap

Jul 23 19:51:36.248: %SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet1/14 with BPDU Guard enabled. Disabling port.
Jul 23 19:51:36.248: %PM-SP-4-ERR_DISABLE: bpduguard error detected on Gi1/14, putting Gi1/14 in err-disable state

STP Status on 6509E after bridging connection with Ettercap

**Notice in the below output that once the Gi1/14 has been disabled that it no longer appears in the STP table.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 480
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/48 Root FWD 19 128.48 P2p < Trunk connection to port Fa7/1 on 6509-svcmod

Interface Gi1/14 status on 6509E after bridging connection with Ettercap

**A “show interface” command reveals that the interface is non-operational.

6509E#sh int gi1/14
GigabitEthernet1/14 is down, line protocol is down (err-disabled)

6509E “BPDU Guard” Recovery

Administrator actions to recover from err-disabled state on 6509E

**Port must be Administrator enabled to become functional.
6509E(config)#int gi1/14
6509E(config-if)#shutdown
6509E(config-if)#no shutdown
6509E(config-if)#exit

6509-svcmod “BPDU Guard” Mitigation Results

Console Message on 6509-svcmod after bridging connecton with Ettercap

**Console message immediately fires upon bridging connections as port Fa7/3 receives a BPDU from Port Gi1/14 on switch Cisco Catalyst 6509E.

Console Messages on 6509-svcmod

6d23h: %SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet7/3 with BPDU Guard enabled. Disabling port.
6d23h: %PM-SP-4-ERR_DISABLE: bpduguard error detected on Fa7/3, putting Fa7/3 in err-disable state

STP Status on 6509-svcmod after bridging connection with Ettercap

**Notice in the below output that once the Fa7/3 has been disabled, it no longer appears in the STP table.

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk Connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim PC

Interface Fa7/3 Status on 6509-svcmod after bridging connection with Ettercap

**A partial display of the show interface command for Fa7/3 shows that its status is down.
6509-svcmod#sh int fa7/3
FastEthernet7/3 is down, line protocol is down (err-disabled)

6509-svcmod “BPDU Guard” Recovery

Administrator actions to recover from err-disabled state on 6509-svcmod

**Port must be Administrator enabled to become functional.
6509-svcmod(config)#int fa7/3
6509-svcmod(config-if)#shutdown
6509-svcmod(config-if)#no shutdown
6509-svcmod(config-if)#exit

Root Guard Mitigation

Figure 9. Mitigation: Root Guard Configuration/Dual NIC Connection

The above diagram depicts Stage I of the MiTM attack where a hacker’s PC with dual NICs attaches to switch ports that belong to VLAN 7 on both Cisco Catalyst 6500 switches. This time, however, “Root Guard” is enabled on both switch ports (Gi1/14 and Fa7/3) with the interface configuration command “spanning-tree guard root.”

You will notice in the above diagram that switches transmit BPDUs to determine whether they are connected to another switch that is participating in STP. Workstations don’t participate in STP and don’t transmit BPDUs. Since the switches aren’t receiving superior BPDUs (they aren’t receiving any BPDUs) on their PC connected switch ports (Gi1/14 and Fa7/3), neither of the ports will transition to a “blocking/root-inconsistent” state. Both switch ports assume a “Designated Port” Role with a status of “Forwarding” which is normal for a switch port connected to a user device that never receives an incoming BPDU.

The “Root Guard” feature (when enabled on a switch port) prevents that switch port from becoming a “Root Port” or a “Blocked” port. A “Blocked” port is a redundant connection that has received a superior BPDU but doesn’t have the best path to the “Root Bridge” (Root Port). There can be only one “Root Port” per bridge. Since there can only be one “Root Port” per bridge, any other switch port on the bridge that receives a superior BPDU (indicating a redundant path to the “Root Bridge”) is blocked.

Root Guard Configuration

6509E “Root Guard” Configuration

Root Guard - Interface Configuration on 6509E

**Configure/enable Root Guard on ports/interfaces that are used to interconnect to other switches that you don’t want to assume the “Root Port” role. You want them to remain in the role of a “Designated Port.”

Configuration commands to implement Root Guard on interface gi1/14

6509E#confit t
6509E(config)#int gi1/14
6509E(config-if)# spanning-tree guard root

Oct 30 12:29:27.248: %SPANTREE-SP-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port GigabitEthernet1/14.

Complete interface configuration after adding Root Guard on interface gi1/14

interface GigabitEthernet1/14
switchport
switchport access vlan 7
switchport mode access
spanning-tree guard root

6509-svcmod “Root Guard” Configuration

Root Guard - Interface Configuration on 6509-svcmod

**Configure/enable Root Guard on ports/interfaces that are used to interconnect to other switches that you don’t want to assume the “Root Port” role. You want them to remain in the role of a “Designated Port.”

Configuration commands to implement Root Guard on interface fa7/3

6509-svcmod#config t
Enter configuration commands, one per line. End with CNTL/Z.
6509-svcmod(config)#int fa7/3
6509-svcmod(config-if)#spanning-tr
6509-svcmod(config-if)# spanning-tree guard root
2d17h: %SPANTREE-SP-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet7/3.

Complete interface configuration after adding Root Guard on interface fa7/3

interface FastEthernet7/3
switchport
switchport access vlan 7
switchport mode access
no ip address
spanning-tree guard root
Figure 10. Mitigation: Root Guard/Bridging NIC’s with Ettercap

The above diagram depicts Stage II of the STP MiTM attack where a hacker’s PC running Ettercap bridges the connections from the dual NICs that are attached to both of the Cisco Catalyst 6500s. The intended result of bridging the connections through the hacker’s PC is to make it appear to the switches that a cable has been connected between them. The switches don’t realize that a hacker’s PC sits between their connection and is capable of sniffing all traffic.

You will notice from the above diagram that both switches are forwarding BPDUs that are being received by the other switch. Port Gi1/14 only, however, is placed into a “blocking/root-inconsistent” state. Port Gi1/14 is receiving a superior BPDU from port Fa7/3 that during a normal STP process would place it in a “blocked” port state (as it represents a redundant connection). Remember that only one “Root Port” is allowed per bridge. A “Root Guard” enabled switch port will not allow that port to become either a “Root Port” or a “Blocked” port. Notice in the above diagram that the Gi1/14 interface is up, line protocol is up despite the fact that the STP table shows that Gi1/14 is “blocking/root-inconsistent.”

Root Guard Mitigation Results – Stage II

6509E “Root Guard” Mitigation Results – Stage II

Console Message on 6509E after bridging connection with Ettercap

**Console message fires immediately upon bridging connections as port Gi1/14 receives a superior BPDU from port Fa7/3 on switch 6509-svcmod.

Console Messages on the 6509E when Ettercap Bridges Attack PC’s interfaces

Oct 30 12:32:04.268: %SPANTREE-SP-2-ROOTGUARD_BLOCK : Root guard blocking port GigabitEthernet1/14 on VLAN0007.

STP Status on 6509E after bridging connection with Ettercap

**The results of a “show spanning-tree vlan 7” command reveal that the Gi1/14 port is in a “root-inconsistent” STP state and is no longer forwarding data.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 480
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Desg BKN*19 128.14 P2p *ROOT_Inc < Hacker PC Eth1 / port received a superior bpdu
Gi1/48 Root FWD 19 128.48 P2p < Trunk connection to port Fa7/1 on 6509-svcmod

Interface Gi1/14 status on 6509E after bridging connection with Ettercap

**Notice in the below partial results of the “show interface” command that even though the Gi1/14 port is no longer forwarding data that the status of the interface is “interface is up, line protocol is up.”

6509E#sh int gi1/14
GigabitEthernet1/14 is up, line protocol is up (connected)

6509-svcmod “Root Guard” Mitigation Results – Stage II

Console Message on 6509-svcmod after bridging connection with Ettercap

**No console message is fired as a superior BPDU is never received on port Fa7/3.

STP Status on 6509-svcmod after bridging connection with Ettercap

**Notice in the below “show spanning-tree vlan 7” output that port Fa7/3 has been unaffected by bridging the NICs with Ettercap.

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p <Trunk connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim PC
Fa7/3 Desg FWD 19 128.771 P2p < Hacker PC Eth2 / this port has remained in a forwarding state

Interface Fa7/3 status on 6509-svcmod after bridging connection with Ettercap

**The “show interface” command on the Fa7/3 interface shows the same “interface up, line protocol up” status as the Gi1/14 port on switch 6509E.

6509-svcmod#sh int fa7/3
FastEthernet7/3 is up, line protocol is up (connected)
Figure 11. Mitigation: Root Guard/Yersinia Attempts Root Bridge Takeover

The above diagram depicts Stage III of the STP MiTM attack where a hacker’s PC running both Ettercap (bridging NICs) and now Yersinia (generating fraudulent config BPDUs) masquarades as a switch and starts transmitting “Config BPDUs” with a lower MAC Address than the “Root Bridge” in an attempt to claim the “Root Bridge” role. Yersinia has learned which switch is the current “Root Bridge” and what to modify in its generated Config BPDU to claim the “Root Bridge” role.

You will notice from the above diagram that port Gi1/14 on switch 6509E remains in a “blocking/root-consistent” state because now instead of receiving a superior BPDU from switch 6509-svcmod it is receiving a superior BPDU from the hacker’s PC. Port Fa7/3, however, on switch 6509-svcmod has transitioned to a “blocking/root-inconsistent” state as it is now receiving a superior BPDU from the hacker’s PC. The “Root Guard” feature configured on both of these ports is keeping those interfaces from transitioning to a “Root Port” role (port with the best path to the “Root Bridge”).

Root Guard Mitigation/Recovery Results – Stage III

6509E “Root Guard” Mitigation Results – Stage III

Console Message on 6509E after Yersinia attempts “Root Bridge” takeover

**Console message does not fire as port Gi1/14 has been in a “blocking/root-inconsistent” state since Stage II of the attack when Ettercap bridged the dual NICs. The Gi1/14 port was receiving a superior BPDU from port Fa7/3 on switch 6509-svcmod. In Stage III, the hacker’s PC running Yersinia has now crafted a superior BPDU and is transmitting it towards port Gi1/14. Port Gi1/14 is now receiving a superior BPDU from the hackers PC so the port remains in a “blocking/root- inconsistent” state and doesn’t generate an additional console message.

STP Status on 6509E after Yersinia attempts “Root Bridge” takeover

**The results of a “show spanning-tree vlan 7” command reveal that the Gi1/14 port remains in a “root-inconsistent” STP state and continues not to forward data.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 480
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Desg BKN*19 128.14 P2p *ROOT_Inc < port still receiving a superior bpdu
Gi1/48 Root FWD 19 128.48 P2p <Trunk connection to port Fa7/1 on 6509-svcmod

Interface Gi1/14 status on 6509E after Yersinia attempts “Root Bridge” takeover

**Notice in the below partial results of the “show interface” command that the Gi1/14 port continues not to forward data (blocking/root-inconsistent) and yet the status of the interface remains “interface is up, line protocol is up.”

6509E#sh int gi1/14
GigabitEthernet1/14 is up, line protocol is up (connected)

6509E “Root Guard” Recovery

Recovery from “blocking/root-inconsistent” state on 6509E

**Recovery is automatic when using the “Root Guard” feature as port Gi1/14 will recover without administrator intervention as soon as it stops receiving superior BPDUs that would force it to become either the “Root Port” or a “Blocked Port.” In this particular case we have stopped Ettercap from bridging the dual NICs, and we have stopped Yersinia from generating superior “Config BPDUs.”

Console Messages on the 6509E when stopping Ettercap and Yersinia attacks

Oct 30 12:45:05.340: %SPANTREE-SP-2-ROOTGUARD_UNBLOCK: Root guard unblocking port GigabitEthernet1/14 on VLAN0007.

STP Status on 6509E after Ettercap and Yersina attacks are stopped

** The results of a “sh spanning-tree vlan 7” command reveal that the Gi1/14 port has recovered and that it has returned to a “Designated Port” role with a “Forwarding” STP status. This is the same role and STP status that it had prior to the attack—prior to the Hacking PC bridging NICs with Ettercap or transmitting superior BPDUs with Yersinia.

6509E#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
Cost 19
Port 48 (GigabitEthernet1/48)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 00d0.0139.dc07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 480

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/14 Desg FWD 19 128.14 P2p < Hackers PC Eth1
Gi1/48 Root FWD 19 128.48 P2p <Trunk connection to port Fa7/1 on 6509-svcmod

6509-svcmod “Root Guard” Mitigation Results

Console Message on 6509-svcmod after Yersinia attempts “Root Bridge” takeover

**Console message fires immediately upon port Fa7/3 receiving a superior BPDU from the hacker’s PC that is attempting to claim the “Root Bridge” Role.

Console Message when Yersinia attempts to claim root on interface fa7/3

2d18h: %SPANTREE-SP-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet7/3 on VLAN0007.

STP Status on 6509-svcmod after Yersinia attempts “Root Bridge” takeover

** The results of a “show spanning-tree vlan 7” command reveal that the Fa7/3 port is now in a “root-inconsistent” STP state and is no longer forwarding data.

6509-svcmod#sh spanning-tree vlan 7
VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk Connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim PC
Fa7/3 Desg BKN*19 128.771 P2p *ROOT_Inc <Hackers PC Eth2

Interface Fa7/3 status on 6509-svcmod after Yersinia attempts “Root Bridge” takeover

** Notice in the below partial results of the “show interface” command that even though the Fa7/3 port is no longer forwarding data that the status of the interface is “interface is up, line protocol is up.”

6509-svcmod#sh int fa7/3
FastEthernet7/3 is up, line protocol is up (connected)

6509-svcmod “Root Guard” Recovery

Recovery from “blocking/root-inconsistent” state on 6509-svcmod

**Recovery is automatic when using the “Root Guard” feature as port Fa7/3 will recover without administrator intervention as soon as it stops receiving superior BPDUs that would force it to become either the “Root Port” or a “Blocked Port.” In this particular case we have stopped Ettercap from bridging the dual NICs, and we have stopped Yersinia from generating superior “Config BPDUs.”

Console Messages on the 6509-svcmod when stopping Ettercap and Yersinia attacks

2d18h: %SPANTREE-SP-2-ROOTGUARD_UNBLOCK: Root guard unblocking port FastEthernet7/3 on VLAN0007.

STP Status on 6509-svcmod after Ettercap and Yersina attacks are stopped

**The results of a “show spanning-tree vlan 7” command reveal that the Fa7/3 port has recovered and that it has returned to a “Designated Port” role with a “Forwarding” STP status. This is the same role and STP status that it had prior to the attack—prior to the hacker’s PC transmitting superior BPDUs with Yersinia.

6509-svcmod#sh spanning-tree vlan 7

VLAN0007
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0009.7b62.1087
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768
Address 0009.7b62.1087
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa7/1 Desg FWD 19 128.769 P2p < Trunk Connection to port Gi1/48 on 6509E
Fa7/2 Desg FWD 19 128.770 P2p < Victim PC
Fa7/3 Desg FWD 19 128.771 P2p <Hackers PC Eth2

Mitigation Summary

In summary, the “BPDU Guard” feature is more comprehensive in its protection when configured on an interface as it will “err-disable” the interface on the reception of any STP BPDU packet received. The “Root Guard” feature, in contrast, will place the port in an STP root-inconsistent/blocking state as long as a superior BPDU is received on the interface that would normaly cause that port to change its STP role from that of a “Designated Port” to that of a “Root Port.” It will not take any action whatsoever on a TCN BPDU or Configuration BPDU that is not superior and is therefore still succeptable to certain DOS attacks that can be generated by the hacking application used in this test scenario (Yersinia). Please see the Table 4 for a list of Yersinia STP attacks and what action is taken dependent on the Mitigation Technique deployed.

The bolded attack in Table 3 is the only attack launched by Yersinia in this test scenario. The other attacks, however, could be easily launched by following the steps outlined in this document that lead you up to launching attacks from Yersinia. Ettercap would not be required to launch any of the below attacks.

Table 4.

Yersinia Attacks BPDU Guard Root Guard

Sending Conf BPDU/single packet Stop

Sending TCN BPDU/single packet Stop

Sending Conf BPDUs/continuous (DOS) Stop Stop

Sending TCN BPDUs/continuous (DOS) Stop

Claiming Root Role/continuous Stop Stop

Claiming Other Role/continuous Stop

Claiming Root Role with MiTM N/A N/A

** It might be noted from Table 4 that the “Root Guard” feature doesn’t stop a single “Conf BPDU” but that it does appear to stop the continuous flow of “Config BPDUs.” The continuous flow of “Config BPDUs” creates a random set of Bridge IDs of which some are superior.

** The “Claiming Root Role with MiTM” attack was non-functional and didn’t produce a single BPDU. In some instances it crashes the Yersinia application when launched.

Switch Configurations without Mitigation

Switch 6509E

upgrade fpd auto
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service counters max age 5
!
hostname 6509E
!
boot-start-marker
boot system flash disk0:
boot system disk0:s72033-adventerprisek9-mz.122-33.SXI1
boot-end-marker
!
security passwords min-length 1
logging buffered 4096 debugging
enable password cisco
!
username Kevin privilege 15 password 0 donk
username Jeff privilege 15 password 0 cornbread
no aaa new-model
call-home
alert-group configuration
alert-group diagnostic
alert-group environment
alert-group inventory
alert-group syslog
profile "CiscoTAC-1"
no active
no destination transport-method http
destination transport-method email
destination address email callhome@cisco.com
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
subscribe-to-alert-group diagnostic severity minor
subscribe-to-alert-group environment severity minor
subscribe-to-alert-group syslog severity major pattern .”*"
subscribe-to-alert-group configuration periodic monthly 4 12:30
subscribe-to-alert-group inventory periodic monthly 4 12:15
ip subnet-zero
!
!
!
no ip dhcp snooping information option
no ip domain-lookup
vtp domain CISCO
vtp mode transparent
mls netflow interface
no mls flow ip
mls cef error action reset
!
!
!
!
!
!
!
!
!
!
redundancy
keepalive-enable
mode sso
main-cpu
auto-sync running-config
!
spanning-tree mode pvst
diagnostic bootup level minimal
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
errdisable recovery cause udld
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause l2ptguard
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause mac-limit
errdisable recovery cause unicast-flood
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
errdisable recovery cause link-monitor-failure
errdisable recovery cause oam-remote-failure
errdisable recovery cause loopback
errdisable recovery interval 30
fabric timer 15
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
vlan 7,10,20
!
vlan 50
remote-span
!
vlan 255
!
!
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet1/3
no ip address
shutdown
!
interface GigabitEthernet1/4
no ip address
shutdown
!
interface GigabitEthernet1/5
no ip address
shutdown
!
interface GigabitEthernet1/6
no ip address
shutdown
!
interface GigabitEthernet1/7
no ip address
shutdown
!
interface GigabitEthernet1/8
no ip address
shutdown
!
interface GigabitEthernet1/9
no ip address
shutdown
!
interface GigabitEthernet1/10
no ip address
shutdown
!
interface GigabitEthernet1/11
no ip address
shutdown
!
interface GigabitEthernet1/12
no ip address
shutdown
!
interface GigabitEthernet1/13
no ip address
shutdown
!
interface GigabitEthernet1/14
description *** Lenovo VMware, Ubuntu Eth1 (Linksys 300M) ***
switchport
switchport access vlan 7
switchport mode access
!
interface GigabitEthernet1/15
switchport
shutdown
!
interface GigabitEthernet1/16
no ip address
shutdown
!
interface GigabitEthernet1/17
no ip address
shutdown
!
interface GigabitEthernet1/18
no ip address
shutdown
!
interface GigabitEthernet1/19
no ip address
shutdown
!
interface GigabitEthernet1/20
no ip address
shutdown
!
interface GigabitEthernet1/21
no ip address
shutdown
!
interface GigabitEthernet1/22
no ip address
shutdown
!
interface GigabitEthernet1/23
no ip address
shutdown
!
interface GigabitEthernet1/24
no ip address
shutdown
!
interface GigabitEthernet1/25
no ip address
shutdown
!
interface GigabitEthernet1/26
no ip address
shutdown
!
interface GigabitEthernet1/27
no ip address
shutdown
!
interface GigabitEthernet1/28
no ip address
shutdown
!
interface GigabitEthernet1/29
no ip address
shutdown
!
interface GigabitEthernet1/30
no ip address
shutdown
!
interface GigabitEthernet1/31
no ip address
shutdown
!
interface GigabitEthernet1/32
no ip address
shutdown
!
interface GigabitEthernet1/33
no ip address
shutdown
!
interface GigabitEthernet1/34
no ip address
shutdown
!
interface GigabitEthernet1/35
no ip address
shutdown
!
interface GigabitEthernet1/36
no ip address
shutdown
!
interface GigabitEthernet1/37
no ip address
shutdown
!
interface GigabitEthernet1/38
no ip address
shutdown
!
interface GigabitEthernet1/39
no ip address
shutdown
!
interface GigabitEthernet1/40
no ip address
shutdown
!
interface GigabitEthernet1/41
no ip address
shutdown
!
interface GigabitEthernet1/42
no ip address
shutdown
!
interface GigabitEthernet1/43
no ip address
shutdown
!
interface GigabitEthernet1/44
no ip address
shutdown
!
interface GigabitEthernet1/45
no ip address
shutdown
!
interface GigabitEthernet1/46
no ip address
shutdown
!
interface GigabitEthernet1/47
no ip address
shutdown
!
interface GigabitEthernet1/48
switchport
switchport trunk encapsulation isl
switchport mode trunk
!
interface GigabitEthernet5/1
no ip address
shutdown
!
interface GigabitEthernet5/2
switchport
switchport access vlan 255
switchport mode access
media-type rj45
link debounce
!
interface Vlan1
no ip address
shutdown
!
interface Vlan7
ip address 10.1.0.1 255.255.255.0
!
interface Vlan255
description *** Take this out after testing is complete ***
ip address 172.18.176.198 255.255.255.0
!
router eigrp 100
network 10.1.0.0 0.0.0.255
network 172.18.176.0 0.0.0.255
no auto-summary
!
ip classless
!
!
no ip http server
no ip http secure-server
!
!
!
control-plane
!
!
dial-peer cor custom
!
!
!
alias exec sidsb show ip dhcp snooping binding
alias exec smac show mac address-table count vlan 7
alias exec cmac clear mac address-table dynamic vlan 7
alias exec smacall show mac address-table count
alias exec dhcps show ip dhcp server statistics
alias exec sarp show arp
!
line con 0
exec-timeout 0 0
line vty 0 4
session-timeout 800
password cisco
login
length 0
transport preferred none
transport input all
transport output none
line vty 5 15
login
transport input lat pad udptn telnet rlogin ssh
!
scheduler process-watchdog terminate
scheduler switch allocate 1000 1000
scheduler allocate 400 100
mac-address-table limit vlan 7 maximum 100
mac-address-table aging-time 480
!
end

Switch 6509-svcmod

upgrade fpd auto
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service counters max age 10
!
hostname 6509-svcmod
!
boot system disk0:s72033-adventerprisek9-mz.122-33.SXI1
!
no aaa new-model
svclc module 3 vlan-group 1
firewall multiple-vlan-interfaces
firewall module 3 vlan-group 1
firewall vlan-group 1 255
ip subnet-zero
!
!
!
ipv6 mfib hardware-switching replication-mode ingress
vtp mode transparent
mls ip slb purge global
mls ip multicast flow-stat-timer 9
no mls flow ip
no mls flow ipv6
no mls acl tcam share-global
mls cef error action freeze
!
!
!
!
!
!
!
!
redundancy
mode sso
main-cpu
auto-sync running-config
!
spanning-tree mode pvst
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
fabric timer 15
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
vlan 7
name SEresidencytesting
!
vlan 8
name ORLDFL8
!
vlan 9
name Parking_Place
!
vlan 10
name ORLDFL10
!
vlan 12
name ORLDFL12
!
vlan 18
name ORLDFL18
!
vlan 19
name ORLDFL19
!
vlan 21
name ORLDFL21
!
vlan 25
name ORLDFL25
!
vlan 31
name ORLDFL31
!
vlan 42
name ORLDFL42
!
vlan 48
name ORLDFL48
!
vlan 51
name ORLDFL51
!
vlan 60
name ORLDFL60
!
vlan 255
!
vlan 256
name ORLDFL256
!
vlan 266
name ORLDFL266
!
vlan 269
name ORLDFL269
!
vlan 276
name ORLDFL276
!
vlan 300
name ORLDFL300
!
vlan 308
name ORLDFL308
!
vlan 318
name ORLDFL318
!
vlan 320
name ORLDFL320
!
vlan 334
!
vlan 361
name ORLDFL361
!
vlan 377
name ORLDFL377
!
vlan 378
name ORLDFL378
!
vlan 431
name ORLDFL431
!
vlan 441
name ORLDFL441
!
vlan 460
name ORLDFL460
!
vlan 471
name ORLDFL471
!
vlan 475
name ORLDFL475
!
vlan 550
name ORLDFL550
!
vlan 695
name ORLDFL695
!
vlan 805
name ORLDFL805
!
!
!
!
interface Port-channel1
switchport
switchport trunk encapsulation dot1q
no ip address
!
interface GigabitEthernet5/1
no ip address
shutdown
!
interface GigabitEthernet5/2
switchport
switchport access vlan 255
no ip address
media-type rj45
!
interface FastEthernet7/1
switchport
switchport trunk encapsulation isl
switchport mode trunk
no ip address
!
interface FastEthernet7/2
description *** Lenovo internal Gigabit Ethernet Adaptor (Victime PC) ***
switchport
switchport access vlan 7
switchport mode access
no ip address
!
interface FastEthernet7/3
description *** Lenovo VMware, Ubuntu Eth2 (Linksys 300M) ***
switchport
switchport access vlan 7
switchport mode access
no ip address
!
interface FastEthernet7/4
no ip address
shutdown
!
interface FastEthernet7/5
no ip address
shutdown
!
interface FastEthernet7/6
no ip address
shutdown
!
interface FastEthernet7/7
no ip address
shutdown
!
interface FastEthernet7/8
no ip address
shutdown
!
interface FastEthernet7/9
no ip address
shutdown
!
interface FastEthernet7/10
no ip address
shutdown
!
interface FastEthernet7/11
no ip address
shutdown
!
interface FastEthernet7/12
no ip address
shutdown
!
interface FastEthernet7/13
no ip address
shutdown
!
interface FastEthernet7/14
no ip address
shutdown
!
interface FastEthernet7/15
no ip address
shutdown
!
interface FastEthernet7/16
no ip address
shutdown
!
interface FastEthernet7/17
no ip address
shutdown
!
interface FastEthernet7/18
no ip address
shutdown
!
interface FastEthernet7/19
no ip address
shutdown
!
interface FastEthernet7/20
no ip address
shutdown
!
interface FastEthernet7/21
no ip address
shutdown
!
interface FastEthernet7/22
no ip address
shutdown
!
interface FastEthernet7/23
no ip address
shutdown
!
interface FastEthernet7/24
no ip address
shutdown
!
interface FastEthernet7/25
no ip address
shutdown
!
interface FastEthernet7/26
no ip address
shutdown
!
interface FastEthernet7/27
no ip address
shutdown
!
interface FastEthernet7/28
no ip address
shutdown
!
interface FastEthernet7/29
no ip address
shutdown
!
interface FastEthernet7/30
no ip address
shutdown
!
interface FastEthernet7/31
no ip address
shutdown
!
interface FastEthernet7/32
no ip address
shutdown
!
interface FastEthernet7/33
no ip address
shutdown
!
interface FastEthernet7/34
no ip address
shutdown
!
interface FastEthernet7/35
no ip address
shutdown
!
interface FastEthernet7/36
no ip address
shutdown
!
interface FastEthernet7/37
no ip address
shutdown
!
interface FastEthernet7/38
no ip address
shutdown
!
interface FastEthernet7/39
no ip address
shutdown
!
interface FastEthernet7/40
no ip address
shutdown
!
interface FastEthernet7/41
no ip address
shutdown
!
interface FastEthernet7/42
no ip address
shutdown
!
interface FastEthernet7/43
no ip address
shutdown
!
interface FastEthernet7/44
no ip address
shutdown
!
interface FastEthernet7/45
no ip address
shutdown
!
interface FastEthernet7/46
no ip address
shutdown
!
interface FastEthernet7/47
no ip address
shutdown
!
interface FastEthernet7/48
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
interface Vlan255
ip address 10.50.255.36 255.255.255.0
!
ip classless
ip route 192.168.181.0 255.255.255.0 10.50.255.1
!
no ip http server
!
!
tftp-server disk0:c6svc-mp.2-1-3.bin.gz
tftp-server disk0:c6svc-fwm-k9.4-0-2.bin
tftp-server disk0:asdm-6112f.bin
!
!
control-plane
!
!
!
dial-peer cor custom
!
!
!
!
line con 0
line vty 0 4
no login
transport input lat pad udptn telnet rlogin ssh acercon
line vty 5 15
login
transport input lat pad udptn telnet rlogin ssh acercon
!
no cns aaa enable
end

Appendix

Introduction to Ubuntu Install Guide for L2 Attack Tools

This appendix is intended for those users that are not familiar with the Ubuntu Linux OS and want to be able to quickly download and use the Layer 2 attack and monitoring tools—Ettercap, Yersinia, packETH and Wireshark—that are utilized throughout these series of Layer 2 attack whitepapers. The Synaptic Package Manager in Ubuntu is the GUI application for installing software packages in the dpkg format—file extensions of “.deb.” This dpkg format was the first Linux packaging to integrate dependency information—the Debian Package Mgmt system database tracks which software packages are installed, which version is installed, and other packages that it is dependent on. This allows you to automatically identify, download and install all dependent applications that are part of your original application installation selection. The Synaptic Package Manager by default will only point to those dpkg repositories that are supported by Ubuntu Linux. If you want the Synaptic Package Manager to point to repositories that are not supported by Ubuntu, you must add those repositories to /etc/apt/sources.list.

This appendix covers the complete installation of the Ettercap application, modification of its initial configuration file—parameter values that provide privilege level, rerouting capabilities, remote browser capabilities, etc to ettercap—and where and how to launch the application. The other L2 attack and monitoring tool installations—Yersinia, packETH and Wireshark—are not covered in their entirety as the process is similar. These applications do differ in where and how they are launched and the appendix will cover these unique differences in detail.

Listed below is a summary of the different attack scenario’s and which L2 attack tools were used:

STP MiTM (Vlan) —Yersinia, Ettercap, Wireshark

STP MiTM (ISL)—Yersinia, Ettercap, packETH, Wireshark

ARP MiTM—Ettercap, Wireshark

MAC Overflow—Ettercap, Wireshark

DHCP Consumption—Yersinia, Wireshark


Ettercap

Ettercap Installation via Synaptic Package Manager

Select “System>Administration>Synaptic Package Manager” to load Synaptic; the GUI application to download, install and remove applications on Ubuntu Linux.

Figure 12.

You will be required to enter your password to perform Administrative Tasks such as installing software.

Figure 13.


Type “ettercap” in the Quick Search Field and the Synaptic Package Manager will locate the application for installation.

Figure 14.

Select the “ettercap-gtk” application for the gui version of ettercap by left clicking your mouse on the application.

Figure 15.


Left click on “Mark for Installation.”

Figure 16.

Additional application dependencies have been identified. Mark this additional application for installation.

Figure 17.


Ettercap has been marked along with its application dependency on “ettercap-common.” Go ahead and hit “Apply” to install both applications.

Figure 18.

Hit “Apply” in the summary screen to confirm your installation selections.

Figure 19.


When your installation is complete, the “Changes applied” window will pop up. Close this window to proceed.

Figure 20.

Synaptic indicates the applications have been successfully installed by the filled green box next to the application.

Figure 21.


Modification of Ettercap initialization file “/etc/etter.conf”

We are going to use the terminal shell to modify the “/etc/etter.conf” file. Select “Applications>Accessories>Terminal“ to open a terminal window.

Figure 22.

When the terminal window opens, type “sudo gedit /etc/etter.conf” to open the file with the appropriate privilege to modify it. You will be prompted for the root password to continue.

Figure 23.


The “ec_uid” and “ec_gid” values both need to be changed to “0” to provide the appropriate privilege level to Ettercap upon execution. The default values are “65534.” Change these to “0” as depicted below.

Figure 24.

The “port_steal_send_delay” value needs to be changed to “1” microseconds. The default value is “2000” microseconds for the port steal send delay. We need to populate arp tables faster than Cisco’s default arp table timeout values can clear them.

Figure 25.


Comment out “#” the original remote browser command line and add the remote_browser command line as entered below—mozilla is replaced with firefox. This fixes the MiTM remote browsing plugin within ettercap. This enables us to view the same web pages as a victim in real time.

Figure 26.

Uncomment the iptables commands; remove the “#” symbol. This will allow you to reroute traffic when performing a MiTM attack on behalf of the gateway and the victim.

Figure 27.


When you have completed these modifications, hit the “save” tab at the top of the editor.

Figure 28.

Launching Ettercap

Ettercap can be launched from “Applications>System Tools” or you can right click on “ettercap” from “System Tools” and install a launcher to the desktop.

Figure 29.


Ettercap can now be launched from the Ubuntu Desktop.

Figure 30.

Double clicking on the Ettercap icon launches the following Ettercap application.

Figure 31.


Yersinia

Yersinia Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 11 to 21 to install the yersinia (Figure 32) application. The below figure depicts the currently installed application—as denoted by the green box next to the application.

Figure 32.

Launching Yersinia’s Graphical Interface

Yersinia must be launched from a terminal window. Click on “Applications>Accessories>Terminal” to open a terminal window.

Figure 33.

Give the terminal window root privilege by typing the command “sudo su” at the command prompt. You will be required to provide a root password. There are several different options to launch yersinia from the CLI—“-G “ for Graphical or “-I” for interactive. The “yersinia –G” option loads the Graphical version of Yersinia depicted in Figure 34.

Figure 34.

The default yersinia screen when using the Graphical option for launching the application.


Launching Yersinia’s Interactive Interface

To launch the Interactive interface of yersinia you must be using a full size terminal window. Make sure you maximize your terminal session before launching the application with the “-I” option.

Figure 35.

Once the window is maximized launch yersinia with the “-I” option from the CLI.

Figure 36.


If your window was not maximized, you will receive the error message depicted below.

Figure 37.


The initial dialog screen informs you that eth0 has been selected as the default interface. You have an option to load an additional Ethernet interface if desired or to change the default interface. Hit any key to proceed.

Figure 38.


Type a lower case “h” to pull up the help screen of available commands. This is just another interface for using yersinia. Our examples of L2 attacks all use the Graphical version of yersinia. This should be enough to get you going if you choose to use the Interactive interface to yersinia.

Figure 39.


packETH

packETH Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 12 to 21 to install the packETH (Figure 40) application. The below figure depicts the currently installed application—as denoted by the green box next to the application.

Figure 40.


Launching packETH

packETH must be launched from a terminal window. Click on “Applications>Accessories>Terminal“ to open a terminal window.

Figure 41.

Give the terminal window root privilege by typing the command “sudo su” at the command prompt. You will be required to provide a root password. Once you have root privilege, type “packeth” at the command prompt and hit enter.

Figure 42.


This is a partial view of the default window that appears for packETH upon launching. You will notice that this packet generator supports ver II, 802.3 and 802.1q frames.

Figure 43.


Wireshark

Wireshark Installation via Synaptic Package Manager

Follow the same process as outlined in Figures 12 to 21 to install the Wireshark (Figure 44) application. The below figure depicts the currently installed application—as denoted by the green box next to the application. You will note that the Wireshark application is dependent on “wireshark-common.” The Synaptic Package Manager will identify the dependency and prompt you to also install “wireshark-common.”

Figure 44.


Launching Wireshark

Wireshark can be launched from “Applications>Internet>Wireshark (as root)” by a single click or you can add the launcher to the desktop by right clicking on wireshark and then select “Add this launcher to desktop.” The Wireshark icon can be double clicked from the Desktop to launch the application. Launched application is depicted in Figure 45.

Figure 45.

Figure 46.