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

Transcription

1 STP MiTM Attack and L2 Mitigation Techniques on the Cisco Catalyst 6500 Authors: Kevin Lauerman, CCSP, CISSP Jeff King, CCIE 11873, CCSP, CISSP 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 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 (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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 1

2 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 / 00:00:00:00:00:01 (Bridge ID of the Root Bridge) Root Path Cost 0 Bridge Identifer / 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 97

3 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 97

4 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 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 97

5 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 Internal Gigabit Ethernet Adaptor (Victim PC) VMware Server Console Build 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 97

6 ** 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 97

7 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 E 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 b ** 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 b is a smaller value than switch 6509Es MAC address 00d dc Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 97

8 ** 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 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 E#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority < Default Cisco Priority Value 6509-svcmod Address b < This is the Bridge MAC Address for VLAN 7 on Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority < Default Cisco Priority Value Address 00d 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 P2p < Switchport to Eth1 on Unbuntu Vmware Station Gi1/48 Root FWD P2p < Trunk connection to port Fa7/1 on 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 97

9 6509E#sh spanning-tree bridge Hello Max Fwd Vlan Bridge ID Time Age Dly Protocol VLAN d dc ieee VLAN d dc ieee VLAN d dc0a ieee VLAN d dc ieee VLAN d dc ieee VLAN d dcff ieee Not complete Output 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 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority < Default Cisco Priority Address b < 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 < Default Cisco Priority Address b < 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 P2p < Trunk connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim Windows XP workstation 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 97

10 Fa7/3 Desg FWD 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 svcmod#sh spanning-tree bridge Hello Max Fwd Vlan Bridge ID Time Age Dly Protocol VLAN b ieee VLAN b ieee VLAN b 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 97

11 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 97

12 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 97

13 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 97

14 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 Fa7/3 Config BPDU Gi1/14 received from Root ID b = Root ID b Cost - 0 = Cost 0 Bridge ID b = Bridge ID b Port ID (Decimal Value) < Port ID (Decimal Value) 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 97

15 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 97

16 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 Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d 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 P2p < Ettercap Bridged to Fa7/3 on 6509-svcmod /Port has changed Its STP Port State to Blocking. Gi1/48 Root FWD P2p < Trunk connection to port Fa7/1 on 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 97

17 ** We will see in stage three of the attack that the hex respresentation for the Port ID on Port Fa7/1 is 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p < Trunk connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim Windows XP workstation Fa7/3 Desg FWD P2p < Ettercap Bridged to Gi1/14 on 6509E 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 97

18 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 97

19 Ettercap recognizes the two configured NICs and offers them as possible bridged connections. Start sniffing the bridged connection Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 97

20 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 97

21 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 97

22 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 b Hacker PC/Yersinia b 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) Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 97

23 Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 97

24 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 Address b < 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 Address 00d 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 P2p < Ubuntu Workstation Eth1 (New Root Port) Gi1/48 Altn BLK P2p <Original Trunk port is now blocking for VLAN Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 97

25 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 < Default Priority become root Address b < Yersinia generates a lower MAC address to Cost 19 Port 771 (FastEthernet7/3) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority < Default Priority Address b < 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 P2p <Trunk Port is Designated Port Fa7/2 Desg FWD P2p < Victim Windows XP workstation Fa7/3 Root FWD P2p <Ubuntu Workstation Eth2 (New Root Port) 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 97

26 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 97

27 6509-svcmod#sh spanning-tree bridge Hello Max Fwd VLAN Bridge ID Time Age Dly Protocol VLAN b <<VLAN ieee VLAN b <<VLAN 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 97

28 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 97

29 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 97

30 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 B621987, generated by Yersinia B Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 97

31 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 97

32 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 97

33 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 97

34 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 / no 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 97

35 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 97

36 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/ E#config t 6509E(config)#int gi1/ E(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 nonswitch 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/ E#config t 6509E(config)#spanning-tree portfast bpduguard default (Global Command) 6509E(config)#int gi1/ E(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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 97

37 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 Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d 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 P2p Edge < Hacker PC Eth1 / Portfast changes type of interface Gi1/48 Root FWD 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 97

38 Configuration commands to implement BPDU guard on interface fa7/ svcmod#config t 6509-svcmod(config)#int fa7/ 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 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 nonswitch 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/ svcmod#config t 6509-svcmod(config)# spanning-tree portfast bpduguard default Command) (Global 6509-svcmod(config)#int fa7/ svcmod(config-if)#spanning-tree portfast Command) (Interface %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 interface is in a non-trunking mode. have effect when the 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 spanning-tree portfast (Interface Command) 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 97

