critical analysis of layer 2 network security in...

Critical Analysis of Layer 2 Network Security in Virtualized Environments

Computer SciencePh.D. Dissertation Proposal

Ronny L. Bull

Introduction

© 2015 Ronny L. Bull - Clarkson University

● Cloud Services

– Offer customers virtual server hosting in multi-tenant environments

● Virtual machines are typically all connected to a single virtual networking device within the host

● Host systems may utilize a virtual bridge or more robust virtual switch for inter-networking virtual machines

● Software emulated version of physical devices

The Question


● Since all client virtual machines are essentially connected to a virtual version of a physical networking device, do Layer 2 network attacks that typically work on physical devices apply to their virtualized counterparts?

● Important question to explore:

– All cloud services that rely on virtualized environments could be vulnerable

– This includes data centers hosting mission critical or sensitive data!

The Problem


● Initial research experiments show that virtualized network devices DO have the potential to be exploited in the same manner as physical devices

● In fact some of these environments allow the attack to spill out of the virtualized network and affect the physical networks they are connected to!

– MAC Flooding in Citrix XenServer● Allows eavesdropping on physical network traffic as well

as traffic on the virtual host

The Importance


● Identify security risks associated with virtual network implementations in multi-tenant virtualized hosting environments

– VMs from many customers share the same physical resources

– How secure is their network traffic from malicious users?

– What is the risk of using a cloud based service or virtualized infrastructure for sensitive network data and operations?

The Importance


● What if another tenant can successfully launch a Layer 2 network attack within a multi-tenant environment?

– Capture all network traffic

– Redirect traffic

– Perform Man-in-the-Middle attacks

– Denial of Service

– Gain unauthorized access to restricted sub-networks

– Affect performance

The Importance


● Users become empowered by understanding which virtual switch implementations are vulnerable to different Layer 2 network attacks

– Educated users will question providers about their hosting environment

– Audit the risk of workloads they run in the cloud or within multi-tenant virtualized environments

– Consider extra security measures● Increased use of encryption● Service monitoring● Threat detection and Alerting

Previous Solutions


● No previously published work related to Layer 2 (data link) network security in virtualized multi-tenant environments

● Majority of published Layer 2 network security research is focused on physical networks and devices

– Cisco

– @stake

– SANS Institute

● This research is helpful for identifying Layer 2 networking attacks that can be duplicated on virtualized networks

Previous Solutions


● Previous solutions in multi-tenant virtualized environments focus on the application layer and end user security

– Policies

– Frameworks

– Secure automated deployment of services

● Though these solutions provide an increased level of security and awareness they offer little protection against low level network threats at the data link layer

– If a network attack can be effective at the data link layer, any application layer defense mechanisms, policies, or security frameworks become useless

Potential to Succeed


● The initial discovery and vendor confirmation of multiple Layer 2 network threats

– MAC flooding effectiveness

– DHCP attack effectiveness

● Large interest from the network security community

– DerbyCon

– Bsides

– Defcon

● ~20 years of experience as a network security professional

● 5 years of experience as a network security instructor in higher education (SUNY Poly, MVCC, CompTIA)



● Developed a lab dedicated to this research at SUNY Poly

– Servers containing each major hypervisor platform and virtualized network configuration

– Isolated dedicated workstations and virtual machines

● Received funding via SUNY Research Foundation and SUNY Networks of Excellence to support summer research efforts

● Interest from Griffiss Cyber Research Institute in supporting the research

● Interest from AFRL in using the research to improve offensive and defensive capabilities

Test Environment

A.K.A.

SUNY PolyCloud Security Research Lab




● First major body of research focusing specifically on Layer 2 network security in virtualized environments using an offensive approach from the start

– Find vulnerabilities and weaknesses

– Define exploits

– Discover mitigation and hardening techniques and evaluate against defined exploits to validate effectiveness

Background


● Virtualization Overview

● Multi-Tenancy

● Virtual Networking

– Bridges

– Switches

Virtualization Overview


Multi-Tenancy


● Cloud service providers maximize resources

– Place multiple client VMs on same physical host

– Share CPU, Memory, Networking, & Storage resources

● Heterogeneous environments (OS, Services)

● Client access to VMs varies

– Some grant full root privileges● Installation from scratch by client● Pre-canned templates

– Others restrict setup or build to suit customer needs

Multi-Tenancy


● Amazon EC2

● Microsoft Azure

● Google Cloud Services

● Countless fly by night VPS hosting providers online

● Brick and mortar data centers serving local clients

● Similarities

– Most run some form of Xen (OS Xen, XenServer)

– Some use VMWare or Hyper-V

