Critical Analysis of Layer 2 Network Security in Virtualized Environments. Computer Science Ph.D. Dissertation Proposal. Ronny L.

(1)

Critical Analysis of Layer 2 Network Security

in Virtualized Environments

Computer Science

Ph.D. Dissertation Proposal

(2)

Introduction

●

Cloud Services

– Offer customers virtual server hosting in multi-tenant

environment

s

●

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

(3)

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

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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

(9)

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

(10)

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

(11)

Potential to Succeed

●

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

(12)

Test Environment

A.K.A.

SUNY Poly

Cloud Security

Research Lab

(13)

Potential to Succeed

●

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

(14)

Background

●

Virtualization Overview

●

Multi-Tenancy

●

Virtual Networking

– Bridges – Switches

(15)

Virtualization Overview

(16)

Virtualization Overview

(17)

Virtualization Overview

(18)

Virtualization Overview

(19)

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

(20)

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

(21)

Multi-Tenancy

(22)

Multi-Tenancy

(23)

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

(24)

Bridging

(25)

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”

(26)

Virtual Bridging

(27)

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!

(28)

Ethernet Frame

Preamble 8 Dest. Address 6 Source Address 6 Type / Length 2 Data ~ FCS 4 Preamble 8 Dest. Address 6

What the switch needs to match against its CAM

(29)

Switching

(30)

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

(31)

Virtual Switches

(32)

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

(33)

What If?

(34)

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

(35)

MAC Flooding Attack

(36)

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

(37)

MAC Flooding

(38)

MAC Flooding

(39)

(40)

MAC Flooding

(Performance Degradation)

(41)

MAC Flooding

●

Reported Open vSwitch vulnerability to:

● cert.org

● Assigned VU#784996

●

[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

(42)

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

(43)

DHCP Attacks

(44)

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

(45)

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

(46)

DHCP Protocol

Client – Server Model

(47)

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

–

(48)

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

(49)

DHCP Attacks

Duplicate 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

(50)

DHCP Attacks

Duplicate Addressing

●

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

(51)

DHCP Attacks

Duplicate Addressing

(52)

DHCP Attacks

Rogue 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

(53)

DHCP Attacks

Rogue DNS Server

(54)

DHCP Attacks

Incorrect 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

(55)

DHCP Attacks

Malicious 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

(56)

DHCP Attacks

Malicious Honeynet

(57)

DHCP Attacks

Remote 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

(58)

DHCP Attacks

Remote Execution of Code

●

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 /

(59)

DHCP Attacks

Remote Execution of Code

(60)

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)

(61)

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 Updated Simple Router - (IPTables) 2

CentOS 6.5

(minimal) Fully Updated Apache 2 (Web) 1

CentOS 6.5

(62)

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

(63)

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

(64)

(65)

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!

(66)

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

(67)

Looking Ahead

VLAN Hopping Attacks

(68)

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

(69)

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

(70)

Virtual LAN Concepts

●

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

(71)

Virtual LAN Concepts

●

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

(72)

Virtual LAN Concepts

●

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

(73)

Virtual LAN Concepts

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

(74)

Virtual LAN Concepts

●

Ethernet frames are modified for VLAN traffic:

● Addition of a 802.1q VLAN header

● 32 bits of extra information wedged in

Dst MAC Src MAC _{VLAN Tag Type/Len}802.1q Data FCS 4 Bytes

TPID

0x8100 (3 bits)TPI (1 bit)DEI (12 bits)VID

2 Bytes _{2 Bytes}

(75)

Virtual LAN Concepts

●

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 _{VLAN Tag}802.1q Type/Len Data FCS 4 Bytes

Dst MAC Src MAC _{VLAN Tag}802.1q Type/Len Data FCS 4 Bytes 802.1q VLAN Tag 802.1q VLAN Tag 4 Bytes

(76)

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

(77)

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.”

(78)

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

(79)

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!

(80)

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!)

(81)

Switch Spoofing

(82)

Switch Spoofing

(83)

Switch Spoofing

(84)

Switch Spoofing

(85)

Switch Spoofing

(86)

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...

(87)

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

(88)

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...

(89)

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”

(90)

Double Tagging

(91)

Double Tagging

(92)

Double Tagging

Dst MAC Src MAC _{VLAN Tag}802.1q Type/Len Data FCS 4 Bytes

Dst MAC Src MAC _{VLAN Tag}802.1q Type/Len Data FCS 4 Bytes 802.1q VLAN Tag 802.1q VLAN 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:

(93)

Double Tagging

(94)

Double Tagging

(95)

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

(96)

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!

(97)

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

(98)

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)

(99)

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

(100)

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)

(101)

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

(102)

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!

(103)

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

(104)

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

(105)

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

(106)

Proposed Timeline

(107)

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

(108)

Proposed Timeline

●

DHCP Attack results acquired – completed

–

Accepted for presentation at BsidesRoc, April 25

th

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

(109)

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

(110)

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)

(111)

References

● Accuvant Labs. Bourne again shell (bash) remote code execution vulnerability - bash

shell 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., and

Sokol, 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. The

netfilter.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.

(112)

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.

(113)

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 data

sheet. 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

(114)

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., and

Matthews, 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/.

(115)

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.

(116)

References

Virtual Bridged Local Area Networks (802.1Q). The Institute of Electrical and Electronics Engineers, Inc., New York, NY, 2003.

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 cisco

catalyst 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.

(117)

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/.

(118)

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 in

an 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.,

(119)

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.