CLARKSON UNIVERSITY. A Doctoral Dissertation. Ronny L. Bull. Department of Computer Science. Submitted in partial fulfillment of the requirements

Transcription

1 CLARKSON UNIVERSITY A CRITICAL ANALYSIS OF LAYER 2 NETWORK SECURITY IN VIRTUALIZED ENVIRONMENTS A Doctoral Dissertation By Ronny L. Bull Department of Computer Science Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy, Computer Science Fall 2016 Accepted by the Graduate School, Date, Dean

2 A CRITICAL ANALYSIS OF LAYER 2 NETWORK SECURITY IN VIRTUALIZED ENVIRONMENTS The undersigned have examined the dissertation entitled A Critical Analysis of Layer 2 Network Security in Virtualized Environments presented by Ronny L. Bull, a candidate for the degree of Doctor of Philosophy in Computer Science, and hereby certify that it is worthy of acceptance. Date Dr. Jeanna Matthews Dr. Christopher Lynch Dr. Yaoqing Liu Dr. Burak Kantarci Dr. John Marsh

3 ABSTRACT Cloud service providers offer their customers the ability to deploy virtual machines in a multi-tenant environment. These virtual machines are typically connected to the physical network via a virtualized network configuration. This could be as simple as a bridged interface to each virtual machine or as complicated as a virtual switch providing more robust networking features such as VLANs, QoS, and monitoring. In this research, I explore whether Layer 2 network attacks that work on physical switches apply to their virtualized counterparts by performing a systematic study across seven different virtual networking configurations using enterprise grade hypervisor environments. First, I used a malicious virtual machine to run a MAC flooding attack and evaluate the impact on co-resident virtual machines. Then I investigated the effects of using a malicious virtual machine to run a rogue DHCP server under multiple DHCP attack scenarios. After that, I evaluated each of the seven virtual network configurations against a series of VLAN hopping experiments, and finally looked at how effective ARP poisoning attacks are in virtualized networks by performing scripted Man-in-the-Middle attacks across every major hypervisor platform. In summary, it was found that some of the evaluated hypervisor platforms utilize virtualized networks that are more resilient to certain classes of Layer 2 attacks than others. However, no single environment proved to have the capability of mitigating every attack. iii

4 ACKNOWLEDGMENTS Special thanks go out to the following individuals, without their support this research would not have been possible: Dr. Jeanna Matthews (Clarkson University - Research advisor) Provost John Johnson (Utica College - Research funding and institutional support) Dr. John Marsh (SUNYIT - Research funding and institutional support) Christopher Urban (SUNYIT - Research funding and institutional support) Nick Merante (SUNYIT - Research equipment acquisition, and for letting me run malicious experiments on his network!) Micheal Moore (Harris Critical Networks - A good friend and mentor who diligently proof read every publication) Prof. John Cook (Herkimer College - For helping me find this path so many years ago!) Many thanks go out to all of the people that have helped make this project happen, especially to all of my student research assistants that helped with some of the grunt work! To my family, thank you for all of your support and patience throughout this process. iv

5 This work is dedicated to my late Grandmother Susan M. Dawidowicz who passed away January 13th, 2016 at the age of 92. She was an inspiration and a reminder that hard work and dedication are the keys to getting past any obstacle in life. v

6 TABLE OF CONTENTS LIST OF TABLES xii LIST OF FIGURES xiv 1 BACKGROUND AND RELATED WORK Introduction Related Work LAYER 2 NETWORKING Introduction Collision Domain vs. Broadcast Domain Common Layer 2 Networking Protocols IEEE Ethernet Address Resolution Protocol (ARP) Spanning Tree Protocol (STP) Virtual Local Area Networks (VLAN) Dynamic Host Configuration Protocol (DHCP) vi

7 2.4 Virtual Layer 2 Networking Options Bridging Switching Layer 2 Network Attacks Media Access Control (MAC) Attacks Dynamic Host Configuration Protocol (DHCP) Attacks Virtual Local Area Network (VLAN) Hopping Address Resolution Protocol (ARP) Spoofing Spanning Tree Protocol (STP) Attacks RESEARCH ENVIRONMENT Original Environment Upgraded Research Environment MAC FLOODING ATTACK Introduction Attack Methodology Results Linux 802.1d Bridged Interface Open vswitch Interface Open vswitch Interface vii

8 4.3.4 Citrix XenServer Microsoft Hyper-V Server 2008 R VMware vsphere (ESXi) free edition Summary of MAC Flooding Results Mitigation Techniques DHCP ATTACKS Introduction Attack Methodology Seeding Clients With a Poisoned DNS Server Providing Clients With an Invalid or Malicious Default Gateway Remote Execution of Code Malicious Extension of the ShellShock Proof of Concept Attack Results Mitigation Techniques SWITCH SPOOFING VLAN HOPPING ATTACK Introduction Attack Methodology Results Mitigation viii

9 7 DOUBLE-TAGGING VLAN HOPPING ATTACK Introduction Attack Methodology Results Mitigation ARP SPOOFING - MAN-IN-THE-MIDDLE ATTACK Introduction Attack Methodology Results Mitigation CONCLUSION 75 APPENDICES 88 A RESEARCH DEMO VIDEOS 89 B DHCP AND DNS SERVER CONFIGURATIONS 91 B.1 Legitimate DHCP Server /etc/hosts File B.2 Legitimate DHCP Server Configuration File B.3 Rogue DHCP Server /etc/hosts File B.4 Rogue DHCP Server Configuration File ix

10 C INITIAL SWITCH CONFIGURATIONS FOR VLAN HOPPING EXPERIMENTS 93 C.1 Cisco Port Switch C.2 Cisco Port Switch D SCRIPTS 96 D.1 MAC Flooding Attack Scripts D.1.1 TCPDump HTTP Traffic Sniffer D.1.2 GNUPlot Scripts for Latency Graphs D.2 Rogue DHCP Server Monitoring Scripts D.2.1 TCPDump DHCP Monitoring Script D.2.2 Python/Scapy Rogue DHCP Server Identification Script D.3 VLAN Hopping Attack and Monitoring Scripts D.3.1 TCPDump VLAN Traffic Monitoring Script D.3.2 VLAN Hopping Python Script D.4 ARP Poisoning Man-in-the-Middle Attack Scripts D.4.1 ARP Poisoning Python Script D.4.2 TCPDump PCAP Parser E MAC FLOODING PERFORMANCE EVALUATION DATA SETS 104 E.1 Gentoo/Xen Bridged E.2 Gentoo/Xen Open vswitch x

11 E.3 Citrix XenServer E.4 Microsoft Hyper-V (Standard Switch) E.5 Microsoft Hyper-V (Cisco Nexus 1000v) E.6 Proxmox E.7 VMWare vsphere ESXi E.8 Cisco 2950 Hardware Switch xi

12 LIST OF TABLES 3.1 Summary of the orignial test environment hardware New virtual machines added to each hypervisor platform for Layer 2 DHCP attack testing Summary of hypervisor platforms and virtual switch configurations installed to the new hardware MAC flooding attack results across seven test environments. indicates the platform was affected DHCP attack scenario results across seven test environments. indicates a successful attack Switch spoofing attack results across the seven virtual test environments and a physical control system. indicates the attack was successful Physical double-tagging attack scenario results across the seven virtual test environments. indicates that a frame was successfully sent from the physical attacking system to a target virtual machine located on VLAN 20 within the corresponding hypervisor environment Virtual double-tagging attack scenario results across the seven virtual test environments. indicates that a frame was successfully sent from the virtual attacking system to a target system located within a separate virtual network on VLAN xii

13 8.1 ARP Poisoning Man-in-the-Middle attack results across the seven virtual test environments. indicates the platform was affected Summary of all attack scenario results across the seven different test environments. indicates that the platform is vulnerable to the corresponding class of attacks xiii

14 LIST OF FIGURES 2.1 The Open Systems Interconnect (OSI) model. The solid line indicates the data path from the transmitter to the receiver, the dotted lines represent the logical connectivity between each of the seven layers on the sending and receiving sides An Ethernet Frame An Ethernet Frame with an Added 802.1Q VLAN Tag Dynamic Host Configuration Protocol process A basic bridge using a forwarding table to pass requests between two network segments A switch and its CAM table An Ethernet Frame. Switches just need to match the destination address from the frame to an entry in its CAM table in order to forward it on to the correct port A malicious virtual machine located on a multi-tenant virtual network A malicious virtual machine running macof to flood a virtual network with random MAC addresses and malformed packets xiv

15 4.2 Network diagram for MAC flooding attack scenarios Latency measured using the ping utility on a bridged virtual network during a MAC flooding attack. The attack was launched at ICMP request 61 and terminated at ICMP request A malicious virtual machine running macof on an Open vswitch virtual network and successfully sniffing HTTP traffic with Wireshark from another tenant virtual machine Latency comparisons against all tested platforms measured using the ping utility during a MAC flooding attack with a Cisco 2950 hardware switch used as a control. The attack was launched at ICMP request 61 and terminated at ICMP request Latency comparisons against all tested platforms measured using the ping utility during a MAC flooding attack with a Cisco 2950 hardware switch used as a control. The attack was launched at ICMP request 61 and terminated at ICMP request Box and whisker plot showing latency variations for each environment while being subjected to the MAC flooding attack Duplicate addressing within a broadcast domain due to the presence of a rogue DHCP server Presence of a poisoned DNS server on a network whose address is provided to clients associated with a rogue DHCP server Malicious virtual machine configured as a router on a network whose address is provided to clients as a default gateway when associated with a rogue DHCP server Malicious DHCP lease process leveraging ShellShock to issue the rm -rf / command using option xv