– All share network connectivity between tenants

Multi-Tenancy


Bridging


● Physical bridges connect two or more segments at Layer 2

– Separate collision domains

– Maintain MAC address forwarding table for each segment

– Forward requests based upon destination MAC addresses● Do not cross bridge if destination is on same segment as

source● Cross if destination is on a different segment connected

to the bridge

Bridging


Virtual Bridges


● Simplest form of virtual networking

● Uses 802.1d Ethernet Bridging

– Support built into Linux kernel and bridge-utils user-space package

– Uses virtual TAP interfaces to connect virtual machines to virtual bridge (ie. tap0)

● User-space “Network Tap”● Simulates a Layer 2 (link layer) network device

Virtual Bridging


Switching


● Physical switches operate at Layer 2 or higher

● Multi-port bridges

– Separate collision domains

● CAM Table – Content Addressable Memory

– Similar to bridge forwarding table

– Dynamic table that maps MAC addresses to ports

– Allows switches to intelligently send traffic to connected devices

– Check frame header for destination MAC and forward

– Finite amount of memory!

Ethernet Frame


Preamble

8

Dest.Address

6

SourceAddress

6

Type /Length

2

Data

~

FCS

4

Preamble

8

Dest.Address

6

What the switch needs to match against its CAM

Switching


Virtual Switches


● Advanced form of virtual networking

● Can emulate Layer 2 and higher physical devices

● Virtual machines connect to vSwitch via virtual interfaces (ie. vif0)

– Similar to tap devices

● Able to provide services such as

– QoS

– VLAN traffic separation

– Performance & traffic monitoring

Virtual Switches


Virtual Switches


● Variety of virtual switches available

– Typically bound to certain environments

– Open vSwitch● OS Xen, Citrix XenServer, KVM, Prox-Mox

– Cisco Nexus 1000V Series● VMWare vSphere, MS Hyper-V (add-on)

– MS Hyper-V Virtual Switch● Microsoft Hyper-V

● All are considered as enterprise level solutions

What If?


Initial Results

● MAC Flooding Attack● Attack Overview● Summary of Results

● DHCP Attack Scenarios● Scenario Descriptions● Summary of Results

● VLAN Attacks● Descriptions of Attacks● Physical network tests● Future work

MAC Flooding Attack


MAC Flooding


● MAC Flooding

– Flood switch with numerous random MAC addresses to fill the CAM table buffer

– Forces switch into fail safe mode (a.k.a. Hub mode)

– All frames forwarded to all connected devices● Breaks collision domain separation

– Works well on most physical switches

MAC Flooding


MAC Flooding Summary

MAC Flooding(Performance Degradation)


MAC Flooding

● Reported Open vSwitch vulnerability to:● cert.org

● Assigned VU#784996● [email protected]

● No response as of yet● [email protected]

● Responded with implementation of MAC learning fairness patch● Applied to all versions of Open vSwitch >= 2.0.0

● https://github.com/openvswitch/ovs/commit/2577b9346b9b77feb94b34398b54b8f19fcff4bd

● Received public acknowledgment as reporter of vulnerability and exploitation technique


mailto:[email protected]

mailto:[email protected]

https://github.com/openvswitch/ovs/commit/2577b9346b9b77feb94b34398b54b8f19fcff4bd

MAC Flooding Mitigation


● Can be mitigated by enforcing port security on physical switches

– Feature only currently available on Cisco Nexus 1000V 'Non-Free' version (VMWare Essentials Plus)

– Limit amount of MAC addresses that can be learned via a single port

● Only allow authorized MAC addresses to connect to a single port on the switch

– Trusted connections, no malicious intent

● Disable unused switch ports

DHCP Attacks


DHCP Protocol


● Networking protocol used on most computer networks to automate the management of IP address allocation

● Also provides other information about the network to clients such as:

– Subnet Mask

– Default Gateway

– DNS Servers

– WINS Servers

– TFTP Servers

Benefits of Using DHCP


● Reduces complexity of address management

– Duplicate address conflicts

– Manual entry errors when configuring clients

● Reduces administrative overhead in large networks

– No need to manually configure every client

– Centralized server responds to client requests as they come online

– Allows mobile devices to remain portable and be transparently configured without user intervention

DHCP ProtocolClient – Server Model


DHCP Options


● DHCP allows and administrator to pass many options to a client besides the standard Subnet Mask, DNS, and Default Gateway information

● Options are specified by a DHCP Option Code number

– Option 4 – Time Server

– Option 15 – Domain Name

– Option 35 – ARP Cache Timeout

– Option 69 – SMTP Server

