here - FTP Directory Listing

Transcription

Critical Analysis of Layer 2 Network Security
in Virtualized Environments
Computer Science
Ph.D. Dissertation Proposal
Ronny L. Bull
Introduction
●
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
© 2015 Ronny L. Bull - Clarkson University
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 Poly
Cloud 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
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
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
Source
Address
6
Preamble
Dest.
Address
6
8
Type /
Length
2
Data
FCS
~
4
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
●
●
●
DHCP Attack Scenarios
●
●
●
Attack Overview
Summary of Results
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
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
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 Protocol
Client – 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
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 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
Then 10.1.2.101 … 102 … 103 ... etc ...
DHCP Attacks
●
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 Attacks
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
–
PII or other sensitive information is harvested by the attacker
DHCP Attacks
Rogue DNS Server
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
–
Unable to access other resources on subnets or the Internet
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
DHCP Attacks
Malicious Honeynet
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
●
–
DHCP Attacks
●
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 Attacks
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 Updated
Simple Router (IPTables)
2
CentOS 6.5
(minimal)
Fully Updated
Apache 2 (Web)
1
CentOS 6.5
(minimal)
No Updates
Left vulnerable to
Shell Shock
1
●
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
●
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 Ahead
VLAN 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
●
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
Standard 802.3 Ethernet Frame
Dst MAC
Src MAC
Type/Len
Data
FCS
●
Ethernet frames are modified for VLAN traffic:
●
Addition of a 802.1q VLAN header
● 32 bits of extra information wedged in
4 Bytes
Dst MAC
Src MAC
TPID
0x8100
2 Bytes
802.1q
Type/Len
VLAN Tag
TPI
(3 bits)
DEI
(1 bit)
Data
VID
(12 bits)
2 Bytes
FCS
●
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
4 Bytes
Dst MAC
Src MAC
802.1q
Type/Len
VLAN Tag
4 Bytes
Dst MAC
Src MAC
Data
FCS
4 Bytes
802.1q
802.1q
Type/Len
VLAN Tag VLAN Tag
Data
FCS
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.”
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!
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
Switch Spoofing
Switch Spoofing
Switch Spoofing
Switch Spoofing
●
Mitigation techniques on physical switches
●
●
●
●
●
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 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”
Double Tagging
Double Tagging
Double Tagging
Dst MAC
Src MAC
Type/Len
Data
FCS
Standard 802.3 Ethernet Frame:
4 Bytes
Dst MAC
Src MAC
802.1q
Type/Len
VLAN Tag
Data
FCS
802.3 Ethernet Frame Tagged with 4 Byte 802.1q header:
4 Bytes
Dst MAC
Src MAC
4 Bytes
802.1q
802.1q
Type/Len
VLAN Tag VLAN Tag
Data
FCS
802.3 Ethernet Frame Tagged with multiple 4 Byte 802.1q headers – Q-in-Q:
Double Tagging
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 multitenant virtualized network environments is warranted
List of Talks & Publications
●
Virtualized Lab Environments for Cost-Effective Hands-On Learning
●
●
●
Exploring Layer 2 Network Security in Virtualized Environments
●
●
●
SUNY ITEC Wizards – Nov. 18th, 2014
R. Bull, N. Merante, J. Vandermaas
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 - 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 international 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 isolation and security hardening among multi-tenant cloud workloads. In 2012 IEEE/ACM Fifth
International Conference on Utility and Cloud Computing (2012), pp. 195–198.
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.
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/43485cdponios43485.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 3 rd, 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/.
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
●
●
●
●
●
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.
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 networks. 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 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 framework 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., Indianapolis, Indiana, 2008.
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 infrastructure. In IMECS ’08 Proceedings of the International MultiConference of Engineers and
Computer Scientists (2008), pp. 1143–1148.

here - FTP Directory Listing

Transcription

Similar documents

5 Star TransitionRight™ Bulls… Savings of up to

Koloman Sokol - psabuba.edu.sk

Daily Bull 2012-2

Here are some of the Game Camera Pics for

Daily Bull 2012-04-04

THE BULL INN - Shepherd Neame

Inside this issue Uplifting to Upchucking

The Smart Housing Project

Daily Bull 2010-2

Red Bull BC One World Final 2015 in Rome (ITA)