16 6.1 Attacker connects to free switch port and sends out DTP packet in order to establish a trunk link with the switch A trunk link is formed between the switch and the attacker s system The attacker can now send and receive traffic on all VLANs associated with the trunk link Switch spoofing control scenario using a physical Kali 2.0 system to perform a DTP attack on a physical Cisco 2950 switch in order to gain unauthorized access to virtual machines on restricted VLANs Switch spoofing scenario where the attack is generated from a virtual machine connected to a virtual switched environment that has a physical uplink to a Cisco 2950 switch in order to gain unauthorized access to other virtual machines located on restricted VLANs within other hypervisor environments Successful switch spoofing attack with Yersinia sh int status output indicating the successful conversion of the port to trunk mode sh int trunk output indicating the port is now set to trunking mode with 802.1q encapsulation Comparison of a standard Ethernet frame with frames containing 802.1Q single and double VLAN tags Network topology with two switches connected via a trunk link offering access to VLANs 1,2, and Double-tagged frame is sent on the network and reaches its destination on the second VLAN xvi

17 7.4 Double tagging scenario where the attack is generated from a physical Kali 2.0 system connected to a Cisco 2950 switch with a second Cisco 2950 switch located in between the first Cisco switch and the connected hypervisor environments Double tagging scenario where the attack is generated from a physical Kali 2.0 system connected to a Cisco 2950 switch in order to gain unauthorized access to virtual machines located on restricted VLANs within connected hypervisor environments Double tagging scenario where the attack is generated from a Kali 2.0 virtual machine within one of the connected virtual networks. A physical Cisco 2950 switch acts as the physical connectivity device located between each of the connected virtual networks ARP poisoning Man-in-the-Middle attack scenario diagram xvii

18 CHAPTER 1 BACKGROUND AND RELATED WORK 1.1 Introduction With the growing popularity of Internet-based cloud service providers, many businesses are turning to these services to host their mission critical data and applications. Cloud customers often deploy virtual machines to shared, remote, physical computing resources. Virtual machines running in cloud capacity are connected to the physical network via a virtualized network within the host environment. Typically, virtualized hosting environments will utilize either a bridged network interface or a virtualized switch such as Open vswitch (Pettit et al., 2010; Pfaff et al., 2009) for Xen and KVM based environments, or either the standard built-in virtual switch or the Cisco Nexus 1000V (Cisco Systems Inc., 2014b) series virtual switch for VMware vsphere and Microsoft Hyper-V environments. These virtual switches are designed to emulate their physical counterparts, however, the majority of them do not provide any of the Layer 2 protection mechanisms found in modern enterprise grade hardware switches. It is important for users of multi-tenant cloud services to understand how secure their network traffic is from other users of the same cloud services, especially given that virtual machines from many customers share the same physical resources. If another tenant can launch a Layer 2 network attack and capture all the network traffic flowing from and to their virtual machines, this poses a substantial security risk. By understanding which virtual switches are vulnerable to which attacks, users can 1

19 evaluate the workloads they run in the cloud, consider additional security mechanisms such as increased encryption and/or increased monitoring and detection of Layer 2 attacks. In this research, I present the results of a systematic study to evaluate the effects of MAC flooding, DHCP, VLAN hopping, and ARP poisoning attacks across five major hypervisor environments with seven different virtual network configurations. First, I provide some background information on the general network configuration options available to virtualized environments. I then introduce the test environment that was put together to perform the experiments, as well as discuss upgrades that were made to the environment as the research progressed. Detailed descriptions of the attack methodology used for each of the Layer 2 networking attack scenarios is presented along with the results of each attack scenario against the seven virtual network configurations. I also discuss mitigation strategies that could help to prevent each of the attacks from being successful. 1.2 Related Work The concept of virtualization has been the subject of many academic publications going back as early as 1997 when the idea of running multiple commodity operating systems simultaneously on a single multiprocessor system was first presented with Disco (Bugnion et al., 1997). In 2003 the Xen hypervisor was introduced (Barham et al., 2003) which proved to be a major contribution in the world of computing that facilitated the widespread adoption of virtualization technologies in data centers across the globe. Since then multiple hypervisor and cloud computing platforms have been developed, and many papers have been published evaluating either the performance or security of these environments. In terms of virtualization security many of the papers currently in publication focus on attempting to steal information from co-located clients by making use of side-channel attacks 2

20 (Zhang et al., 2012; Ristenpart et al., 2009) in order to extract information from the target system located on the same physical host. Varadarajan et al. (2012) describe a class of attacks which they refer to as resource freeing attacks which are able to modify the workload of a co-located target virtual machine in order to free up resources for the attacker s virtual machines to use. There have also been publications that provide details on methods that could be used in order to mitigate attacks that take advantage of vulnerabilities associated with sharing computing resources in a multi-tenant environment. Two papers in particular have introduced the idea of splitting up the hypervisor environment into multiple components instead of having a single virtual machine manager that controls everything. Zhang et al. (2011) propose the idea of adding a security monitor between the management domain and the user virtual machines. This monitor provides an additional layer of security and isolation when handling resource allocation and sharing (CPU, memory, storage, etc.) between client virtual machines. Colp et al. (2011) take the idea of breaking up the hypervisor further with the introduction of service virtual machines that separate the traditional virtual machine manager tasks into multiple isolated virtual machines, each performing a specific function. There has already been a substantial amount of work studying the vulnerability of physical networks to Layer 2 attacks (Cisco Systems Inc., 2002; Rouiller, 2015; Yeung et al., 2008; Altunbasak et al., 2005; Lauerman and King, 2010), but the impact on virtual networks has not received as much attention. This is beneficial in the fact that published research previously performed on physical networks can serve as a model for testing in virtual environments and comparisons can be made based upon the physical baselines. For instance, Yeung et al. (2008) provide an overview of the most popular Layer 2 networking attacks as well as descriptions of the tools used to perform them. This work was very helpful in identifying possible attack vectors that could be emulated within a virtualized environment. Altunbasak et al. (2005) also describe various attacks that can be performed on 3

21 local and metropolitan area networks, as well as the authors idea of adding a security tag to the Ethernet frame for additional protection. Cisco also published a white paper (Cisco Systems Inc., 2002) regarding VLAN security in their Catalyst series of switches. The paper discloses testing that was performed on the switches in August of 2002 by an outside security research which was acquired by Symantec in In the white paper, they discussed many of the same attacks that were mentioned by Yeung et al. (2008), however the authors also went into detail about best practices and mitigation techniques that could be implemented on the physical switches in order to prevent the attacks from being successful. The SANS Institute also published a paper entitled Virtual LAN Security: weaknesses and countermeasure (Rouiller, 2015) which provided detailed information on the different types of attacks that target virtual LANs and their effectiveness against physical switches. The paper is heavily based on work that was presented by a Cisco employee at the Blackhat conference in 2002 entitled Hacking Layer 2: Fun with Ethernet Switches (Convery, 2002), as well as the results provided in the Cisco white paper. Both the SANS Institute paper and the Blackhat briefing provide an abundance of information on the inner workings of common Layer 2 networking attacks that affect VLAN security such as switch spoofing, double-tagging, and MAC address flooding as well as mitigation tactics that can be put in place to prevent them from being successful within physical networks. The documents served as valuable points of reference during this research, especially when setting up and conducting similar experiments against multiple different enterprise grade virtual switching devices. 4

22 CHAPTER 2 LAYER 2 NETWORKING 2.1 Introduction The main purpose of a computer network is to allow multiple devices to efficiently communicate with each other over some form of transmission media. The establishment of communication channels and transmission of data over these networks typically happens at blinding speeds. This makes it very easy to take for granted the many processes and services that are working behind the scenes to facilitate the efficient transaction of information between two systems on a communications network. These processes have been generalized and represented in the Open Systems Interconnection (OSI) model (Figure 2.1), which is a theoretical model that illustrates what happens when two devices communicate on a computer network (Dean, 2013). The OSI model breaks up the processes involved in node-to-node communication into seven different layers; Application, Presentation, Session, Transport, Network, Data Link, and Physical. Each of the seven layers consists of a set of protocols that perform a specific set of functions related to the transmission of data at that particular point in the communication stream. When a system transmits data to another system on a network the communication path begins at the top of the OSI model at the Application layer on the sending system, flows down through the other six layers in order, leaves the computer s network 5

23 Figure 2.1: The Open Systems Interconnect (OSI) model. The solid line indicates the data path from the transmitter to the receiver, the dotted lines represent the logical connectivity between each of the seven layers on the sending and receiving sides. interface at the Physical layer, and is then sent across the network media to the intended destination. The receiving system intercepts the transmission at the Physical layer and then sends it up through the next six layers in order, from bottom to top, until it reaches the Application layer where protocols exist that interact with the programs that are expecting the data. As the data flows down through the OSI model on the transmitting system information is added at each layer in the form of headers and sometimes trailers. This information is meant to be interpreted on the receiving system at the corresponding layer in the OSI model. As the data moves down through the sending system this extra information is encapsulated at each new layer until the data and all of the corresponding headers become a packet at the network layer. This is where the logical network information is added to the data which consists of the source and destination IP addresses. The next step in the process 6

24 is the Data Link layer (Layer 2), which is where the focus of this research lies. At this layer the packet is now encapsulated into a frame that is specific to the physical media that the information will be transmitted across. The frame header contains the physical addressing information for the sending and receiving systems in the form of a Media Access Control (MAC) address. This address consists of a unique 48-bit hexadecimal number that is burned into the network card at manufacture time. Once the frame is created it is sent down to the Physical layer and transmitted across the network in the form of light pulses, radio waves, or electrical signals. When the data reaches the receiver the frame is de-encapsulated at the data link layer and pushed up through the rest of the layers which further de-encapsulate the packet in order to read the header information that is pertinent to that specific layer. This process repeats until the Application layer is reached and the data is passed on to the requesting program. Since the focus of this research work is on vulnerabilities in Data Link layer protocols and devices, the other six layers of the OSI model are considered out of scope and will not be discussed in detail. However it is important to recognize that each of these layers consist of sets of protocols with their own vulnerabilities that are worth exploring against virtual networks in future research endeavors. The rest of this chapter will provide background information and details on common Layer 2 networking concepts, devices, protocols, and attacks. 7