● Options are defined in RFC 2132 - DHCP Options

–https://tools.ietf.org/html/rfc2132

https://tools.ietf.org/html/rfc2132

DHCP Attacks


● DHCP Attacks

– Rogue DHCP server is placed on a network

– Competes with legitimate DHCP server when responding to client addressing requests

– 50/50 chance that a client will associate with malicious server since client requests are broadcast to the network

● Multiple rogue DHCP servers will reduce the odds!– Setting up a DHCP server on an existing system is very

simple and can be completed in a matter of minutes

DHCP AttacksDuplicate Addressing


● Condition:

– Two DHCP servers provide addresses to clients on the same network within the same range

● ie. 10.1.2.100 – 10.1.2.200

– High probability that duplicate addressing will occur● First address allocated from each DHCP server will most

likely be: 10.1.2.100● Then 10.1.2.101 … 102 … 103 ... etc ...



● Affect:

– Denial of Service for the two clients that received the same address

● In conflict● Services provided by those clients become inaccessible

to other systems on the same network

– OR● Clients are directed to a malicious system that received

the same address as the legitimate system● Relies on malicious system replying to clients first

DHCP AttacksRogue DNS Server


● Condition:

– A malicious DHCP server provides associated clients with the IP address of a poisoned DNS server

– Poisoned DNS server is seeded with information that directs clients to spoofed websites or services

● Affect:

– Client system is directed to malicious services that are intended to steal information or plant viruses, worms, maleware, or trojans on the system

– PII or other sensitive information is harvested by the attacker

DHCP AttacksRogue DNS Server


DHCP AttacksIncorrect Default Gateway


● Condition:

– A malicious DCHP server provides the IP address of an incorrect default gateway for associated clients

● Affect:

– Clients are unable to route traffic outside of their broadcast domain

– Unable to access other resources on subnets or the Internet

DHCP AttacksMalicious Honeynet


● Condition:

– A malicious DCHP server provides the IP address of an malicious default gateway for associated clients

● Affect:

– Client traffic is routed to a malicious honeynet that the attacker setup in order to harvest PII or other sensitive information

DHCP AttacksMalicious Honeynet


DHCP AttacksRemote Execution of Code


● Condition:

– By making use of certain DHCP options clients can be forced to run code or other commands while acquiring a DHCP lease

● Each time the lease is renewed the code will be executed, not just the initial time!

– The BASH vulnerability ShellShock can be leveraged to remotely execute commands or run code on a vulnerable Linux or Mac OSX system



● Affect:

– Remote commands or code executed on associated system with root privileges!

● Intent could be harmless to catastrophic:– Set the system banner:

● echo “Welcome to $HOSTNAME” > /etc/motd– Send the shadow file somewhere:

● scp /etc/shadow [email protected]:.– Delete all files and folders on the system recursively

from /● rm -rf /

DHCP Attack Test Environment


● The same test environment was used as in the previous MAC flooding experiment

Hypervisor Virtual Switch

OS Xen 4.3 Linux 802.1d Bridging

OS Xen 4.3 Open vSwitch 1.11.0

OS Xen 4.3 Open vSwitch 2.0.0

Citrix XenServer 6.2 Open vSwitch

M.S. Server 2008 R2 w/Hyperv

MS Hyper-V Switch

M.S. Hyper-V 2008 - Free MS Hyper-V Switch

Vmware vSphere (ESXi) 5.5

Default vSwitch

DHCP Attack Virtual Machines


● However four new virtual machines were created in each platform to setup scenarios

Operating System Updates Applied Services VIFs

CentOS 6.5 (minimal) Fully Updated

DNSMasq -(DHCP/DNS) 1

CentOS 6.5 (minimal)

Fully UpdatedSimple Router - (IPTables)

2


Fully Updated Apache 2 (Web) 1


No UpdatesLeft vulnerable to Shell Shock

1

DHCP Attack Scenarios


● Remote Execute of Code

– The following command was passed with DHCP option 100:Dhcp-option-force=100,() { :; }; /bin/echo 'Testing shellshock vulnerability. If you can read this it worked!'>/tmp/shellshock

● Poisoned DNS Server

– The DHCP server was also configured as the poisoned DNS server directing clients to a malicious webserver spoofing gmail.com, mail.google.com, and www.gmail.com

DHCP Attack Scenarios


● Invalid Default Gateway

– Clients were passed a default gateway address of 1.1.1.1 instead of the valid 192.168.1.1

● Malicious Default Gateway

– Clients were passed a default gateway address of 192.168.1.20 which was a system configured as a simple router routing traffic to a malicious honeynet containing a web server

DHCP Attack Summary