39 Spanning Tree Status after configuring portfast on 6509-svcmod **Notice how configuring portfast on an interface changes its Type as Edge P2P svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p < Trunk connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim PC Fa7/3 Desg FWD Edge P2p < Hacker PC Eth2 / Portfast changes Type of interface 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 97

40 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 and then no 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 97

41 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 Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d 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 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/ E(config-if)# 6509E(config-if)#no 6509E(config-if)#exit 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 97

42 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 errdisable 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p < Trunk Connection to port Gi1/48 on 6509E Fa7/2 Desg FWD 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 svcmod#sh int fa7/3 FastEthernet7/3 is down, line protocol is down (err-disabled) 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 97

43 6509-svcmod BPDU Guard Recovery Administrator actions to recover from err-disabled state on 6509-svcmod **Port must be Administrator enabled to become functional svcmod(config)#int fa7/ svcmod(config-if)# 6509-svcmod(config-if)#no 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 97

44 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/ E#confit t 6509E(config)#int gi1/ E(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/ svcmod#config t Enter configuration commands, one per line. End with CNTL/Z svcmod(config)#int fa7/ 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/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 97

45 Complete interface configuration after adding Root Guard on interface fa7/3 interface FastEthernet7/3 switchport switchport access vlan 7 switchport mode access 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 97

46 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 Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d 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* P2p *ROOT_Inc < Hacker PC Eth1 / port received a superior bpdu Gi1/48 Root FWD P2p < Trunk connection to port Fa7/1 on 6509-svcmod 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 97

47 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p <Trunk connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim PC Fa7/3 Desg FWD P2p < Hacker PC Eth2 / this port has remained in a forwarding state 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 97

48 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 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/rootinconsistent 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 ) Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 97

49 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 rootinconsistent STP state and continues not to forward data. 6509E#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d 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* P2p *ROOT_Inc < port still receiving a superior bpdu Gi1/48 Root FWD P2p <Trunk connection to port Fa7/1 on 6509-svcmod 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 97

50 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 Address b Cost 19 Port 48 (GigabitEthernet1/48) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address 00d dc07 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 97

51 Interface Role Sts Cost Prio.Nbr Type Gi1/14 Desg FWD P2p < Hackers PC Eth1 Gi1/48 Root FWD 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p < Trunk Connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim PC Fa7/3 Desg BKN* P2p *ROOT_Inc <Hackers PC Eth Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 97

52 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 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 svcmod#sh spanning-tree vlan 7 VLAN0007 Spanning tree enabled protocol ieee Root ID Priority Address b This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority Address b 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 P2p < Trunk Connection to port Gi1/48 on 6509E Fa7/2 Desg FWD P2p < Victim PC Fa7/3 Desg FWD P2p <Hackers PC Eth Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 97

53 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 Sending TCN BPDU/single packet Stop 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 53 of 97

54 boot-start-marker boot system flash disk0: boot system disk0:s72033-adventerprisek9-mz 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 destination address callhome@cisco.com destination address http 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 54 of 97

55 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 55 of 97

56 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 interface GigabitEthernet1/2 interface GigabitEthernet1/3 interface GigabitEthernet1/4 interface GigabitEthernet1/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 56 of 97

57 interface GigabitEthernet1/6 interface GigabitEthernet1/7 interface GigabitEthernet1/8 interface GigabitEthernet1/9 interface GigabitEthernet1/10 interface GigabitEthernet1/11 interface GigabitEthernet1/12 interface GigabitEthernet1/13 interface GigabitEthernet1/14 description *** Lenovo VMware, Ubuntu Eth1 (Linksys 300M) *** switchport 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 57 of 97

58 switchport access vlan 7 switchport mode access interface GigabitEthernet1/15 switchport interface GigabitEthernet1/16 interface GigabitEthernet1/17 interface GigabitEthernet1/18 interface GigabitEthernet1/19 interface GigabitEthernet1/20 interface GigabitEthernet1/21 interface GigabitEthernet1/22 interface GigabitEthernet1/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 58 of 97

59 interface GigabitEthernet1/24 interface GigabitEthernet1/25 interface GigabitEthernet1/26 interface GigabitEthernet1/27 interface GigabitEthernet1/28 interface GigabitEthernet1/29 interface GigabitEthernet1/30 interface GigabitEthernet1/31 interface GigabitEthernet1/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 59 of 97