25 2.2 Collision Domain vs. Broadcast Domain Layer 2 networking relies on transmitting and receiving frames between inter-networked systems using the transmitting and receiving node s physical MAC address for identification. Unlike the logical addressing that occurs at the Network layer (Layer 3), MAC addresses are not route-able resulting in the inability for Layer 2 communications to leave the Local Area Network (LAN). A LAN typically consists of a series of switches and connected devices that make up a broadcast domain in which every connected device can communicate with every other device via broadcast transmissions. A broadcast transmission is when a system sends a frame on the network that is received by every other connected device that is online. Broadcast domains can be separated by routing devices at Layer 3, which require the MAC address of the system to be translated to a logical IP address so that the packet can cross the boundary of the broadcast domain, and be passed on to a different broadcast domain connected to another interface on the routing device. This process includes the de-encapsulation of the frame at Layer 2 so that the router can examine the packet header at Layer 3 and determine the destination. Then the router re-encapsulates the packet into a new frame that is specific to the physical network media that it is being forwarded to. Layer 2 networking also allows for unicast transmissions. In this case a system transmits frames directly to the MAC address of the target destination instead of broadcasting it to the entire network. Layer 2 switches allow for the separation and isolation of this traffic by making each physical port a separate collision domain. A collision domain is an area on a network in which all transmissions can be intercepted by each device within the collision domain. This includes broadcast and unicast transmissions. Prior to the use of switches, Physical layer devices called hubs were used in order to connect multiple systems on a network. These devices provided no isolation between connected devices, and the entire 8

26 hub was considered as a collision domain. This allowed administrators along with malicious and curious users to easily eavesdrop on all of the traffic passing through the device. The implementation of Layer 2 switches instead of hubs corrected this problem with the separation of the physical ports into their own collision domains. This provides a level of protection for unicast traffic against eavesdropping or tampering, however in Chapter 4 I demonstrate how this isolation can be broken due to a flaw in the design of most physical switches. 2.3 Common Layer 2 Networking Protocols IEEE Ethernet The majority of wired networks in use today are using the IEEE Ethernet standard (LAN MAN Standards Committee, 2012) which provides specifications for the transmission of data across twisted pair copper and fiber optic cable. Part of this standard is the specification for the Ethernet frame (Figure 2.2), which defines the structure that is used to carry the encapsulated data across the network media. The Ethernet frame consists of a header that provides information about the frame such as where the transmission originated from as well as its intended destination. The frame also contains a trailer after the encapsulated packet portion which consists of a Frame Check Sequence (FCS) that is used to verify the frame integrity. Without a standardization of the container that carries the data across the network, systems would not be able to effectively communicate with each other. Two nodes on a network have to be able to speak the same language in order to setup a communication channel, and this is the reason why specific protocols and standards exist in networking. 9

27 Figure 2.2: An Ethernet Frame. This especially comes into play when manufacturing devices such as switches and networking cards that are to be used on Ethernet networks. They must be built around the Ethernet standard which defines the specifications and guidelines as to how these devices are expected to perform. The Ethernet frame is designed in such a way that it provides the information that Layer 2 networking devices require in order to send network traffic to the correct destination efficiently. For example, Layer 2 switches typically support one of two methods when forwarding a frame; cut-through and store and forward. In cut-through mode the switch only processes the preamble and destination fields of the frame, which are the first two fields. Once it reads the destination MAC address it immediately forwards the frame on without delay. In store and forward mode the switch processes the entire frame and uses the Frame Check Sequence (FCS) information to verify the integrity of the frame. If it finds a fault in the frame it will ask the transmitting node to resend the same frame again, otherwise it will forward it on to the destination. Both of these methods of switching are compatible with the same frame type, however one is more efficient at sending data across the network and the other is more reliable. The point here is that switches that support either mode can be mixed on a Ethernet network and the frames will be correctly forwarded because both modes of switching comply with the IEEE Ethernet standard. 10

28 2.3.2 Address Resolution Protocol (ARP) The Address Resolution Protocol (ARP) is a Layer 2 networking protocol that is used to map the physical MAC addresses of connected devices within a broadcast domain to their logical Layer 3 IP addresses. Each device on the network maintains an ARP cache which is a table that is dynamically updated when a device discovers other devices located within the same Layer 2 network. When a system is initially placed on a network, the ARP cache is empty and is filled with new entries as the system begins to communicate with other systems, either directly or via broadcast transmissions. Typically, the first entry added to the ARP cache is the default gateway for the network. The process of updating the ARP table is rather simple. If a system on a network does not know the physical MAC address of another system within the broadcast domain, it will send out a broadcast transmission to every connected device asking who has that specific Layer 3 IP address. Once the system that is assigned the target Layer 3 IP address receives the Layer 2 ARP broadcast, it sends a unicast reply back to the requesting system with its physical Layer 2 MAC address. The requesting system then updates its ARP cache so that it does not need to send out the broadcast request again when it needs to establish future connections to that particular system. This process can be easily filtered and viewed in open source network traffic monitoring programs such as tcpdump (Tcpdump Project, 2016) or Wireshark (Combs, 2016). The following example is filtered ARP traffic output from the tcpdump program showing the ARP request broadcast and unicast reply process. ARP, Ethernet (len 6), IPv4 (len 4), Request who-has vader (ec:b1:d7:55:04:51) tell , length 46 ARP, Ethernet (len 6), IPv4 (len 4), Reply vader is-at (ec:b1:d7:55:04:51), length 28 11

29 2.3.3 Spanning Tree Protocol (STP) The Spanning Tree Protocol (STP) is a Layer 2 network protocol defined in the IEEE 802.1D standard (LAN MAN Standards Committee, 2004) for local and metropolitan area networks to prevent loops from occurring within a Layer 2 network topology. The standard also allows for redundant links to be created between switching and bridging devices on a network that act as a fail-over if the main trunk link is down. When a spanning tree is created within a broadcast domain there are typically multiple paths that are established between any two nodes on a network. The Spanning Tree Protocol organizes the network topology into a tree that reduces the amount of redundant paths between any two nodes to a single active path. Other paths may still physically exist within the topology, but the protocol blocks them until they are needed for fail-over or load balancing purposes. In order to create the tree a root bridge is selected that acts as the root node of the tree. The root bridge is identified as the device on the network with the smallest bridge ID and the highest priority. The protocol attempts to calculate the lowest cost paths between the root bridge and each network segment, as well as between each network segment, and uses the interfaces connected at each end of those paths as the primary links. When a device or link goes down the protocol automatically diverts the traffic to a higher cost path until the original path is functional again. STP uses Bridge Protocol Data Units (BDPU) as a method to exchange information about the bridge IDs and path costs within the network. By default BDPU frames are broadcast across the network every two seconds, and can be used to configure the spanning tree as well as make changes to the network topology. When a switch port is configured to use STP and accept BDPU frames it can be in one of five different states; blocking, listening, learning, forwarding, and disabled. If the state is set to disabled then the port is not participating in STP, in which case it ignores any BDPU frames that are sent to it. The 12

30 blocking state is similar to the disabled state however the port is still listening and receiving the periodic broadcast of BDPU frames, however it cannot be used to pass traffic until the block is released. A blocked port may be put into the forwarding state if another link path fails and a message is sent in a BDPU frame that signals it to start up as a fail-over link due to a failure in the lower cost path. Ports are considered to be in the forwarding state if they are sending and receiving data as normal. When in the forwarding state the port still listens to the BDPU broadcasts and adjusts itself as necessary depending on if there is a topology change or not. The listening and learning states are intermediate states in which the port listens for BDPU frames and populates its MAC address table. No frames are forwarded in either the listening or learning states until the port is put into the forwarding state, in which case it is clear to start transmitting frames across the network Virtual Local Area Networks (VLAN) The IEEE 802.1Q standard (LAN MAN Standards Committee, 2005) provides support for separating a physical network into multiple logical networks by allowing the creation of multiple Virtual Local Area Networks (VLANs) within a single Layer 2 switching device. This allows an administrator to use a set of physically connected switches to create multiple (virtual) networks that span the same network hardware and media. Each of the separate VLANs are considered as an isolated broadcast domain, therefore a Layer 3 routing device has to be put into place if traffic needs to flow between them. In order to maintain isolation between multiple VLANs running over the same switch, the Ethernet frame supports the addition of a 32-bit 802.1Q VLAN tag (Figure 2.3) which identifies the specific VLAN that the frame belongs to in the tag s VLAN ID (VID) field. 13

31 Figure 2.3: An Ethernet Frame with an Added 802.1Q VLAN Tag. When setting up a Layer 2 switching device to support 802.1Q VLANs there are two types of port configurations to consider; trunk and access. A trunk port is typically used to connect switches together in order to allow traffic from multiple VLANs to travel between the devices over the same backbone channel. Access ports are those that are configured for client access to the network, and more specifically to a certain VLAN. When a client connects to an access port the connection to the virtual LAN is transparent. The client does not require any special configuration to support being on the VLAN because the switch automatically adds the VLAN tag to every frame that is sent over the port. The combination of trunk and access ports allow administrators to place clients located on separate switches within the same VLAN. This provides flexibility when initially designing the network topology, as well as when it comes time to scale it up in the future. By default switches that support the 802.1Q protocol are configured to use a native VLAN, which is usually VLAN 1 on the switch. The native VLAN allows for the passing of untagged traffic and is typically configured to be used for management purposes only. Every other VLAN that is configured on the switch is considered as an access VLAN. Access VLANs require frames to have the proper VLAN ID in their 802.1Q tag in order to 14