DHCP Attack Mitigation


● DHCP attacks can be mitigated by the following:

● Enforcing static IP addressing, DNS entries, and default gateways on every device

– Cumbersome!

– Prone to error

● Utilized DHCP snooping on switches

– Option on some physical switches (Cisco, HP)

– Restrict network access to specific MAC addresses connected to specific switch ports

● Highly restrictive!● Prevents unauthorized DHCP servers

DHCP Attack Mitigation


● Use DHCP server authorization

– Windows 2000 server and up

– Feature of Active Directory and Windows DHCP servers

● Techniques using software defined networking (SDN) could be explored

– Define filters to identify DHCP client requests on the broadcast domain and forward them to the correct server

– Requires further investigation and experience with SDN

Looking AheadVLAN Hopping Attacks


Next Step

● Next step: evaluate VLAN security in virtualized environments:● All virtual switch products support the creation of VLANs● VLANs allow service providers to logically separate and isolate

multi-tenant virtual networks within their environments● Do the current known vulnerabilities in commonly used

VLAN protocols apply to virtualized networks?● Could allow for:

● Eavesdropping of traffic on restricted VLANs● Injection of packets onto a restricted VLAN

● DoS attacks● Covert channels


Virtual LAN Concepts

● Virtual LAN (VLAN)● Allows for separation of physical network into multiple logical

networks● Each logical network is considered as a single broadcast

domain● Layer 2 connectivity● Broadcast traffic reaches all logically connected nodes● Separated by Layer 3 devices (routers)● Broadcast domains can span multiple network segments by

the use of a bridge or switch



● Switch Ports (managed switches)● Trunk port

● Port on switch configured to carry traffic for multiple VLANs to other connected switches

● Allows VLANs to expand beyond a single switch● ie. between buildings

● Access port● Port on switch configured to provide access to a single VLAN● Tags all traffic entering port from connected devices with

associated VLAN ID (ie. VLAN 102) ● No need to configure connected device with specific VLAN

information



● Types of VLANs● Native VLAN

● Allows for the passing of un-tagged frames between devices● Trunk connections between switches● CDP, DTP, VTP messages between switches● VLAN 1 traffic between devices on a network

● Typically used for management purposes● Default VLAN on an un-configured switch

● Defaults to VLAN 1



● Types of VLANs (cont.)● Access VLAN

● Restricted VLAN used for client access to a logical network● All traffic is tagged with the ID of the access VLAN● Un-tagged traffic or traffic tagged with a different VLAN ID is

prevented from accessing the logically separated broadcast domain

● Used to isolate traffic on a network● Separate traffic from different departments● Increase security by preventing unauthorized access to

network resources



Dst MAC Src MAC Type/Len Data FCS

Standard 802.3 Ethernet Frame

● Standard Ethernet frames consist of the following fields:● Destination MAC address● Source MAC address● Type of frame or frame length● The data payload● A frame check sequence



● Ethernet frames are modified for VLAN traffic:● Addition of a 802.1q VLAN header

● 32 bits of extra information wedged in

Dst MAC Src MAC802.1q

VLAN Tag Type/Len Data FCS

4 Bytes

TPID0x8100

TPI(3 bits)

DEI(1 bit)

VID(12 bits)

2 Bytes 2 Bytes



● The IEEE 802.1ad standard also known as Q-in-Q allows for the addition of multiple 802.1q VLAN tags to a frame● Useful for:

● Provider bridging● Stacked VLANs

Dst MAC Src MAC 802.1qVLAN Tag

Type/Len Data FCS

4 Bytes


VLAN TagType/Len Data FCS

4 Bytes

802.1qVLAN Tag

802.1qVLAN Tag

4 Bytes


VLAN Hopping

● VLAN Hopping● An attack method used to gain unauthorized access to another

Virtual LAN on a packet switched network● Consists of attacker sending frames from one VLAN to another

that would otherwise be inaccessible● Two methods

● Switch Spoofing● Double Tagging


Switch Spoofing

● CVE-2005-1942● http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-1942● “Cisco switches that support 802.1x security allow remote

attackers to bypass port security and gain access to the VLAN via spoofed Cisco Discovery Protocol (CDP) messages.”


http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-1942

Switch Spoofing

● Cisco Discovery Protocol● Cisco proprietary Layer 2 protocol● Allows connected Cisco devices to share information

● Operating system● IP address● Routing information● Duplex settings● VTP domain● VLAN information


Switch Spoofing

● CVE-1999-1129● http://www.cvedetails.com/cve/CVE-1999-1129/● “Cisco Catalyst 2900 Virtual LAN (VLAN) switches allow