60 interface GigabitEthernet1/33 interface GigabitEthernet1/34 interface GigabitEthernet1/35 interface GigabitEthernet1/36 interface GigabitEthernet1/37 interface GigabitEthernet1/38 interface GigabitEthernet1/39 interface GigabitEthernet1/40 interface GigabitEthernet1/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 60 of 97

61 interface GigabitEthernet1/42 interface GigabitEthernet1/43 interface GigabitEthernet1/44 interface GigabitEthernet1/45 interface GigabitEthernet1/46 interface GigabitEthernet1/47 interface GigabitEthernet1/48 switchport switchport trunk encapsulation isl switchport mode trunk interface GigabitEthernet5/1 interface GigabitEthernet5/2 switchport switchport access vlan 255 switchport mode access 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 61 of 97

62 media-type rj45 link debounce interface Vlan1 interface Vlan7 ip address interface Vlan255 description *** Take this out after testing is complete *** ip address router eigrp 100 network network 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 62 of 97

63 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 scheduler allocate mac-address-table limit vlan 7 maximum 100 mac-address-table aging-time 480 end 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 63 of 97

64 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 sxi1 no aaa new-model svclc module 3 vlan-group 1 firewall multiple-vlan-interfaces firewall module 3 vlan-group 1 firewall vlan-group 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 64 of 97

65 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 ORLDFL Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 65 of 97

66 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 ORLDFL Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 66 of 97

67 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 67 of 97

68 name ORLDFL695 vlan 805 name ORLDFL805 interface Port-channel1 switchport switchport trunk encapsulation dot1q interface GigabitEthernet5/1 interface GigabitEthernet5/2 switchport switchport access vlan 255 media-type rj45 interface FastEthernet7/1 switchport switchport trunk encapsulation isl switchport mode trunk interface FastEthernet7/2 description *** Lenovo internal Gigabit Ethernet Adaptor (Victime PC) *** switchport switchport access vlan 7 switchport mode access interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 68 of 97

69 description *** Lenovo VMware, Ubuntu Eth2 (Linksys 300M) *** switchport switchport access vlan 7 switchport mode access interface FastEthernet7/4 interface FastEthernet7/5 interface FastEthernet7/6 interface FastEthernet7/7 interface FastEthernet7/8 interface FastEthernet7/9 interface FastEthernet7/10 interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 69 of 97

70 interface FastEthernet7/12 interface FastEthernet7/13 interface FastEthernet7/14 interface FastEthernet7/15 interface FastEthernet7/16 interface FastEthernet7/17 interface FastEthernet7/18 interface FastEthernet7/19 interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 70 of 97

71 interface FastEthernet7/21 interface FastEthernet7/22 interface FastEthernet7/23 interface FastEthernet7/24 interface FastEthernet7/25 interface FastEthernet7/26 interface FastEthernet7/27 interface FastEthernet7/28 interface FastEthernet7/29 interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 71 of 97

72 interface FastEthernet7/31 interface FastEthernet7/32 interface FastEthernet7/33 interface FastEthernet7/34 interface FastEthernet7/35 interface FastEthernet7/36 interface FastEthernet7/37 interface FastEthernet7/38 interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 72 of 97

73 interface FastEthernet7/40 interface FastEthernet7/41 interface FastEthernet7/42 interface FastEthernet7/43 interface FastEthernet7/44 interface FastEthernet7/45 interface FastEthernet7/46 interface FastEthernet7/47 interface FastEthernet7/ Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 73 of 97

74 interface Vlan1 interface Vlan255 ip address ip classless ip route no ip http server tftp-server disk0:c6svc-mp bin.gz tftp-server disk0:c6svc-fwm-k 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 74 of 97

75 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 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 75 of 97

76 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 76 of 97

77 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 77 of 97

78 Left click on Mark for Installation. Figure 16. Additional application dependencies have been identified. Mark this additional application for installation. Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 78 of 97

79 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 79 of 97

80 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 80 of 97

81 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 81 of 97

82 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 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 82 of 97

83 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 83 of 97

84 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 84 of 97

85 Ettercap can now be launched from the Ubuntu Desktop. Figure 30. Double clicking on the Ettercap icon launches the following Ettercap application. Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 85 of 97

86 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 86 of 97

87 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 87 of 97

88 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 88 of 97

89 If your window was not maximized, you will receive the error message depicted below. Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 89 of 97

90 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 90 of 97

91 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 91 of 97

92 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 92 of 97

93 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 93 of 97

94 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, and 802.1q frames. Figure Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 94 of 97

95 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 95 of 97

96 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 96 of 97