32 be transmitted within the logical broadcast domain. If the 802.1Q tag does not exist or the VLAN ID is incorrect the frame is dropped. By separating traffic into multiple VLANs, and more specifically separate isolated broadcast domains, administrators are able to restrict access to network resources, quickly isolate problems, and increase overall network performance Dynamic Host Configuration Protocol (DHCP) The Dynamic Host Configuration Protocol (DHCP) is an Application layer (Layer 7) protocol that relies heavily on Layer 2 broadcast messages in order to provide dynamic Layer 3 addressing services within a single broadcast domain. DHCP simplifies the allocation of IP addresses and required network information to clients by completely automating the process. This prevents errors that typically occur when manually assigning addresses to network nodes which can be caused by typographical errors, omissions of required network information, or by inputing the same address on multiple clients causing address conflicts. The DHCP service can be configured to provision IP addresses from an IP address pool that is reserved for this process. Clients that request an address from the DHCP server are allocated one from the pool and are also provided with the proper subnet mask for the network, the address of the default gateway, as well as Domain Name Service (DNS) server information for name resolution. The Dynamic Host Configuration Protocol also can be configured to push a wide range of other options to clients which are defined by the Internet Engineering Task Force (1997) in RFC Currently the DHCP specification supports up to two hundred and fifty five (eight bits) different options, many of which are non-standard, application specific, or proprietary extensions. 15

33 Figure 2.4 illustrates the interaction that occurs when a client requests an IP address from a DHCP server within the same broadcast domain. First the client sends out a broadcast to the network requesting a DHCP server to respond with an address lease offer. Once a DHCP server on the network intercepts the client request broadcast it checks its pool for an available address, then makes an offer to the client in the form of a unicast response to the client s Layer 2 MAC address. The client then replies with an acknowledgment, and accepts the IP address lease. The server then responds with the lease information consisting of; the lease duration, client IP address, subnet mask, default gateway, and DNS information for the network as well as any other options that it is configured to push. Once the client receives this information it uses it to automatically configure its network interface card appropriately to communicate with other nodes on the network. Figure 2.4: Dynamic Host Configuration Protocol process. 2.4 Virtual Layer 2 Networking Options There are two types of networking configurations that are typically used in virtualized environments: bridging and switching. In this section we describe both options and discuss how each one is applied within a virtualized network. 16

34 2.4.1 Bridging Bridged mode is the simplest configuration providing an interface dedicated to virtual machine use. A bridge connects two or more network segments at Layer 2 in order to extend a broadcast domain and separate each of the segments into their own individual collision domains (Seifert and Edwards, 2008). A forwarding table as described by (LAN MAN Standards Committee, 2004; Seifert and Edwards, 2008) is used to list the MAC addresses associated with devices located on each network segment connected to the bridge (Figure 2.5). Requests are forwarded based upon contents of this table and the destination MAC address located in the Ethernet frame. A frame is forwarded across the bridge only if the MAC address in the destination block of the frame is reachable from a different segment attached to the bridge. Otherwise, the frame is directed to a destination address located on the same segment as the transmitting device or dropped. Figure 2.5: A basic bridge using a forwarding table to pass requests between two network segments. 17

35 In virtualized environments, guest machines utilize user-space virtual network interfaces that simulate a Layer 2 network device in order to connect to a virtual bridge. Typically, the virtual bridge is configured and bound to a physical interface on the host machine that is dedicated solely to virtual machine traffic Switching Physical switches have the capability of operating at Layer 2 or higher of the OSI model. Switches can be thought of as multi-port bridges (Seifert and Edwards, 2008) where each port of the switch is considered as its own isolated collision domain. Instead of a forwarding table, switches employ a CAM (content addressable memory) table as described by (Seifert and Edwards, 2008). Content addressable memory is specialized memory hardware located within a switch that allows for the retention of a dynamic table or buffer that is used to map MAC addresses of devices to the ports they are connected to (Figure 2.6). When a packet arrives on a port from a new device, an entry mapping the device to the port is added to the table. This allows a switch to intelligently send traffic directly to any connected device without broadcasting frames to every port on the switch. The switch reads the frame header (Figure 2.7) for the destination MAC address of the target device, matches the address against its CAM table, then forwards the frame to the correct device. If a MAC address is not found in the CAM table, a packet destined for it will be sent to all interfaces. The use of a CAM table and the separation of collision domains are key factors in preventing eavesdropping of network traffic between devices connected to the switch. However, a physical switch is an embedded device and has a finite amount of memory available 18

36 Figure 2.6: A switch and its CAM table. Figure 2.7: An Ethernet Frame. Switches just need to match the destination address from the frame to an entry in its CAM table in order to forward it on to the correct port. to its CAM table; once this memory is full, the switch must discard existing entries in order to add new entries. The majority of physical switches in use today employ CAM chips 19

37 that are capable of holding up to 32,000 addresses (Seifert and Edwards, 2008) which can easily be saturated by a single MAC flooding attack in a very short amount of time. Virtual switches emulate their physical counterparts and are capable of providing features such as VLAN traffic separation, performance and traffic monitoring, as well as quality of service (QoS) solutions. Virtual machines are connected to a virtual switch by the way of virtual network interfaces (VIF) that are similar to the Layer 2 network devices used in conjunction with virtual bridges. 2.5 Layer 2 Network Attacks Media Access Control (MAC) Attacks The most popular attack in this category is the MAC flooding attack. In this attack, a switch is flooded with numerous random MAC addresses in order to fill up the content addressable memory (CAM) buffer within the switch forcing it into a fail safe mode, otherwise known as hub mode. When a switch is operating in hub mode, the inherent separation of collision domains is broken and all frames passing through the switch are forwarded to all connected devices. This allows for passive eavesdropping of all traffic passing through the device. MAC flooding can be mitigated by enforcing port security on physical switches which imposes a limit on the amount of MAC addresses that can send traffic to a specific port (Cisco Systems Inc., 2015a). This feature is not implemented within the majority of the virtual switches available today rendering them vulnerable to MAC flooding attacks. 20

38 2.5.2 Dynamic Host Configuration Protocol (DHCP) Attacks The Dynamic Host Configuration Protocol (DHCP) is actually an Application layer protocol that relies on the Layer 2 MAC address and the process of broadcasting to provide IP addresses to clients located within the same broadcast domain. In order to perform a Layer 2 DHCP attack an attacker must place a rogue DHCP server on a network in hopes that clients in the broadcast domain associate with it rather than the legitimate DHCP server. Once a client receives an IP address lease from a malicious DHCP server under an attacker s control, that client could also be seeded with the IP address of a poisoned DNS server, an incorrect default gateway, or be forced to run malicious code. This type of attack could also cause DoS situations where duplicate addressing occurs on the network causing the resources bound to those addresses to be inaccessible. These attacks can be mitigated by enforcing static addressing, or by using utilities to monitor the network and alert administrators when this type of activity is encountered Virtual Local Area Network (VLAN) Hopping VLAN hopping is the term used to describe an attack where an Ethernet frame is modified to force traffic to traverse (hop) VLANs in order to allow an attacker to gain unauthorized access to restricted portions of a network. More specifically, an attacker modifies the VLAN tag embedded in the frame to contain the ID of the target VLAN on the network. In order to perform this type of attack against a switch, the attacker must be connected to a port on the device that is a member of the native VLAN, or one that is setup as a trunk port. When the modified frame is passed through the switch, the VLAN tag is read and the switch places it within the correct broadcast domain associated with that VLAN ID. If successful, the attacker can then proceed to intercept traffic on the target VLAN or perform 21

39 other malicious activities such as DoS attacks against services running on that particular portion of the network. VLAN hopping can be mitigated by enforcing strict VLAN configuration of physical switch ports to prevent unauthorized access to the default VLAN or trunk ports Address Resolution Protocol (ARP) Spoofing ARP spoofing is a technique used by attackers that allows for the hijacking of traffic destined for another host. Specifically, by using ARP spoofing an attacker can perform a man-in-the-middle (MITM) attack that allows for eavesdropping between two hosts on a network. An attacker can also broadcast fake ARP messages to a network to redirect traffic or create DoS situations. ARP spoofing attacks can be mitigated by using static ARP entries for all hosts on a network, however this is a cumbersome task and is typically avoided unless absolutely necessary. More often that not savvy administrators will employ the use of network monitoring utilities to watch for suspicious behavior and react accordingly based upon the alerts Spanning Tree Protocol (STP) Attacks In this type of attack, incorrect BPDU frames are sent to switches in order to modify the spanning tree topology implemented on the network. By exploiting STP, an attacker could perform a man-in-the-middle (MITM) attack allowing eavesdropping on traffic passing between two nodes on a network (Lauerman and King, 2010). The attacker could also cause a denial of service (DoS) situation rendering services unavailable to legitimate users. 22

40 STP based attacks can be mitigated on Cisco Catalyst switches by enabling either the Cisco Catalyst BPDU Guard or Root Guard feature on the device (Lauerman and King, 2010). By enabling BPDU guard on switch ports administrators are able to control the STP domain boarders and prevent changes to the topology (Cisco Systems Inc., 2015c). BPDU guard is enabled Cisco switches by configuring certain ports on the switch to use STP PortFast mode. When a port is configured in STP PortFast mode devices connected to it are not allowed to influence the STP topology (Cisco Systems Inc., 2015c). If the port receives a BPDU while in PortFast mode it is put into a disabled state and a log entry is made alerting the administrator that the port received a BPDU attempting to make changes to the STP topology. Root Guard (Cisco Systems Inc., 2005) is another feature that Cisco implemented in their modern switch lines that offers some additional protection against STP topology attacks. When Root Guard is enabled on a switch port it blocks the port from becoming the new STP root node of the tree. The STP topology can be augmented with BPDU frames that specify when the root node should be changed to a different switch, which also causes a recalculation in the tree topology and pathing. Root Guard monitors the port for BPDU frames that are attempting to change the topology, and when one is received on the protected port it shuts it down and creates an alert in the logs indicating that there was an attempted STP root node change. Seeing as these are proprietary features available only on Cisco Catalyst switches they offer no help in preventing these attacks from being successful within a non-cisco network that utilizes STP. Virtual switches are currently unaffected by Spanning Tree Protocol attacks due to the fact that the switches do not support STP and ignore any BDPU frames that they receive. In fact some of the major hypervisor vendors have provided documentation that actually informs administrators to disable STP on ports that their products are connected to by enabling PortFast mode on the interface (Citrix, 2016; VMWare, 2013). This helps to prevent network service interruption to the virtual machines hosted within the hypervisor platform 23