remote attackers to inject 802.1q frames into another VLAN by forging the VLAN identifier in the trunking tag.”

● Combine with ...

● DTP: Dynamic Trunking protocol. "If a switch port were configured as DTP auto and were to receive a fake DTP packet, it might become a trunk port and it might start accepting traffic destined for any VLAN" (Cisco).● DTP Auto is the default setting!


http://www.cvedetails.com/cve/CVE-1999-1129/

Switch Spoofing

● Dynamic Trunking Protocol● Cisco proprietary Layer 2 protocol● Allows automatic configuration of trunk ports on Cisco

switches● Automatically configures VLAN trunking for all supported

VLANs● Provides ability to negotiate the trunking method with

neighbor devices● Pair this with CDP and your Cisco devices can pretty much

configure themselves (not very securely!)


Switch Spoofing


Switch Spoofing

● Mitigation techniques on physical switches● Disable unused switch ports● Disable CDP and DTP

● Or use on an as need, per port basis!● Restrict the amount of trunk ports

● Should only be configured when connecting devices require it (ie. other switches)

● Limit VLAN access on trunk ports to only what the connected segments require

● Configure all other ports as access ports (no trunking) with no access to the native VLAN

● Don't use Cisco switches...


Switch Spoofing

● Consequences● Attacker's system has a trunk connection to the switch

● Attacker can generate frames for any VLAN supported by the trunk connection

● Attacker can communicate with any device on any of the associated VLANs

● Two-way communication can occur between the attacker and a targeted node because the attacker can actually place themselves on the VLAN

● Also allows attacker to eavesdrop on the traffic within a target VLAN


Switch Spoofing

● Mitigation techniques on physical switches● Disable unused switch ports● Disable CDP and DTP

● Or use on an as need, per port basis!● Restrict the amount of trunk ports

● Should only be configured when connecting devices require it (ie. other switches)

● Limit VLAN access on trunk ports to only what the connected segments require

● Configure all other ports as access ports (no trunking) with no access to the native VLAN

● Don't use Cisco switches...


Double Tagging

● CVE-2005-4440● http://www.cvedetails.com/cve/CVE-2005-4440/● “The 802.1q VLAN protocol allows remote attackers to

bypass network segmentation and spoof VLAN traffic via a message with two 802.1q tags, which causes the second tag to be redirected from a downstream switch after the first tag has been stripped.”

● A.K.A: “Double-Tagging VLAN jumping attack”


http://www.cvedetails.com/cve/CVE-2005-4440/

Double Tagging


Double Tagging


VLAN TagType/Len Data FCS

4 Bytes


VLAN Tag Type/Len Data FCS

4 Bytes

802.1qVLAN Tag

802.1qVLAN Tag

4 Bytes

Dst MAC Src MAC Type/Len Data FCS

802.3 Ethernet Frame Tagged with multiple 4 Byte 802.1q headers – Q-in-Q:

Standard 802.3 Ethernet Frame:

802.3 Ethernet Frame Tagged with 4 Byte 802.1q header:


Double Tagging


Double Tagging

● Consequences● Attacker can send packets to a target VLAN● Targeted system cannot respond back

● Attacking system is on the native VLAN● Target is on an access VLAN isolated from the native VLAN

broadcast domain● Not a good attack for eavesdropping● Excellent method for DoS attacks● Can be used as one way covert channels


Double Tagging

● Mitigation Techniques on physical switches● Do not assign any hosts to VLAN 1 (native VLAN)

● If necessary significantly limit access● Disable VLAN 1 on unnecessary ports

● Change native VLAN on all trunk ports to something different than VLAN 1

● Restrict access to switches by MAC address● Can spoof MAC addresses to get around this

● Heart of this attack is having access to the native VLAN!● This is the default VLAN for all ports on a switch!


Future Work

● What can be done in Virtualized environments?● Switch Spoofing

● Targets vulnerability in Cisco proprietary protocols● Would be useless on non-Cisco based vSwitches● Testing on Cisco Nexus 1000v switches is planned

● Double Tagging● Targets vulnerability in 802.1q standard

● 802.1ad sub-standard● Could potentially work on any vSwitch● Attack requires two or more switches to be successful● Many scenarios can be explored


Future Work

● Scenarios:● Switch Spoofing

● DTP/CDP spoofing attacks● Cisco Nexus 1000v switch (advanced and essentials

editions)● VM → vSwitch (DTP) → VM (VLAN XX)● PC → Switch → vSwitch (DTP) → VM (VLAN XX)● VM → vSwitch (DTP) → Switch → PC (VLAN XX)


Future Work