41 when changes occur in the STP topology that cause a convergence. The STP convergence process forces all switches in the STP domain to dump their forwarding tables and relearn the entire STP topology including all related MAC addresses. This process could take up to one minute before connectivity is restored (VMWare, 2013) causing downtime to each of the devices connected to the network. If best practices are followed and switch ports that are connected to virtual switches are properly configured in PortFast mode, this downtime could be mitigated. This is especially important for large data centers that rely on virtualization for their entire infrastructure. If STP is enabled on the network then this could cause serious concerns for clients that have service level agreements (SLA s) in place where there is an expected level of uptime that should be consistently maintained. 24

42 CHAPTER 3 RESEARCH ENVIRONMENT 3.1 Original Environment The original research environment consisted of seven server class systems all located on a test network that was isolated from local production networks to avoid impacting them. I deployed an optimized installation of Gentoo Linux and the Xen 4.3 hypervisor to three Dell PowerEdge 860 servers each equipped with a dual core Intel Xeon GHz processor, 4 GB of memory, and a 500 GB hard drive. Each system contained dual Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI Express network interface cards integrated into the motherboard. The first network interface was dedicated to the privileged control domain on each server for administrative functions, and the second configured to be utilized by guest virtual machines. Each server s 500 GB hard disk was divided into four partitions; a 100MB ext3 /boot, a 10GB ext3 /, a 2GB swap, with the remainder allocated to Logical Volume Management (LVM) storage for virtual machine deployment. Four additional servers were configured with enterprise level hypervisor solutions: Citrix XenServer 6.2, Microsoft Windows Server 2008 R2 with the Hyper-V hypervisor, Microsoft Hyper-V 2008 (free edition), and VMware vsphere (ESXi) 5.5 (free edition). The hardware utilized for the Citrix XenServer 6.2 system was identical to the three Gentoo 25

43 systems, however the Microsoft Hyper-V and the VMware vsphere hypervisors were configured on systems with different hardware configurations due to a lack of additional Dell PowerEdge 860 systems. Both Microsoft Windows Server 2008 R2 along with the Hyper- V hypervisor as well as the free version of Hyper-V 2008 were installed to identical Dell PowerEdge 2950 server systems containing dual quad core Intel Xeon 5140 processors at 2.33GHz, 32GB of memory, and a 145GB SATA hard drive. VMware vsphere (ESXi) 5.5 (free edition) was deployed to a custom built server using a Supermicro X9SCL server motherboard, a quad core Intel Xeon E processor at 3.30GHz, 24GB of memory, and a 500GB SATA hard drive. The Hyper-V and vshpere systems were each outfitted with two network adapters in order to provide separate dedicated interfaces for administrative purposes and virtual machine use. Though there are notably some variations in the hardware configurations summarized in Table 3.1, it is important to note that these differences had no impact on the results of the experiments that were performed. Table 3.1: Summary of the orignial test environment hardware. Hardware Specs CPU Memory Hard NICs Platform Type Size Disk OS Xen w/ Linux Bridging Xeon GB 500 GB 2 OS Xen w/ Open vswitch Xeon GB 500 GB 2 OS Xen w/ Open vswitch Xeon GB 500 GB 2 Citrix XenServer 6.2 Xeon GB 500 GB 2 MS Server 2008 R2 w/hyper-v Xeon GB 145 GB 2 MS Hyper-V 2008 Free Xeon GB 145 GB 2 VMware vsphere (ESXi) 5.5 Xeon E GB 500 GB 2 For the MAC flooding scenario, two virtual machines were deployed to each virtualization platform: one malicious virtual machine attempting to eavesdrop on the traffic of any other tenant virtual machines and one victim virtual machine (Figure 3.1). The Kali Linux 26

44 security distribution was selected due to the plethora of network security auditing tools that come pre-installed and configured. Two complete installations of Kali were installed to each server on 20GB LVM partitions as hardware virtual machine (HVM) guests. The systems were then allocated static IP addresses that positioned them on the same isolated subnet as the servers and were completely updated. Figure 3.1: A malicious virtual machine located on a multi-tenant virtual network. The DHCP attack testing required a more elaborate setup. Specifically, four virtual machines were created within each hypervisor platform. Each of these virtual machines used a minimal installation of CentOS 6.5 and was configured for a specific purpose (Table 3.2). First, a virtual machine acting as a rogue DHCP server was setup and configured using DNSMasq, a lightweight DHCP and DNS server. Second, a simple router using iptables on a separate virtual machine was used to forward traffic between two broadcast domains using NAT and two network interfaces. Third, a basic Apache web server was setup to act as a malicious web server. Fourth, the final virtual machine was configured as a minimal client that was left unpatched and vulnerable to shellshock (National Vulnerability Database, 2014c). 27

45 Table 3.2: New virtual machines added to each hypervisor platform for Layer 2 DHCP attack testing. Operating Completely System Virtual System Updated Purpose Interfaces CentOS 6.5 Yes DHCP/DNS Server 1 CentOS 6.5 Yes Simple Router 2 CentOS 6.5 Yes HTTP Server 1 CentOS 6.5 No Left Vulnerable to ShellShock Upgraded Research Environment In August of 2015 I acquired $30,000 worth of funding to build a new test environment for this research. The previous systems that were used for the MAC flooding and DHCP attack experiments were somewhat outdated and consisted of mismatched hardware which made for an inconsistent test environment. Originally this was not a concern because of the fact that the DHCP and MAC flooding attack experiments were not dependent on system performance. However, it could be argued that the original MAC flooding performance results were skewed due to the fact that some of the systems contained better processors and more memory than others. Since acquiring the funding I have upgraded the entire test environment to eight brand new identical SuperMicro server systems, and have installed the latest versions of each of the hypervisor environments as of September 2015 in order to continue the research in a uniform environment with the latest software available. Each new rack mountable 1U SuperMicro server system consists of a quad core Intel Xeon X3-1240V3 processor running at 3.4GHz, 32GB of memory, a 500GB Western Digital Enterprise 7400 RPM SATA hard drive, and four on-board Intel Gigabit Ethernet ports. Having four Ethernet ports on each system allowed me to dedicate a port to the hypervisor operating system for management purposes, and also provided the flexibility to use the other three ports for different virtual machine network configurations within each environment. 28

46 This especially became useful when conducting the VLAN hopping experiments since a separate isolated network had to be created in order to run the attacks without affecting the primary virtual machine test network. This isolated network was created by connecting the third Ethernet port on each of the physical systems to a 48-port Cisco 2950 switch. There was also an uplink from the 48-port switch to a second 24 port Cisco 2950 switch in order to support multiple test scenarios. The initial interface and trunking configurations used for each of the Cisco switches can be found in Appendix C. As previously stated I upgraded all of the hypervisor environments and virtual switches to the latest versions as of September 2015 and also added a few new configurations to the mix. I swapped out two of the systems that were found to be redundant (Gentoo/Xen/OVS , and MS Hyper-V Free Edition) in favor of two new environments (Proxmox, and MS Hyper-V with the Cisco Nexus 1000v) to add more variety since it was found that there was no difference when testing those systems in comparison with the newer or more robust solutions that were offered at the time. Kali 2.0 was installed to the eighth system in order to have an independent physical test system to use in the VLAN hopping experiments. Table 3.3 provides a list of the hypervisor environments and operating systems that were installed to the new hardware along with the virtual switch configuration used within each system. 29

47 Table 3.3: Summary of hypervisor platforms and virtual switch configurations installed to the new hardware. Hypervisor Platform Gentoo OS Xen Virtual Switch Linux 802.1d Bridging Gentoo OS Xen Open vswitch VMWare vsphere ESXi MS Server 2012 R2 DataCenter w/hyper-v MS Server 2012 R2 DataCenter w/hyper-v ProxMox 3.4 (KVM) Standard ESXi Virtual Switch Standard Hyper-V Virtual Switch Cisco Nexus 1000v 5.2(1)SM3(1.1a) Linux 802.1d Bridging Citrix XenServer Open vswitch Kali 2.0 Standalone System No virtual switch 30

48 CHAPTER 4 MAC FLOODING ATTACK 4.1 Introduction The Layer 2 Media Access Control flooding attack, also known as MAC flooding, is an attack in which many packets are generated on the network with random MAC addresses in an attempt to overflow the CAM buffer within a switch and thus force the switch into a mode in which it broadcasts packets on all interfaces. This happens because the legitimate MAC addresses are evicted from the CAM table in favor of the many random MAC addresses generated by the attacker. This is referred to as hub mode and when a switch is operating in hub mode, the inherent separation of collision domains is broken and all frames passing through the switch are forwarded to all connected devices. This allows for passive eavesdropping of all traffic passing through the device. MAC flooding can be mitigated by enforcing port security on physical switches which imposes a limit on the amount of MAC addresses that can send traffic to a specific port (Cisco Systems Inc., 2015a). This feature is not implemented within the majority of the virtual switches available today rendering them vulnerable to MAC flooding attacks. 31

49 4.2 Attack Methodology The program macof from the dsniff package (Yeung et al., 2008) was used on a Kali virtual machine to perform a MAC flooding attack (Figure 4.1) on the virtual network within each test environment. This type of attack when performed on a physical switch typically causes the CAM table on the switch to fill up forcing the device to go into a fail safe or hub mode which in turn causes all packets on the network to be broadcast to every node connected to the switch. Wireshark (Combs, 2016) was used to determine if the attack was successful by monitoring the network for HTTP traffic which should not be interceptable by other hosts on the virtual network. Figure 4.1: A malicious virtual machine running macof to flood a virtual network with random MAC addresses and malformed packets. All tests were conducted in the same manner. Each server had two Kali Linux virtual machines deployed on them and connected to the internal virtual network as illustrated in 32

50 Figure 4.2. During each experiment both virtual machines were brought online. On the first virtual machine (Kali1) macof was started up using the command: macof -i eth0 and left to run. Then Wireshark was started on the same virtual machine and an HTTP filter was applied to only display sniffed HTTP traffic. The second Kali virtual machine (Kali2) was then used to surf the web. If the attack proved to be successful then the HTTP traffic from Kali2 should be viewable in Wireshark on Kali1. Figure 4.2: Network diagram for MAC flooding attack scenarios. 4.3 Results Linux 802.1d Bridged Interface Running the attack within the bridged virtual network test environment resulted in a significant performance degradation that impacted the usability of the tenant virtual machines, 33

51 essentially creating a denial of service (DoS) type of attack. This effect was observed as a large increase in latency when attempting to interact with any of the virtual machines on the system either through Secure Shell (SSH) or Virtual Network Computing (VNC). While the MAC flooding attack was occurring remote connections to the virtual machines became unstable due to the saturation of the virtual network with spoofed frames. This effect was quantified by using the ping utility on the second virtual machine to measure the transmission latency to a server located on the physical network while the attack was occurring (Figure 4.3). The attack however did not result in the ability to sniff other virtual machine traffic passing over the interface. This most likely comes from the fact that the standard bridge interface is missing the CAM table that typically is found on switches mapping known MAC addresses to switch ports, an essential element of the attack. Figure 4.3: Latency measured using the ping utility on a bridged virtual network during a MAC flooding attack. The attack was launched at ICMP request 61 and terminated at ICMP request

52 4.3.2 Open vswitch Interface When running the attack on the Open vswitch virtual network test environment network performance degradation was also observed, and the attacking machine could also successfully sniff traffic from another tenant machine. Figure 4.4 depicts the results of the successful attack and provides substance to the claim that virtual switches are vulnerable to some of the same Layer 2 attacks as physical switches. Figure 4.4: A malicious virtual machine running macof on an Open vswitch virtual network and successfully sniffing HTTP traffic with Wireshark from another tenant virtual machine Open vswitch Interface Running the attack on the latest version of Open vswitch available at the time of this research revealed that the vulnerability still existed and had not been addressed. The system responded in the same way as the previous two attempts and the other tenant s HTTP traffic was viewable in Wireshark. It should be noted that in February of 2015 I notified the Open vswitch security team of the discovery. They confirmed the vulnerability and immediately responded with a patch 35

53 (Pfaff et al., 2015; Pfaff, 2015a) to resolve the issue. Since then the patch has been merged into every major branch of Open vswitch from on (Pfaff, 2015b). It is recommended that any environment running any version of Open vswitch prior to the patched version of the branch should be upgraded immediately, since both the vulnerability and exploitation technique have been made public Citrix XenServer 6.2 Citrix XenServer 6.2 utilizes an older version of Open vswitch (version 1.4.6) to provide virtual switching services to its client machines. When the MAC flooding test was attempted in the XenServer environment, it was also discovered that the flooding was able to escape the virtual environment which caused all upstream physical switches to go into hub mode as well. Not only did this allow the malicious virtual machine running Wireshark to sniff traffic from other tenant virtual machines, it also was able to eavesdrop on traffic from physical machines located within the same broadcast domain to which the physical Ethernet adapter was connected. Since this test was performed on a university network well over one hundred upstream switches were affected and put into hub mode which also had the side effect of disabling all VLAN separation within the affected devices. This made it possible to view the majority of the traffic flowing over the campus network from the attacking virtual machine using Wireshark. After disclosing the issue to the IT staff they promptly took action to enforce port security on all of their physical switches limiting each port to learning at most fifty MAC addresses at a time to avoid the possibility of CAM table overflow. 36

54 4.3.5 Microsoft Hyper-V Server 2008 R2 Testing under the Microsoft Hyper-V environment was performed both with and without the Windows Firewall service enabled to identify if there was any effect on the results. Both scenarios proved to be unsuccessful due to the fact that the virtual networking used by Microsoft Windows Server 2008 R2 provides some minimal protection for virtualized network traffic, this includes protection against MAC address spoofing (Microsoft, 2013). Further testing was performed on the free version of Microsoft Hyper-V to see if the protection offered by Server 2008 R2 is also built into the bare metal product. As with the previous environment testing was performed both with and without the Windows Firewall service enabled. It was concluded that under both conditions the free version of Microsoft Hyper-V 2008 was also unaffected by the MAC flooding attack since it is built upon a minimal version of Microsoft Windows Server 2008 R2 entitled Server Core. The Core version of Microsoft Server 2008 R2 still provides the same level of network protection as the full version, but only allows for the installation of specific server roles to the operating system (Microsoft, 2008), in this case the Hyper-V hypervisor VMware vsphere (ESXi) free edition All testing within the VMware vsphere environment was performed identically to the previous trials for completeness. Testing was performed on the free version of ESXi using the default virtual networking configuration. The results show that this particular configuration was not vulnerable to the MAC flooding attack in terms of a malicious user being able to eavesdrop on another tenant s network traffic. 37

55 4.3.7 Summary of MAC Flooding Results It can clearly be seen from the results summarized in Table 4.1 that any virtualized network environment built upon the Open vswitch virtual switch could be vulnerable to MAC flooding attacks, and has the potential to expose its client traffic to eavesdropping. Therefore, if a virtual machine is transmitting sensitive information over a virtual network that uses Open vswitch precautions should be taken such as using encryption in order to ensure that the information in transit remains confidential. Table 4.1: MAC flooding attack results across seven test environments. indicates the platform was affected. Results of Attack Impacted Eavesdropping Network Platform Allowed Performance OS Xen w/ Linux Bridging OS Xen w/ Open vswitch OS Xen w/ Open vswitch Citrix XenServer 6.2 MS Server 2008 R2 w/hyper-v MS Hyper-V 2008 Free VMware vsphere (ESXi) 5.5 Figures 4.5, 4.6, and 4.7 illustrate the effects of the MAC flooding attack on each of the virtual environments utilizing the same ping latency test that was previously described in Section and depicted in Figure 4.3 for the bridged interface. The MAC flooding attack performance benchmarks were conducted on the upgraded environment to ensure consistency among the different platforms, as well as to isolate any possibility of differences in hardware affecting results. This also resulted in the performance evaluation of the newer environments against the attack, specifically the ProxMox and Cisco Nexus 1000v 38

56 virtual networks were added. A control element is also provided in the following graphs via a Cisco 2950 hardware switch which underwent the same testing. All of the experiments were performed using Gigabit network interfaces to maintain uniformity in flood rate. As can be seen by the results any environment using a bridged or Open vswitch based virtual network was heavily affected by the attack in terms of network performance. The Microsoft Hyper-V virtual switch, the Cisco Nexus 1000v, and the ESXi virtual switch all maintained consistent performance throughout the entire test which was very similar to the performance of the Cisco 2950 hardware switch which remained unaffected during the attack. Figure 4.5: Latency comparisons against all tested platforms measured using the ping utility during a MAC flooding attack with a Cisco 2950 hardware switch used as a control. The attack was launched at ICMP request 61 and terminated at ICMP request

57 Figure 4.6: Latency comparisons against all tested platforms measured using the ping utility during a MAC flooding attack with a Cisco 2950 hardware switch used as a control. The attack was launched at ICMP request 61 and terminated at ICMP request 241. Figure 4.7: Box and whisker plot showing latency variations for each environment while being subjected to the MAC flooding attack. 40

58 4.4 Mitigation Techniques As stated previously the traditional way to prevent these attacks on physical switches is to utilized port security to lock down switch ports so they can only learn a limited amount of MAC addresses to avoid CAM table overflow. It is also wise to configure port security to limit network connectivity to authorized MAC addresses only. Since this feature is not possible on the majority of enterprise grade virtual switches in use today other mitigation techniques need to be investigated. The most obvious solution would be for the virtual switch developers to start incorporating port security features into their software switches as a default feature that is easily configurable. Another simpler solution would be to prevent the switches from going into a hub mode state in the first place by not emulating physical switch CAM table limits. Bare-metal hypervisor platforms are typically deployed on systems with large amounts of memory. Unlike physical switches which have a limitation on available resources, server systems have an abundance of memory that could be allocated to the task of providing dynamic CAM tables to the virtual switching devices that could be configured to adapt to a flooding situation and alert an administrator if the memory usage rises above a certain threshold. This would eliminate the possibility of information leakage due to the virtual switch going into a hub mode state. As stated previously most modern physical switches have a CAM table capacity limit of 32,000 MAC addresses. With each MAC address comprising of 48 bits this would require around 187.5MB of memory in order to store all of the addresses. This memory requirement is insignificant on most modern server systems today which could easily provide a larger more dynamic buffer to the virtual switch. 41

59 CHAPTER 5 DHCP ATTACKS 5.1 Introduction Layer 2 Dynamic Host Configuration Protocol (DHCP) attacks typically consist of an attacker placing a rogue DHCP server on a network that essentially competes with the legitimate DHCP server when responding to client addressing requests located within the same broadcast domain. Setting up a DHCP server on a Linux virtual machine is a fairly simple task that only requires installing the dnsmasq or dhcpd services and making a few minor configuration changes. The entire process can be completed in a short amount of time allowing an attacker to quickly place a rogue DHCP server within a multi-tenant virtualized environment. Since DHCP requests are broadcast across the network the attacks rely on the attacker s DHCP server to respond to the address request before the legitimate DHCP server in order to be successful. Once a client obtains an IP address lease from a malicious DHCP server, that client could also be seeded with the IP address of a poisoned DNS server, an incorrect default gateway, or be forced to run malicious code. This type of attack could also cause Denial of Service (DoS) situations where duplicate addressing (Figure 5.1) occurs on the network causing the resources bound to those addresses to be inaccessible, or allow for the execution 42