● Scenarios (cont.):● Double Tagging (requires at least 2 switches)

● PC → Switch → vSwitch → VM● VM → vSwitch → Switch → PC● VM → vSwitch → vSwitch → VM

● Between different environments and vSwitches● VM → vSwitch → Switch → vSwitch → VM

● Between different environments and vSwitches


Future Work

● Lab infrastructure upgrades and design changes are required to safely support test scenarios● Addition of multiple physical switches that support VLANs to

lab and server rack (acquired!)● Direct 1Gb Ethernet connection from lab switch to server rack

switch (waiting on approval)● Connections currently go through multiple campus switches ● Requires facilities to install cabling between lab on 3rd floor

and server room in basement.● Isolation of lab network with router (locating hardware)● Approval of VLAN ID usage from SUNY Poly ITS

administrators (waiting on approval)


Future Work

● Infrastructure and design changes (cont.)● Addition of Cisco Nexus 1000v essentials & advanced

vSwitches in VMWare environments● Two Servers (locating hardware)● Software license fees ~$5000.00 (acquired funding!)

● Academic VMWare vSphere Essentials (purchased)● Academic VMWare vCenter (purchased)● Cisco Nexus 1000v Advanced Edition (purchased)

● DTP/CDP Switch spoofing scenarios● Configuration of VLAN IDs (once approved) on all physical and

virtual switches● Allocation of new target virtual machines on each of the test

VLANs


Conclusion

● All Layer 2 vulnerabilities discussed were targeted towards the virtual networking devices not the hypervisors themselves

● Results show that virtual networking devices CAN be just as vulnerable as their physical counterparts

● Further research and experimentation is necessary to find out more similarities

● XenServer and any other solutions utilizing Open vSwitch are vulnerable to eavesdropping out of the box!

● All environments are vulnerable to manipulation via the DHCP protocol out of the box!


Conclusion


● A single malicious virtual machine has the potential to sniff all traffic passing over a virtual switch

– This can pass through the virtual switch and affect physically connected devices allowing traffic from other parts of the network to be sniffed as well!

● Significant threat to the confidentiality, integrity, and availability (CIA) of data passing over a network in a virtualized muli-tenant environment

● The results of the research presented today provide proof that a full assessment of Layer 2 network security in multi-tenant virtualized network environments is warranted

List of Talks & Publications

● Virtualized Lab Environments for Cost-Effective Hands-On Learning● SUNY ITEC Wizards – Nov. 18th, 2014● R. Bull, N. Merante, J. Vandermaas

● Exploring Layer 2 Network Security in Virtualized Environments● DerbyCon 4.0 “Family Rootz” - Sept. 27th, 2014● R. Bull, J. Matthews

● Migrating a Voice Communications Laboratory to a Virtualized Environment● SIGITE '13 Proceedings of the 14th annual ACM SIGITE conference on

Information Technology education – Oct. 10-12, 2013● R. Bull


List of Talks & Publications

● A Quantitative Study of Virtual Machine Live Migration● CAC '13 Proceedings of the 2013 ACM Cloud and Autonomic Computing

Conference, 2013● W. Hu, A. Hicks, L. Zhang, E. Dow, V. Soni, H. Jiang, R. Bull, J. Matthews

● Design and Implementation of Computer Science Virtualized Lab Environment at SUNYIT● Master's Thesis, May 2012● R. Bull


Proposed Timeline


Proposed Timeline


● Topic selection – completed

● Evaluation of required resources – completed

● Test environment established – completed

● Test environment expansion – ongoing

● Attack vectors defined – completed

● Preliminary results acquired (MAC Flooding) – completed

– Presented at DerbyCon 4.0 in Sept 2014

– Confirmed by Open vSwitch security team● Released patch

Proposed Timeline


● DHCP Attack results acquired – completed

– Accepted for presentation at BsidesRoc, April 25th 2015● MAC flooding and DHCP attack results paper submissions

– MASONS '15 (August 2015)● IEEE International Workshop on Manageabillity and

Security of Network Function Virtualization and Software Defined Network

– DefCon 23 (August 2015): ACCEPTED!!● The world's premier network and computer security

conference – Attracts over 15,000 attendees each year!

Proposed Timeline


● VLAN Hopping results acquired – goal (August 2015)

● ARP Spoofing attack results acquired – goal (December 2015)

● Submit new results for publication:

– DerbyCon 5.0 in Sept 2015

– Various USENIX conferences

– DefCon 24 in August 2016

● Identify mitigation and hardening techniques – goal (September 2016)

Proposed Timeline


● Submit mitigation and hardening techniques paper – (Fall 2016 – Spring 2017)