60 of Man-in-the-Middle attacks where traffic is first sent to an attacker and then onto the original destination. Figure 5.1: Duplicate addressing within a broadcast domain due to the presence of a rogue DHCP server. 5.2 Attack Methodology Three different attack scenarios were duplicated across each of the original seven test environments in order to evaluate the impact of the following Layer 2 DHCP attacks; seeding clients with a poisoned Domain Name Server (DNS) server, providing an invalid or malicious default gateway, and remote execution of code Seeding Clients With a Poisoned DNS Server When a client receives an IP address lease from a DHCP server it usually is also pushed DNS server information for the network. If the client is seeded with the IP address for a 43

61 poisoned DNS server under an attacker s control the client could potentially be directed to spoofed websites and services setup by the attacker to capture private information from the user such as user names, passwords, credit card numbers, and other personally identifiable information (PII) that the attacker could use to further penetrate the organization. For this scenario, the DNSMasq server was used to seed the client system with a poisoned DNS server through DHCP. Since DNSMasq also provides DNS server functionality the rogue DHCP server doubled as the poisoned DNS server that was passed to clients receiving addresses. The DNS server was setup to direct all traffic destined to to be redirected to the malicious web server (Figure 5.2). A command line web browser called elinks (ELinks, 2014) was then used in the client virtual machine to visit in order to observe the effect. Figure 5.2: Presence of a poisoned DNS server on a network whose address is provided to clients associated with a rogue DHCP server. 44

62 5.2.2 Providing Clients With an Invalid or Malicious Default Gateway If clients on a network obtain incorrect default gateway information from a rogue DHCP server under an attacker s control they will be unable to route traffic outside of the local network creating a denial of service situation for resources on other subnets or the Internet. An attacker can also push the IP address of a default gateway that leads the client into a malicious honeypot network that can be setup to mirror another subnet on the network. This could then be used to capture information from the user without their knowledge. In this scenario the DHCP server was configured to pass a bad default gateway address to clients that obtained their network configuration from it. First, it was set to pass as the default gateway with the intention of causing a DoS attack for access of subnets outside of the existing broadcast domain. Second, the DHCP server was configured to point clients to the second virtual machine that was setup as a router to direct traffic to a malicious honeynet (Figure 5.3). This in conjunction with a poisoned DNS server allows the attacker to direct traffic to malicious servers setup within the honeynet. In each case, the previously used web server was placed in the honeynet, and a DNS entry was setup to direct traffic to it through the rogue default gateway Remote Execution of Code The DHCP protocol allows for the passing of many options, one of these options has recently been used in order to execute remote code on a DHCP client machine running the BASH shell. This exploit has been referred to as ShellShock (National Vulnerability Database, 2014a,b) and allows an attacker to leverage a DHCP option in order to take advantage of a vulnerability in the BASH shell to execute remote commands on a vulnerable 45

63 Figure 5.3: Malicious virtual machine configured as a router on a network whose address is provided to clients as a default gateway when associated with a rogue DHCP server. client system (Accuvant Labs, 2014; TrustedSec, 2014). This is a very high risk vulnerability and the full extent of its effect are not yet known since BASH is utilized in many scripts and services that are essential to most Linux/Unix systems including Mac OS X. In this scenario, the DNSMasq server was setup to pass option 100 to clients (Figure 5.4) which was configured to leverage the ShellShock exploit in order to remotely execute the echo command with root privileges on the target machine and place text into a file in /tmp. The following code was placed into the /etc/dnsmasq.conf file on the DHCP server as a proof of concept to illustrate the vulnerability without damaging the client system. The entire /etc/dnsmasq.conf configuration file can be viewed in Appendix B. dhcp-option-force=100,() { :; }; /bin/echo Testing shellshock vulnerability >/tmp/shellshock_test 46

64 Figure 5.4: Malicious DHCP lease process leveraging ShellShock to issue the rm -rf / command using option Malicious Extension of the ShellShock Proof of Concept Attack After performing a successful proof of concept using a fairly harmless ShellShock exploit via DHCP to write to a file in /tmp I decided to evaluate each of the platforms against a more dangerous implementation of the attack. In this extension, the rogue DHCP server was configured to use option 100 to download a public key file from a remote web server and then add the key to the root user s.ssh/authorized keys file. If successful this attack would allow the attacker to use the corresponding private key to gain remote root access to the system via SSH without entering a password. The following code was added to /etc/dnsmasq.conf on the rogue DHCP server in order to implement the attack. dhcp-option-force=100,() { :; }; /usr/bin/curl -s webserver/pubkey >>/root/.ssh/authorized_keys 47

65 Like the proof of concept, the SSH public key attack was successful in each of the test environments. However, it was discovered that if SELinux (National Security Agency, 2009) was set to enforcing on the vulnerable client the public key could not be written to the root user s.ssh/authorized keys file. This also resulted in a permission denied error being sent to the console on the client system during the DHCP lease process. Further investigation showed that I was able to write to /tmp with SELinux set to enforcing because traditionally /tmp is set to world writable so that any service can add or manipulate files that are located there. An additional test was performed to verify that the dhclient process executed the ShellShock command with root privileges by changing option 100 in /etc/dnsmasq.conf to run the id command: dhcp-option-force=100,() { :; }; /usr/bin/id which resulted in the following output indicating that dhclient does run commands fed to it via option 100 as the root user on the remote system. uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:system_r:dhcp_t:s0-s0:c0.c Results Table 5.1 illustrates the results of the DHCP attack scenarios that were run within each test environment. It was found that out of each of the seven configurations that were tested, the virtual networking devices offered no protection against the attacks in their default configurations. This allowed every DHCP attack scenario to be successful across all of the environments. 48

66 Table 5.1: DHCP attack scenario results across seven test environments. indicates a successful attack. Attack Scenarios Shell Poisoned Invalid Malicious Platform Shock DNS Gateway Gateway OS Xen w/ Linux Bridging OS Xen w/ Open vswitch OS Xen w/ Open vswitch Citrix XenServer 6.2 MS Server 2008 R2 w/hyper-v MS Hyper-V 2008 Free VMware vsphere (ESXi) Mitigation Techniques SELinux offers some protection against the ShellShock attack. In the default configuration of SELinux, a remote network service is prevented from writing to a file that is not configured to be used by that service unless a specific SELinux rule exists to permit access (Red Hat, Inc., 2015). Multiple tests were done on different file and folder combinations with different permission levels. It was found that SELinux only permitted the dhclient service to write to files located in directories that were set to world writable with the chmod 777 command. However, if SELinux is set to disabled or permissive, the attack was again successful because full root write access to the system from a network service was no longer blocked. Knowing this provides a way of mitigating the remote execution of code via DHCP by enforcing the use of SELinux on all critical systems and learning how to configure it appropriately. It is important to note though that SELinux did not prevent any of the MAC flooding or other DHCP attacks from being successful. 49

67 The common theme among all of the DHCP attack scenarios is that the attacker must be able to place a rogue DHCP server on the network and beat out the legitimate DHCP server when responding to client requests. Preventing clients from interacting with the malicious DHCP server is the most logical answer to this problem. Static IP addressing is one solution, but it does not scale well and would not be applicable in a cloud environment. Cisco offers a feature in their hardware switches called DHCP snooping which according to them acts as a firewall between untrusted hosts and trusted DHCP servers (Cisco Systems Inc., 2015a). It allows validation of DHCP messages and rate-limiting of DHCP traffic to prevent rogue DHCP servers and DHCP starvation attacks from being effective on a network. Other utilities such as DHCP authorization can also be used in order to force clients to use a legitimate DHCP server, and ignore or drop responses from any other system trying to act as a malicious DHCP server on the network. Currently neither of these features are offered in the virtual switches that were used in this research leaving them all wide open to these types of attacks. If functionality similar to DHCP snooping on Cisco switches and DHCP authorization in Microsoft Active Directory environments were added to the virtual switching environments as standard features then data center operators could take proactive measures to safeguard their environments. The majority of the virtual switches in use today are capable of interacting with software defined networking (SDN) controllers which opens up the possibility of creating a solution that leverages SDN in order to provide a generic solution that would work across all virtual switching environments. One possible solution would be to create a SDN application that monitors the network for DHCP activity and verifies that the activity is legitimate and not malicious. This could be accomplished by monitoring each DHCP lease request and response to verify that the response is coming from a certified DHCP server on the network. If the response is found to be malicious then the traffic is dropped and an alert is sent to the administrator so that prompt action can be taken to quickly identify the 50

68 source of the attack. The problem with this solution however is that many vulnerabilities are being discovered in SDN controllers that allow an attacker to take control of the entire network that the controller manages (Tiwari et al., 2014). With the high likelihood of adding more security holes, and potentially providing an attacker with complete control of the network, it is difficult to recommend adding the extra overhead of SDN to the virtualized environment. A more simplified solution could be had by using a small Python scrip with the Scapy library (SecDev, 2016b) in order to identify rogue DHCP servers (SecDev, 2016a) on the network and alert and administrator of their existence. Rather than introduce the complexity of SDN into the virtual network the simple Python/Scapy script could be run as a service on a virtual machine in order to monitor the network for the DHCP requests and responses. I have written and tested a Python program based on this idea to prove that a simple solution could be developed. The source code and sample output for the program can be found in Appendix D.2.2. When executed the program sends out a DHCP request and waits for a period of time for a response. Once it gets a response, or multiple responses, it loops through each one and compares the Layer 3 IP address to the authorized DHCP server s IP address. If the address from a DHCP response is different from the authorized server then an alert is triggered. 51

69 CHAPTER 6 SWITCH SPOOFING VLAN HOPPING ATTACK 6.1 Introduction Switch spoofing is an attack that leverages a vulnerability (National Vulnerability Database, 1999) in physical Cisco switches that utilize the proprietary Dynamic Trunking Protocol (DTP) in order to automatically negotiate trunk links between switches. The majority of modern Cisco switches have DTP enabled by default on all ports out of the box so that trunk links can easily be formed automatically. If physical ports on a Cisco switch are left in the dynamic desirable mode, then an attacker can connect a system via any free switch port and fool the switch into thinking that their system is another switch looking to negotiate a trunk link (Figure 6.1). If the attack is successful, and a trunk link is formed (Figure 6.2), the attacker will have access to all of the VLANs associated with the trunk thereby giving their system access to any system located on any of the corresponding VLANs as illustrated in Figure 6.3. This attack has been well documented against physical networks in previous work performed by Cisco (Cisco Systems Inc., 2002) and the SANS Institute (Rouiller, 2015). There is also a powerful open source Layer 2 networking security auditing tool available called Yersinia (Omella and Berrueta, 2016) that can automate such a DTP attack against a Cisco switched network. 52

70 Figure 6.1: Attacker connects to free switch port and sends out DTP packet in order to establish a trunk link with the switch. Figure 6.2: A trunk link is formed between the switch and the attacker s system. 53

71 Figure 6.3: The attacker can now send and receive traffic on all VLANs associated with the trunk link. In this chapter, I discuss my evaluation of the effectiveness of executing a similar switch spoofing attack from a virtual machine. The attack is attempted within each of the seven test environments connected to a Cisco 2950 switch on the physical network. For comparison, I began with a control scenario in which the physical Kali 2.0 system was connected to a port on the Cisco 2950 switch to verify that the switch port could be successfully changed from dynamic desirable mode to trunking mode, and then move on to evaluating if the same attack works when executed from a virtual machine connected to a virtual switch with an uplink to the same physical Cisco 2950 switch. I adhered to the best practices guides (Citrix, 2015; VMWare, 2010; Fazio, 2008) offered by the hypervisor manufacturers when setting up the physical switch ports connected to each virtual switch environment. Each of these guides suggests that the switch port be manually setup as a trunk port with access to each of the VLANs required for the virtual 54

72 machines hosted within the environment. When testing the attack from each of the virtual networks, I made sure to convert the port that was connected to the system hosting the attacking virtual machine back to dynamic desirable mode from trunk mode in order to see if the virtual machine could successfully convert the physical switch port into trunk mode from the virtual network. In this case, I am suggesting that when the administrator connected the hypervisor environment to the physical switch they neglected to follow the best practices guide and never actually changed the switch port leaving it at its default setting of dynamic desirable. Figure 6.4 illustrates the control scenario using the physical Kali 2.0 system, and Figure 6.5 illustrates the scenario where the attacker is using a Kali 2.0 virtual machine located within one of the seven virtual test environments. Figure 6.4: Switch spoofing control scenario using a physical Kali 2.0 system to perform a DTP attack on a physical Cisco 2950 switch in order to gain unauthorized access to virtual machines on restricted VLANs. Figure 6.5: Switch spoofing scenario where the attack is generated from a virtual machine connected to a virtual switched environment that has a physical uplink to a Cisco 2950 switch in order to gain unauthorized access to other virtual machines located on restricted VLANs within other hypervisor environments. 55

73 6.2 Attack Methodology I utilized the Yersinia tool via SSH in command line mode on each of the attacking systems in order to perform the attack. The attack process was straight forward and consisted of the following steps: 1. First the Yersinia application was loaded at the command line with yersinia -I. 2. Then the proper network interface was selected to use for the attack, in all cases the default network interface was used. 3. Yersinia was then changed to DTP mode by pressing g and selecting DTP Mode. 4. The attack was then conducted by pressing the x key and selecting option 1 to enable trunking mode. If the attack was successful the Yersinia application displayed TRUNK/AUTO (Figure 6.6) in the DTP mode interface, otherwise if the attack failed ACCESS/DESIRABLE was displayed. I also verified if the attack worked by observing the interface and trunk status for the respective port associated with the attacking system on the Cisco switch by using the commands sh int status and sh int trunk from the console. This allowed me to see if the switch port was successfully converted into trunking mode or not. If the port was converted into trunking mode then the word trunk would be displayed under the VLAN column in the output of sh int status (Figure 6.7), and the interface would also appear in the trunk list with the word auto next to it in the output of sh int trunk (Figure 6.8). The results of this attack were varied across the different virtual network environments. The control test from the physical Kali 2.0 system worked as expected and the port was put 56

74 Figure 6.6: Successful switch spoofing attack with Yersinia. Figure 6.7: sh int status output indicating the successful conversion of the port to trunk mode. Figure 6.8: sh int trunk output indicating the port is now set to trunking mode with 802.1q encapsulation. into trunking mode from dynamic desirable mode which provided access to all of the virtual machines that were associated with VLANs available on the trunk. I simply loaded the 8021q kernel module on the attacking system, associated the target VLAN to the network interface and provide a valid IP address to the newly created VLAN tagged interface on the system. The following commands were used to set up the interface on the target VLAN 20. modprobe 8021q vconfig add eth0 20 ifconfig eth netmask up 57

75 This created a new network interface on the system labeled eth0.20 which could be used to access the target systems located within the isolated VLANs on each of the virtual networks. The same process was used when testing from the virtual machines in order to validate the attack. 6.3 Results Table 6.1 provides a summary of the results of the switch spoofing experiments. As can be seen from the results the attack worked in the control scenario as well as three out of the seven virtual network environments. If a virtual environment utilized a virtual bridged interface for virtual machine network connectivity the attack was successful, but the environments that utilized a virtual switch for network connectivity prevented the attack from occurring. It can also be seen that the ESXi standard virtual switch allowed the attack to occur which shows that the virtual switch is acting more like bridge than a switch. Table 6.1: Switch spoofing attack results across the seven virtual test environments and a physical control system. indicates the attack was successful. Results of Attack Negotiate Unauthorized Platform Trunk Link VLAN Access Physical Kali 2.0 Control System OS Xen w/ Linux Bridging OS Xen w/ Open vswitch VMWare vsphere ESXi MS Hyper-V Standard vswitch MS Hyper-V Cisco Nexus 1000v Proxmox Citrix XenServer 58

76 I have posted a demo video (Bull, 2016f) of the successful attack from the ESXi environment to YouTube in order to document the process that was used on each of the seven environments for this experiment. These results were a bit surprising since this attack is specific to a Cisco proprietary protocol and one would think that the attack would not be allowed to be passed from the virtual network to the physical switch as the DTP probes should be blocked. This was the case for each of the virtual switched environments since they were not compatible with the DTP protocol, however the bridged interfaces acted as a pass through allowing the attack to traverse through the virtual network and affect the physical switch. I attempted to perform the attack directly against the Cisco Nexus 1000v switch to see if its virtual interfaces could be converted to trunking mode. When configuring the Nexus 1000v per the deployment guides (Holman, 2013; Cisco Systems, Inc., 2015b), it was found that even connecting a virtual machine to the virtual switch required the creation of virtual subnets and policies that restricted which networks the virtual machines could access. This prevented the establishment of a trunk connection between the virtual machine and the Cisco Nexus 1000v virtual switch. 6.4 Mitigation Switch spoofing attacks can be mitigated on physical Cisco switches by following a few best practices such as disabling unused switch ports to prevent unauthorized physical access to the switch as well as disabling the Dynamic Trunking Protocol on all ports. Limiting VLAN access on trunk connections is also a wise preventive action to reduce the likelihood of an attacker gaining unauthorized access to all of the VLANs on the network. Because 59

77 DTP is a Cisco proprietary protocol, another way to mitigate this attack is to not use Cisco switches in the physical network. In terms of virtual networks connected to physical Cisco switches within a data center, it is important to recognize that this attack will work if the virtual network uses a bridged interface for virtual machine network connectivity. In order to prevent this from occurring, administrators could either convert the virtual network over to a secure virtual switched environment or lock down the physical switch to which the virtual platform is connected. The port could be secured by following best practices and ensuring that it is in trunk mode, and only has access to the specific VLANs that are required for the virtual network. Access to the native VLAN within the physical environment should also be blocked by removing it from the trunk VLAN access list on that specific port. 60

78 CHAPTER 7 DOUBLE-TAGGING VLAN HOPPING ATTACK 7.1 Introduction The VLAN hopping Double-Tagging or Double-Tagging VLAN jumping attack is an attack that leverages an inherent vulnerability in the 802.1q VLAN protocol (CVE Details, 2005) which allows an attacker to bypass network segmentation and spoof VLAN traffic by manipulating an Ethernet frame so that it contains two 802.1q VLAN tags. Figure 7.1 provides a visual comparison between a standard Ethernet frame and the 802.1q tagged variants. The first frame depicted is a standard Ethernet frame with no VLAN association. The second is an Ethernet frame that has an additional 4 Byte 802.1q header which provides information regarding which VLAN the frame belongs on. The last frame illustrates the concept of double-tagging the Ethernet frame with an additional 802.1q header. In order to be successful this attack typically requires two physical switches with a trunk connection established between them to be present in between the attacking system and the target system as depicted in Figure 7.2. When the Ethernet frame is pushed through the first switch the first 802.1q VLAN tag is stripped from the frame leaving only the second 802.1q VLAN tag. This tricks the second switch into thinking that the frame is destined for the target VLAN and it allows the frame to be forwarded on to the destination (Figure 7.3). 61

79 Figure 7.1: Comparison of a standard Ethernet frame with frames containing 802.1Q single and double VLAN tags. Figure 7.2: Network topology with two switches connected via a trunk link offering access to VLANs 1,2, and 3. 62