– Various USENIX conferences

– MASONS

– DerbyCon

– DefCon

● Dissertation first full draft – goal (December 2016)

● Dissertation final copy submissions – goal (March 2017)

● Dissertation defense – goal (April 2017)

References


● Accuvant Labs. Bourne again shell (bash) remote code execution vulnerability - bashshell shock advisory. Retrieved Oct 5, 2014 from http://files.accuvant.com/web/file/c18f38696677495085074e51178da52b/Bash%20ShellShock%20Advisory.pdf.

● Altunbasak, H., Krasser, S., Owen, H. L., Grimminger, J., Huth, H.-P., andSokol, J. Securing layer 2 in local area networks. In ICN’05 Proceedings of the 4th in-ternational conference on Networking - Volume Part II (2005), pp. 699–706.

● Ayuso, P. N., McHardy, P., Kadlecsik, J., Leblond, E., and Westphal, F. Thenetfilter.org project. Retrieved Oct 21, 2014 from http://www.netfilter.org.

● Baker, Morris, CCNA Security 640-554 Official Cert Guide, Cisco Press. July 2012.

● Barjatiya, S., and Saripalli, P. Blueshield: A layer 2 appliance for enhancing isola-tion and security hardening among multi-tenant cloud workloads. In 2012 IEEE/ACM Fifth International Conference on Utility and Cloud Computing (2012), pp. 195–198.

http://www.netfilter.org/

References


● Buhr, A., Lindskog, D., Zavarski, P., and Ruhl, R. Media access control address spoof-ing attacks against port security. In WOOT’11: Proceedings of the 5th USENIX conference on Offensive technologies (2011), pp. 1–1.

● Bull, R. Design and implementation of computer science virtualized lab environment.Retrieved Oct 19, 2014 from http://web.cs.sunyit.edu/~bullr/publications/bullr_thesis.pdf.

● Bull, R. Exploring layer 2 network security in virtualized environments. Retrieved Oct 19,2014 from http://youtu.be/tLrNh-34sKY.

● Bull, R. Migrating a voice communications laboratory to a virtualized environment. In SIGITE ’13 Proceedings of the 14th annual ACM SIGITE conference on Information Technology education (2013), pp. 189–194.

● Cabuk, S., Dalton, C., Ramasamy, H., and Schunter, M. Towards automated provi-sioning of secure virtualized networks. In CCS ’07, Proceedings of the 14th ACM conference on Computer and communications security (2007), pp. 235–245.

http://youtu.be/tLrNh-34sKY

References


● CentOS. The centos project. Retrieved Oct 21, 2014 from http://www.centos.org.

● Cisco Systems, Inc. Catalyst 6500 release 12.2sx software configuration guide.Retrieved May 12, 2014 from http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/pref.html.

● Cisco Systems, Inc. Cisco nexus 1000v series switches for vmware vsphere datasheet. Retrieved November 29, 2013 from http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/data_sheet_c78-492971.html.

● Cisco Systems, Inc. Dynamic Trunking Protocol. Retrieved February 3rd, 2014 from http://www.cisco.com/c/en/us/tech/lan-switching/dynamic-trunking-protocol-dtp/index.html

● Cisco Systems, Inc. Configuring Cisco Discovery Protocol on Cisco Routers and Switches Running Cisco IOS . Retrieved February 3rd, 2014 from: http://www.cisco.com/c/en/us/support/docs/network-management/discovery-protocol-cdp/43485-cdponios43485.html

http://www.cisco.com/c/en/us/tech/lan-switching/dynamic-trunking-protocol-dtp/index.html

References


● Cisco Systems, Inc. Stacked VLAN Processing. Retrieved February 3rd, 2014 from: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/qinq.html

● Cisco Systems, Inc. Understanding VLAN Trunk Protocol (VTP). Retrieved February 3rd, 2014 from: http://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/10558-21.html

● Clark, B., Deshane, T., Dow, E., Evanchik, S., Finlayson, M., Herne, J., andMatthews, J. N. Xen and the art of repeated research. In USENIX 2004 Proceedings of the Annual Technical Conference - FREENIX Track (2004), pp. 135–144.

● die.net. dhcp-options - linux man page. Retrieved Oct 5, 2014 from http://linux.die.net/man/5/dhcp-options.

● ELinks. Elinks full-featured text www browser. Retrieved Oct 21, 2014 from http://www.elinks.or.cz.

● Gentoo Bugzilla. Bug 491672 - =net-misc/openvswitch-2.0.0 - install: cannot stat ’brcom-pat.ko’: No such file or directory. Retrieved December 4, 2013 from https://bugs.gentoo.org/show_bug.cgi?id=491672/.

References


● Gentoo Wiki. Qemu with open vswitch network. Retrieved December 4, 2013 from http://wiki.gentoo.org/wiki/QEMU_with_Open_vSwitch_network/.

● Hu, W., Hicks, A., Zhang, L., Dow, E., Soni, V., Jiang, H., Bull, R., and Matthews, J. A quantitative study of virtual machine live migration. In CAC ’13, Pro-ceedings of the 2013 ACM Cloud and Autonomic Computing Conference (2013), p. Article No. 11.

● Information Security Stack Exchange. bash - shellshock dhcp exploitation.Retrieved Oct 19, 2014 from http://security.stackexchange.com/questions/68877/shellshock-dhcp-exploitation.

● Kali Linux. The most advanced penetration testing distribution, ever. Retrieved November 29, 2013 from http://www.kali.org/.

● LAN MAN Standards Committee. IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges. The Institute of Electrical and Electronics Engineers, Inc., New York, NY, 2004.

References


● LAN MAN Standards Committee. IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks (802.1Q). The Institute of Electrical and Electronics Engineers, Inc., New York, NY, 2003.

● LAN MAN Standards Committee. IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges (802.1ad). The Institute of Electrical and Electronics Engineers, Inc., New York, NY, 2005.

● Lauerman, K., and King, J. Stp mitm attack and l2 mitigation techniques on the ciscocatalyst 6500. Retrieved May 12, 2014 from http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_605972.pdf/.

● Microsoft. Hyper-v virtual switch overview. Retrieved May 18, 2014 from http://technet.microsoft.com/en-us/library/hh831823.aspx.

● Microsoft. What is server core? Retrieved June 4, 2014 from http://msdn.microsoft.com/en-us/library/dd184075.aspx.

References


● National Vulnerability Database. Cve-2014-6271. Retrieved Oct 5, 2014 from http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271.

● National Vulnerability Database. Cve-2014-7169. Retrieved Oct 5, 2014 from http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169.

● National Vulnerability Database. Cve-2005-1942/ Retrieved Feb 3. 2015 from https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-1942

● National Vulnerability Database. Cve-1999-1129/ Retrieved Feb 3. 2015 from https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-1129

● Open Networking Foundation. Software-defined networking: The new norm for net-works. Retrieved May 13, 2014 from https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf.

● Open vSwitch. How to install open vswitch on linux, freebsd and netbsd. Retrieved December 4, 2013 from http://git.openvswitch.org/cgi-bin/gitweb.cgi p=openvswitch;a=blob_plain;f=INSTALL;hb=HEAD/.

References


● Open vSwitch. Production quality, multilayer open virtual switch. Retrieved November 29, 2013 from http://openvswitch.org.

● Pettit, J., Gross, J., Pfaff, B., Casado, M., and Crosby, S. Virtual switching inan era of advanced edges. In ITC 22 2nd Workshop on Data Center - Converged and Virtual Ethernet Switching (DC-CAVES) (2010).

● Pfaff, B., Pettit, J., Koponen, T., Amidon, K., Casado, M., and Shenker, S. Extending networking into the virtualization layer. In HotNets-VIII (2009).

● Rouiller, S. VLAN Security: weaknesses and countermeasures - v1.4b. SANS Institute.

● Saripalli, P., and Walters, B. Quirc: A quantitative impact and risk assessment frame-work for cloud security. In 2010 IEEE 3rd International Conference on Cloud Computing (2010), pp. 280–288.

● Seifert, R., and Edwards, J. The All-New Switch Book. Wiley Publishing, Inc., Indi-anapolis, Indiana, 2008.

http://openvswitch.org/

References


● thekellys.org. Dnsmasq - network services for small networks. Retrieved Oct 19, 2014 from http://www.thekelleys.org.uk/dnsmasq/doc.html.

● TrustedSec. Shellshock dhcp rce proof of concept. Retrieved Oct 5, 2014 from https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/.

● VMware Inc. Vmware vsphere end user license agreement. Retrieved May 21, 2014 from http://www.vmware.com/download/eula/esxi50_eula.html.

● Xen Networking. Setting up open vswitch networking. Retrieved December 4, 2013 from http://wiki.xen.org/wiki/Xen_Networking#Setting_up_Open_vSwitch_networking/.

● Yeung, K.-H., Fung, D., and Wong, K.-Y. Tools for attacking layer 2 network infras-tructure. In IMECS ’08 Proceedings of the International MultiConference of Engineers and Computer Scientists (2008), pp. 1143–1148.

critical analysis of layer 2 network security in...

Documents