VLAN Hopping, ARP Poisining & Man-In-The_Middle Attacks in Virtualized Environments
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 93 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/36286 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2425 / 93
4
6
7
11
15
20
26
33
34
35
36
39
40
46
49
53
58
62
63
66
68
72
79
90
92
93
00:00
Virtual LANIntegrated development environmentDynamic Host Configuration ProtocolVirtualizationService (economics)MultiplicationCloud computingImplementationComputer networkVirtual realityInformation securityComputing platformSoftware testingComputing platformPoint cloudThermodynamisches SystemClient (computing)Revision controlConnected spaceComputer networkBridging (networking)Roundness (object)NeuroinformatikVideoconferencingVirtual LANCloud computingSoftware testingDiagramComputing platformHydraulic jumpRevision controlPeripheralThermodynamisches SystemComputer networkLevel (video gaming)Inclusion mapMultiplication signPresentation of a groupType theoryVirtual machineStudent's t-testSensitivity analysisSocial classComputer scienceData centerComputer networkVirtual realityPhysicalismBridging (networking)Information securityVirtualizationInterface (computing)Demo (music)Latent heatFaculty (division)Context awarenessBitDenial-of-service attackMultiplicationArc (geometry)Metropolitan area networkComputer animation
03:06
Computer networkIntegrated development environmentConnected spaceComputer networkService (economics)AuthorizationMultiplicationThermodynamisches SystemPerformance appraisalVirtual LANSoftware testingDenial-of-service attackPhysicalismVirtual LANPeripheralVulnerability (computing)Computer networkComputer networkHydraulic jumpCASE <Informatik>Thermodynamisches SystemSoftware testingMetropolitan area networkComputing platformVirtualizationResultantLine (geometry)BitComputer animation
04:33
Thermodynamisches SystemSoftware testingServer (computing)Computer hardwareHill differential equationUser interfaceThermodynamisches SystemMereologyData recoverySoftware testingComputer hardwareVirtualizationComputer network
05:18
System programmingComputer hardwareThermodynamisches SystemServer (computing)HypercubeCore dumpBefehlsprozessorQuadrilateralWhiteboardComputer networkInterface (computing)Thermodynamisches SystemComputer networkDifferent (Kate Ryan album)VirtualizationReading (process)Software testingDenial-of-service attackComputer hardwareGroup actionGoodness of fitDiagramInterface (computing)Hacker (term)Set (mathematics)Regular graphInternetworkingXMLDiagram
06:21
Computer networkInterface (computing)Bridging (networking)Computing platformControl flowVirtual realityVirtual LANComputer networkStandard deviationFrame problemAuthorizationComputer networkComputer networkVirtualizationThermodynamisches SystemVulnerability (computing)Point (geometry)Software testingFrame problemMixed realityRight angleAuthorizationTwitterStandard deviationGame controllerCommunications protocolDoubling the cubePhysicalismVirtual LANGraph (mathematics)ResultantOpen setExploit (computer security)Interface (computing)Surjective functionComputing platformInformationHypercubeComputer animation
08:51
Frame problemVirtual LANEmailAdditionInformationInformation securityMessage passingCommunications protocolConnected spaceThermodynamisches SystemAddress spaceDuplex (telecommunications)Time domainVirtual LANBitInformationComputer networkEmailFrame problemConnected spaceView (database)Information securityVulnerability (computing)Thermodynamisches SystemProxy serverMessage passingCommunications protocolComputer animation
09:38
Local area networkVirtual LANFrame problemNetwork socketWireless LANVirtual realityMereologyCommunications protocolThermodynamisches SystemWide area networkTelecommunicationAsynchronous Transfer ModeVirtual LANThermodynamisches SystemHoaxVulnerability (computing)1 (number)Configuration spaceProduct (business)Communications protocolTelecommunicationSet (mathematics)Frame problemDynamical systemConnected spaceMessage passingDefault (computer science)Computer networkCube
10:50
Demo (music)Thermodynamisches SystemDemo (music)Bridging (networking)Default (computer science)VirtualizationLink (knot theory)Virtual machineVideoconferencingYouTubeComputer animation
11:29
VMware ESX ServerYouTubeVideoconferencingLink (knot theory)Virtual machineComputer networkInterface (computing)Connected spaceVirtual LANDefault (computer science)VirtualizationComputer networkSoftware testingGreatest elementThermodynamisches SystemAsynchronous Transfer ModeSet (mathematics)CASE <Informatik>Server (computing)Right angleConfiguration spaceVideo game consoleEncapsulation (object-oriented programming)Program flowchartComputer animation
13:01
Dynamical systemComputer networkThermodynamisches SystemType theoryDefault (computer science)Interface (computing)Sound effectAsynchronous Transfer ModeCommunications protocolComputer programmingCASE <Informatik>Interactive televisionFlow separationEncapsulation (object-oriented programming)Line (geometry)Source code
14:20
Game controllerLocal area networkMereologyBasis <Mathematik>Virtual LANThermodynamisches SystemResultantWhiteboardComputer networkControl systemOpen sourceBasis <Mathematik>Bridging (networking)VirtualizationUsabilityGame controllerPhysicalismVirtual LANVirtual realityPeripheralConnected spaceComputer animation
15:57
Virtual LANProxy serverComputer networkMessage passingComputer networkMessage passingVirtual LANCommunications protocolProxy server1 (number)Normal (geometry)Thermodynamisches SystemVirtual machineDataflowFrame problemConnected spaceSingle-precision floating-point formatPairwise comparisonType theoryComputer animationDiagramProgram flowchart
17:00
Polar coordinate systemVirtual LANFrame problemEmailStandard deviationWide area networkMenu (computing)Thermodynamisches SystemDensity of statesTime domainBroadcasting (networking)EmailDoubling the cubeDifferent (Kate Ryan album)Connected spaceStandard deviationFrame problemDomain nameVirtual LANThermodynamisches SystemType theoryPairwise comparisonGreatest elementDenial-of-service attackCASE <Informatik>1 (number)Computer networkBroadcasting (networking)Goodness of fitSound effect
18:30
Link (knot theory)Demo (music)Inclusion mapCASE <Informatik>Multiplication signVideoconferencingVirtual realityDemo (music)Virtual LANLink (knot theory)Thermodynamisches SystemGame controllerVirtualizationServer (computing)Computer animation
19:41
Thermodynamisches SystemSet (mathematics)Encapsulation (object-oriented programming)Interface (computing)Server (computing)Configuration spaceAsynchronous Transfer ModeComputer animation
20:37
Set (mathematics)Thermodynamisches SystemComputer networkServer (computing)Interface (computing)Virtual LANClient (computing)Core dumpCommunications protocolAddress spaceSource codeIP addressFrame problemVirtual realityGreatest elementDoubling the cubeComputer fileLocal ringoutputTheory of everythingBoom (sailing)Multiplication signBitSoftware testingDefault (computer science)2 (number)Computer animationSource code
23:35
YouTubeHypercubeDemo (music)Vulnerability (computing)Hyper-VVirtualizationThermodynamisches SystemCASE <Informatik>1 (number)PhysicalismComputer animation
24:18
Data centerComputer networkVirtual machineVirtual LANThermodynamisches SystemCASE <Informatik>Connected spaceCommunications protocolEncapsulation (object-oriented programming)BitMultiplication signConfiguration spacePhysicalismSoftware testingInterface (computing)Interface (computing)Computer networkComputer networkDifferent (Kate Ryan album)Greatest elementPhysical systemIP addressVirtualizationWhiteboardCore dumpSet (mathematics)Surjective functionResultant
27:53
Smith chartHypercubeInclusion mapLipschitz-StetigkeitMechanism designDemosceneCASE <Informatik>Standard deviationThermodynamisches SystemException handlingAddress spaceServer (computing)Set (mathematics)SoftwareOpen setOpen sourceBridging (networking)Computer networkResultantVirtual machineDenial-of-service attackSource codeComputer animation
29:19
Virtual LANLimit (category theory)MathematicsAddress spaceComputer networkCache (computing)InformationTranslation (relic)Gateway (telecommunications)Direct numerical simulationServer (computing)Broadcasting (networking)Time domainThermodynamisches SystemSystem programmingImage resolutionProcess (computing)Radio-frequency identificationComputer networkBit1 (number)PeripheralLimit (category theory)Standard deviationDifferent (Kate Ryan album)Software testingIntegrated development environmentAddress spaceVirtual LANCommunications protocolIP addressProcess (computing)Direct numerical simulationImage resolutionThermodynamisches SystemMappingPhysicalismComputer networkInformationGateway (telecommunications)Cache (computing)LogicBroadcasting (networking)Default (computer science)Demo (music)Computer animation
31:02
Demo (music)Virtual machineGateway (telecommunications)IP addressDefault (computer science)GoogolCore dumpCache (computing)Scripting languageRight angleAddress spaceRouter (computing)Electronic visual displayTouchscreenResultantComputer animation
33:28
Thermodynamisches SystemHypercubeFreewareVirtual realitySoftware developerUtility softwareComputer networkDynamic Host Configuration ProtocolRevision controlResultantComputing platformThermodynamisches SystemDynamical systemMathematicsService (economics)Validity (statistics)Computer networkSource codeComputer animation
34:10
Computer networkVirtual realitySystem programmingThermodynamisches SystemSoftware testingInformation securityGradientEnterprise architectureVirtual machineVector potentialMereologyConnected spaceComputer networkData integrityImplementationIntegrated development environmentMultiplicationInternet service providerEncryptionService (economics)Computer networkWorkloadEnterprise architectureContext awarenessVirtualizationEncryptionPhysicalismAdditionService (economics)Thermodynamisches SystemGradientMeasurementInformation securityComputer networkGreatest elementVirtual machineINTEGRALLine (geometry)MereologyGame controllerInternet service providerImplementationStrategy gameResultantSoftware testingPoint cloudMultiplicationComputer animation
36:21
Software testingIntegrated development environmentEmailLink (knot theory)Demo (music)Presentation of a groupVideoconferencingVirtual realitySoftware testingConditional-access moduleVideoconferencingTerm (mathematics)Thermodynamisches SystemGame controllerServer (computing)Open sourceScripting languageTrailStudent's t-testMonster groupComplex (psychology)DemonVirtualizationSemiconductor memoryTable (information)MiniDiscMultiplication signoutputPerfect groupDifferent (Kate Ryan album)HypermediaQuicksortBuffer overflowInformation securityVirtual machineEndliche ModelltheorieComputer networkService (economics)AdditionVulnerability (computing)BefehlsprozessorIntegrated development environmentRevision controlFeedbackHuman migrationResultantCuboidDefault (computer science)Daylight saving timeOpen setZoom lensGoodness of fitCondition numberWebsiteDemo (music)Type theoryPresentation of a groupEmailPoint (geometry)Computer animation
41:46
Thermodynamisches SystemSoftware testingCumulative distribution functionComputer hardwareLastteilungCartesian coordinate systemCore dumpPresentation of a groupClient (computing)MereologyInformationThermodynamisches SystemEncapsulation (object-oriented programming)Doubling the cubeFront and back endsEncryptionLecture/Conference
43:27
Software developerUtility softwareRevision controlDynamic Host Configuration ProtocolComputer networkThermodynamisches SystemFreewareVirtual realitySlide ruleCuboidIntegrated development environmentComputer networkCodeServer (computing)Dynamical systemMedical imagingUtility softwareDifferent (Kate Ryan album)
44:22
Integrated development environmentThermodynamisches SystemEmailSign (mathematics)Line (geometry)CuboidLecture/Conference
Transcript: English(auto-generated)
00:00
Uh so uh we're gonna get this next talk started. Uh let's get a big round of applause for them. We've got at least one new speaker. How is anybody? Two? Yeah? Alright. Hey everybody three for the price of one. My name is Gina Matthews and I'm a computer
00:20
science professor at Clarkson University in way way upstate New York. Nosebleed New York as we like to affectionately call it right across from uh Canada. Uh Ronnie Bull is both a PhD student with me at Clarkson and also a faculty member at Utica College. And Caitlin Trumbull uh is a senior undergraduate who's been helping us run all of these attacks that we're gonna tell you about. In particular we're gonna talk about VLAN hopping
00:41
and arc poisoning and man in the middle attacks in virtualized environments. And this is a bit of a follow on from the presentation we did last year at Def Con. So here's a little road map of what we're gonna do. We're gonna talk about the context of the problem for layer 2 network security in virtualized environments. The problem in multi tenant environments especially in cloud services. We're gonna talk about the test
01:04
platforms that we used. And all of the different virtual uh the hypervisors and the virtual network uh devices that we tested. And we're gonna talk about the specifics of the attacks. We've got some uh great videos and demos to show you. Specifically of the
01:21
uh VLAN hopping and arc poisoning this time. We also have videos and many many details of the map flooding and DHCP attacks that we talked about last year. If you wanna look those up. And finally some conclusions. So um the key question is when you have virtual machines that are hosted in a multi tenant environment, how safe are they? What
01:45
can they do to each other over the network? Um they're essentially connected to a virtual version of a physical networking device. And the question we're trying to answer is the layer 2 network attacks that typically work on physical devices, do those work on their virtual counterparts as well? And if so, what are the implications especially in a
02:05
multi tenant environment? Cloud services that rely on these virtualized environments could be vulnerable and that can include data centers hosting mission critical or sensitive data. This is not the only class of attacks from co-located virtual machines. It's kind of an old story. You're vulnerable to those that are close to you
02:23
but in a public kind of multi tenant environment you're not quite sure who you land next to. And um we've done some other work in the past of the you know the types of things that virtual machines can do to each other as have many other people. But in particular today we're talking about the attacks over the network. So here's a pretty simple
02:44
diagram of the setup we're worried about. We have a physical host here and on it we are hosting a bunch of virtual machines. One of them that's a nasty malicious one that's gonna do things to the other uh victims and they're you can see they're sharing a
03:01
virtual switch or bridge and that's passed through to a physical network interface. And to kind of jump ahead, the bottom line is that we do see in our research that virtualized network devices have the same ability to be exploited as physical devices. Sometimes we see more vulnerabilities in physical devices, sometimes in certain cases we
03:23
see less than a physical device and we're gonna show you that uh for the attacks we're talking about today. Another interesting thing we've seen is that um some of these attacks allow have the ability to weave the virtualized environment and affect the physical networks that they're connected to as well. So that's another interesting bonus for you. What are some of the consequences if a malicious VM successfully launches a
03:47
network attack in a multi-tenant environment like this? What are some of the things that they could do? Well they could capture all the network traffic coming from the victims that are co-located with them, they could redirect traffic, they could perform man in
04:01
the middle attacks, denial of service attacks, they could gain unauthorized access to restricted subnets and they could affect performance which is I guess a sub example of denial of service. So here are some of the test scenarios and results that we're gonna be talking about. We're gonna give you a little update on MAC flooding uh especially
04:22
because we've changed over our testing platform completely since we spoke here last year. We're gonna talk about VLAN hopping in quite a bit of detail. Also art poisoning and some man in the middle attacks. Here is a lovely picture of the test environment that we were using last year. It was pretty much built from pieces and
04:41
parts that we could salvage. Rest in peace you've served us well, thank you very much. Um here are for uh complete details uh some of the hardware specs and the hypervisors and the virtual uh networking devices that we were testing when we spoke to you last year. All of those details are on the Defcon 23 CD. Um we have nice new shiny hardware uh
05:05
thank you Utica college for that. Um and it allowed us to basically repeat all of the experiments we did before and just eat you know a much more um controlled environment than our pieces and parts and also extend the work. So here is some of the gory details of
05:23
the test environment that we used this year. You can see a lot of different hypervisors, a lot of different virtual networking devices and you can see some details here of the hardware specs. Again all of the gory details are available for your reading enjoyment um in the Defcon docs. Okay so to kick things off and also just to
05:44
provide a good um transition between what we did last year and this year. Gonna give you a little update on the MAC flooding stuff. First you know here's a simple diagram of the scenario in which we're doing MAC flooding attacks. Again we have 2 VMs attached to a virtual switch. We have a victim, the target VM and we have an attacker that's patched
06:04
through to a physical interface that connects to a physical switch and the internet beyond. And the target VM is just doing a set of regular pings and we're gonna see what happens to the performance of those pings when the attacker launches a MAC flooding attack. And
06:22
here in this uh graph which is something we showed you last year, you can see um from like 0 to 65 or 70 or so what was happening when it wasn't under attack. So low latency pings, no trouble. You can clearly see when the attack gets launched and you can see just after 2.40 when the attack stops. You can see clear impact on the network
06:44
performance for the the victim VM. And this was done on gen 2 in the zen bridged interface. And this gives you just a sense of you know we're just doing a lot more systems and platforms this year. So this is the same test performed across not just um
07:02
that gen 2 uh zen bridged but also gen open uh excuse me zen open v switch, citrix zen server, hyper v standard switch, hyper v nexus 1000 v, the prox mox bridged, VMware ESXi and a control physical switch, a Cisco 2950. And um so some of those when
07:23
the attack starts don't, aren't affected. It's a little difficult to read from this this graph. Maybe it's a little easier to read here. Still not incredibly easy. We did we realized at the last minute there might have been a better way to do this one. But um from this uh if you look carefully you can see that the hyper v standard, the hyper v nexus,
07:43
um VMware ESXi were not vulnerable. Um and uh I'd like to make the point before we head into some of the rest of the things that all of these layer 2 vulnerabilities that we're discussing were targeted toward the virtual networking devices not so much the hypervisors themselves. What we're testing is what happens with the virtual
08:03
networking devices. So it's interesting you see a mix right? Not everything's vulnerable, not everything is safe and we're gonna see that trend continue across all of our tests. It wasn't uniform, which things were vulnerable and which things weren't. At this point I'm gonna pass it over to Ronnie who's gonna tell you about the VLAN hopping.
08:23
Okay so we've performed a few VLAN hopping experiments on the environments as well to see what we could do um about getting frames onto unauthorized networks. Uh we found some interesting results. So some basics about VLAN hopping attacks um just allowing unauthorized unauthorized access to another virtual LAN on a packet switch network. Um 2
08:40
methods of doing this currently uh switch spoofing and double tagging where switch spoofing is Cisco proprietary um using Cisco protocols uh and double tagging is an exploitation of the 802.1Q protocol. Uh so basic virtual LAN information we have a basic frame uh ethernet frame here and what we do to get VLAN going is uh we stick a 4 byte um tag in there or VLAN header with 32 bits of extra information um to support the VLAN
09:05
ID to show where that frame is supposed to go on the correct networks. So switch spoofing, here's a CVE listed um about Cisco switches that if they support 802.1X security allow attackers to bypass port security and gain access to the VLAN uh via spoof Cisco discovery protocol messages. So a little bit about the Cisco discovery
09:22
protocol. Basically it's a proprietary protocol that Cisco has on their switches that allows 2 or more switches to identify each other's operating systems, automatically negotiate connections, things like that. So if we can have a vulnerability in that protocol and actually exploit it we can get on a different VLAN. Couple more CVEs and
09:40
vulnerabilities for switch spoofing uh Cisco catalyst 2900 virtual LAN switches allow remote attackers to inject 802.1Q frames into another VLAN just by forging the ID tag um and a quote directly from Cisco from one of their white papers about dynamic trunking protocol. Basically if it's enabled um you can send a fake DTP packet out and switch that port from auto into a trunking mode and we're gonna see that as pretty
10:04
effective across some of the environments. Um and it's important to note that on most Cisco switches out there at least some of the earlier ones that are still in production today um DTP auto is the default setting so you want to make sure you uh harden that. Okay so again this is just another Cisco proprietary layer 2 protocol um allowing you to do that automatic configuration of trunking connections between 2
10:25
switches. Um pair this with CDP and you'll pretty much have a automatically configured network. So some of the consequences of this um basically the attacker can have a full trunk connection to the switch they can make themselves into a trunk uh spoof themselves as a switch uh which allows them to have 2 way communication on that VLAN
10:43
they place themselves directly on that VLAN um allowing them to eavesdrop on the traffic send messages to and from systems on that on that VLAN. Okay so here is um switch spoofing demo uh basically we did this in the ESXi environment um the setup is we have a virtual machine um within the ESXi environment and it's going out through the virtual
11:03
switch or bridge. ESXi is more like a bridge than a virtual switch uh the standard switch on it. We have that connected to a physical Cisco 2950 switch um and the port is set to DTP auto just default configuration and then you see um there's another system on the other end that's connected uh via a trunk link with a VLAN 20 and 1 support over that
11:23
trunk link going into another hypervisor environment there. So let's take a look at this uh this demo here. And all these videos are on YouTube the links are on the whitepaper on the Defcon CD so if you want to watch them later. Okay so on the left hand side we can see the configuration for the Cisco 2950 switch um on the
11:45
network settings for the Kali virtual machine that's on that system. We're going to first take a look at the interface settings for the um ESXi server in this case it's called Luminara. Um you can see it's connected it's just set to VLAN 1 so it's just on the default VLAN of that switch nothing was changed besides the defaults um it's not set to a
12:02
trunk port or anything. Um we're just going to verify the trunk status on that and we can see that it's using 802.1q encapsulation it's not trunking and the mode is set to auto so it's just default configuration nothing was changed. If we go over onto the virtual machine uh we're going to take a look at the network interface here we can see
12:22
there's just the basic network adapter it's on an isolated VLAN test environment we created it's just a separate network for that um which is over there on the switch on that port. So if we dig a little deeper into these details um we can take a look at that network and we see down on the bottom we set up that VLAN test network and the
12:40
Kali virtual machine is the only system on that network. Um and if we look at the properties of that we can see that this uh this connection has no VLAN ID set to it so it's just on the default VLAN for the ESXi virtual switch. Um now we're going to go over to the virtual machine itself grab console access and we're going to start the attack in this
13:03
case we're going to just use the Yersinia program so we're just going to type Yersinia minus I to get into interactive mode. Gotta bear with me a little bit. Ok and we're going to select the default network interface on this so just hit enter and then we'll
13:27
launch the attack. So we're just going to go up and select the uh DTP or dynamic trunking protocol and then launch the attack press 1 and we can see it successfully went into to
13:42
trunk mode. So the uh dynamic desirable effect was affected over there on the switch side we can see the line protocol went down it came back up again and if we check the status on that trunk port we'll see it indeed went into trunking mode. You see it's now instead of VLAN 1 it shows the trunk and if we take a look at the full status we
14:10
can see that it's indeed set for trunking and auto and native 2.1 q encapsulation. So the system was effectively put on as a trunk now we can access any VLAN we want that's associated with that trunk so in this case any system that was on VLAN 20 or whatever.
14:23
So that was the switch spoofing attack you can see it was affected or effective in the ESXI environment and let's see. Ok so results across the board here we can see that uh the physical Kali 2.0 control system we set up the physical switch we tested it with a control to make sure it worked first that way before we proceeded into
14:43
the virtualized environments. Um you can see it pretty much worked under every system that used bridge networking instead of a virtual switching networking so if you're using an environment that has a bridged network uh virtual switch um this is gonna work. It worked in the uh open source Zen with Linux bridging it worked in the VMware ESXI
15:01
environment as you saw and it also worked in Proxmox which also supports bridging as well. So any environment that used the virtual switch it did not work because basically those that DTP packet when it was sent through it was blocked uh for getting to the physical device. Ok so mitigation um in the physical world you just disable unused switch ports don't give access to people that actually get connected to those
15:21
ports um disable CDP and DTP uh or use it on an as need basis for those ports that you really need it set up on. Um restrict the amount of trunk ports you don't just want to have ports set up to be trunks if you don't need them although most all the hypervisor environments if you read their their documentation they specifically say that for best practices set up a trunk port for connection to the the virtual switch so that
15:43
way you can actually support VLANs into your physical environment and other virtual environments. Um so really just limit these this access but in the virtual world it's really hard to do this so if you're using bridged environments realize that this could be affecting your network. Ok let's talk about double tagging now um here's the CVE
16:00
for double tagging. The 802.1Q VLAN protocol allows remote attackers to bypass network segmentation spoof VLAN traffic via a message with two 802.1Q tags. So we saw before that we have um a normal basically this is the uh normal traffic this is the scenario we used here we have two switches um a trunk connection between them
16:21
supporting VLAN one two and three. You can see some two machines on one side connect to that first switch one's on VLAN one one's on VLAN two and on that second switch we have VLAN one two and three so the goal is to get some frames across between the two switches uh from that system on VLAN one and try to get it over to VLAN two or three instead of VLAN one. So here we can see the normal flow of
16:42
traffic we're just using a single tag um where it goes through VLAN one goes into that first switch goes across the trunk connection still with that VLAN one tag and then it goes into that system that's VLAN one on the other side so basic normal flow of traffic and we can see that the other VLAN two and VLAN three machines do not get that that frame it just gets blocked. So here's a comparison of frame types um the
17:04
first one is a standard Ethernet frame without VLAN support the second one is that standard VLAN tag with one uh 802 dot one q tag in the middle or header in the middle and the third one down on the bottom is doing uh 802 dot one q double tagging so um this is where we're actually doing a a frame within the frame or a VLAN tag within the frame
17:22
and we're doing multiple ones. So in this case here we can see that um the effects of double tagging we have VLAN one and VLAN two on the one side that tag has one and two in it so we have two headers in that in that frame it goes into that first switch it doesn't get passed on to that first system not connected to that first switch because we're
17:40
still reading that VLAN one tag we're not seeing the VLAN two tag. As soon as we go across that trunk connection that VLAN one tag is stripped off passing over the the frame with the with the tag of two and then when it gets to the other side it goes directly to that system on VLAN two and doesn't go to the VLAN one or VLAN three so here we can see the same thing with three just a different example. In case of the
18:02
consequences an attacker can send packets to any targeted VLAN as long as it's ported over that trunk connection um and as long as they have access to that native VLAN. Um the target on the access is isolated and um it's in a native VLAN broadcast domain this is not a good attack for eavesdropping because basically it's a one way attack so you're sending a frame to another VLAN you're not getting anything back to you so it's good
18:24
for DOS attacks it's good for maybe a one way covert channel to another system on another network um but that's about it. Ok so we have three different scenarios we ran with this the first one was a control scenario where we had the two physical switches which was this was known to work in um we had a physical attacking
18:40
system connected on a native VLAN and went through that first trunk link to the second switch and we were able to access the VM um on the other side on VLAN 20 for this. For the sake of time I'm not going to show this video right now it does work here you guys are more than welcome to go click the link um but we have two more videos I'd like to show they're a little more effective than this one. Ok so the second scenario we did
19:00
was two virtual switches so we took out that uh second 2950 and instead we're going from one virtualized environment through the physical switch into another virtualized environment. So in this case we have an attacker VM it's on no VLAN um just on that native VLAN on that virtual um environment going through that virtual switch connected through a trunk link via best practices um on 1 and 20 into the Cisco 2950 through
19:24
another trunk link connected to another virtualized environment which is going into a virtual switch there on an access uh VM on VLAN 20. So in this case in this demo we have the attacker systems on Xen server and the target systems on Proxmox. Ok so again on
19:45
the left hand side we can see the switch configuration for the 2950 that's in the middle of these two uh two systems. Port 31 is uh the Citrix Xen server. Port 29 is the Proxmox system. Yes I do like Star Wars. Uh the middle system is Xen server and the
20:02
far right system is the Kali system on Proxmox. So the Proxmox system is our target. The middle system is our Xen server attacker. What we're gonna do is take a look at those interfaces just to check out the settings. So port 31 is our attacking system. Set for trunking. Notice the mode is on. I didn't do auto because I actually
20:20
specifically set this to trunking mode for best practices. And we can see the 802.1 encapsulation. So what we'll do here now is check out the the settings for the attacking system. And we can just see I have it just set up on a basic network
20:43
interface port. There's nothing special about it. There's no VLAN tags on that system or it's just a straight connection into that that server on that VM. And that switch. The Proxmox system you can see it's tagged for VLAN 20 for that client um on that system. So we're gonna run the attack from the Citrix Xen server VM on Kali there to the
21:03
Proxmox system which is also Kali. Um on the Proxmox system we're just gonna run a simple TCP dump command and we're gonna grep out for ICMP traffic to try to just pull out that ping packet we're gonna try to send through. Um so just basic TCP dump with verbosity and grepping for ICMP. And then over on the Xen server system we're gonna set up
21:30
Yersinia to to launch the double tagging attack. And just selecting that default interface again. This time we're gonna select 802.1Q protocol. And then we have to do
21:44
some setup on the bottom there. So um down on the bottom you can see there's uh tags for input VLAN and then the target VLAN. There's also uh the source IP address and destination IP address. So we wanna go from VLAN 1 to VLAN 20 and then we wanna go from a
22:00
source IP address it doesn't matter so we spoof the address of 192.168.5.5 um and then the target system is 192.168.1.11. So we have to just input that in there for the settings. And we're set up there. So we can see up on top we're using ARP 192.168.1.11.
22:24
Um so we see the ARP protocol there it actually went through. We're gonna launch the attack. Sending out that ICMP protocol or ICMP frame. And we sometimes you have to keep launching this attack a little bit. What I found is when I started doing this testing
22:42
nothing happened. And I'm like okay it's not gonna work. Not gonna work. Then I sat there for a little while longer and just kept pressing the attack button pressing the attack button. And then finally what happened is we'll see here in a second. Took a little bit of time. So if you're doing this at home. Boom we see all the traffic. So there was a little bit of latency going from one virtual environment through the
23:03
physical switch into another environment. But we can see that the frame was actually successfully forwarded from VLAN 1 through a virtual switch through a physical switch through another virtual switch to VLAN 20 on the other side. So you can see that the uh spoofed address of 192.168.5.5 going to the Cali 1 host name which obviously ETC
23:21
host file on that Cali system is resolving the local IP address to the host name um on that system. So this was successful. We were actually able to do the double tagging attack through a virtual switch through a physical switch into another virtual switch. Okay
23:44
so we have one more here. Um in this case we decided hey if we could do it with two virtual switches let's take it out. Let's go through one physical switch into another virtual switch and just see if that second virtual switch will successfully do that double tag. So we don't have three switches now we're down to two. One's a physical one's a virtual. Um in this case the physical Cali system is the attacker and
24:04
we're going into a Microsoft Hyper-V guest on a Cisco Nexus 1000V. Has anybody ever tried to set up a Cisco Nexus 1000V? How fun is it? Right? Oh yeah okay so let's take a look at this one. Same pretty much set up we have um on the left hand side the
24:26
physical 2950 and there's a port 1 which is connected to that physical uh Cali system which is in the middle. Like you see it's just on VLAN 1. Uh no trunking going on there. So this has a trunk connection between the physical switch to the Cisco uh
24:45
Nexus 1000V on the Hyper-V environment. Um so we'll check out that interface as well. And
25:01
we can see it's set for a trunk as per best practices. And 802.1Q encapsulation again. Uh we have VLANs 1, 2 and 10 supported on here and 20. Um now we'll go over and
25:25
check the configuration for the Nexus 1000V which supports the same Cisco commands pretty much for identifying trunk connections. Um so here you can see we have Ethernet 31 is the trunk connection connected to the Cisco 2950 and we have VETH 1 which is that Cali
25:41
system connected on VLAN 10 in this case. And that's connected to that Cisco Nexus 1000V. So in the middle here we have our um attacking system which is a physical system and then on the far right we have our uh Hyper-V VM. And again we're just gonna run TCP
26:00
dump. A little bit of verbosity and grep for ICMP traffic. Let's forward this a little bit so we can speed it up. And then on the attacking system we're gonna run Yersinia again. We're pretty systematic in our approach to this testing to make sure we did it across the board and it was the same everywhere we did it. Um now our physical Cali system is
26:25
multi-home so we have 4 network interfaces on this so we can do different testing on different networks. So in this case we choose Ethernet 2 because that's the one that's actually on that VLAN test network. Um so we just went in there and changed the configuration of that interface. And then we're gonna go up and choose the 802.1Q protocol
26:43
again and set up that attack down on the bottom. I've already seen that so I'll forward through that a little bit here. Just verifying the IP so we're we're going to that uh IP
27:03
of 192.168.1.199 in this case is the virtual machine in Hyper-V. Um and we're gonna start launching this attack now. So here same thing just launching it we can see the uh spooked IP address going to the uh the destination IP of 100. Wasn't 199 it was 100.
27:21
Uh 802.1Q and the protocol's ICMP. And if we just start launching that thing again took a little bit of time to get this thing to successfully go. But in the end we see that it actually works. So it went through the physical switch from a physical attacker through that physical 2950 into the Cisco Nexus 1000V onto VLAN 10 um on the the target
27:46
virtual machine. So it actually worked. So we're seeing that we can actually do double tagging and switch spoofing attacks in virtualized environments which is pretty scary. So overall results of this um the first set of charts there on the left hand side show
28:07
the uh open V switch, Linux bridging, pretty much everything worked um for going in. So this is this isn't coming from this is trying to get into um an attack a virtual machine on another VLAN inside of a a virtualized network. So it worked on every single
28:21
environment except for the standard V switch for Hyper-V. Uh we find this is because when you're launching your senior you're actually spoofing MAC addresses on the attacker side. And what we saw last year when we were we were discussing our MAC flooding attacks, those also didn't work in the V uh the standard V switch for Hyper-V because the standard V switch has some protection for MAC spoofing against it in in the server 2008 2010
28:43
environments. Um so that's the only thing that protected against this attack was that MAC spoofing um safety mechanism. So if that wasn't there or if you could do this attack without spoofing MAC addresses you could probably get away with it in that environment. Over on the other chart we see um what was successful what could we launch the attack from? Uh which environments could we could we actually send something out
29:02
from? In this case um we saw it worked in the bridging environment. So anything that was a bridge except for ESXi in this case worked. We also saw it work in in uh zen server with open V switch and just a standard zen environment with open V switch. So pretty much all the open source software was affected by this attack. Mitigation techniques,
29:21
standard ones for physical devices is limit your access to VLAN 1 or just eliminate VLAN 1 altogether. Um maybe label it something different so it's not easily identified. Um restrict access to switches by MAC address which can be spooked so that's a little bit difficult it's kind of a double edged sword there. Um but the heart of this attack is having access to that native VLAN as we saw. And even the native VLANs within the
29:42
virtual switches themselves which may not be identified. Um so you really need to look at hardening these these uh these switches if you're gonna be using these in production environments. Okay so we're gonna pass on to Caitlin now for ARP spoofing. Okay ARP spoofing. It is ARP is an address resolution protocol. It's a layer 2
30:08
network protocol that maps the physical MAC address to the logical IP address. Each system on a network has an ARP cache and it stores the information from discovered nodes on that network into the ARP cache. Uh the common entries in ARP cache is the
30:23
default gateway and the local DNS. The process for ARP is an initiating system sends out a broadcast broadcast request to the entire network. It asks who has a certain IP address. A node on that network who has that IP address responds with its MAC address
30:45
and the information is stored into the ARP cache. Okay so this is just a demo of what we
31:08
did. On the left hand screen is the router or the default gateway. In the center is the target machine and on the right is the attacking machine. On each of them we have
31:20
the ARP cache displayed and you can see the IP address of the attacker and the target over on the default gateway and you can see the MAC address displayed with it showing each separate entry. And then over on the attacking machine we're gonna run our ARP poison script which is just a basic python script and that's gonna run it's gonna go
31:46
through and poison the ARPs. So we're gonna go over onto the target and the default gateway and check our ARP cache and you can see as it comes up and displays with the 2 IP addresses that the MAC addresses are now the same. So on the default gateway both the
32:02
target and IP address are showing that the MAC address is now the same so that was spoofed into tricking the MAC address. Then we're gonna go and we're gonna run a
32:20
ping just out to Google just to get some packets flowing, get some traffic and that's gonna finish up the script and run through there. Once the script is finished it's gonna restore the target machine so we're gonna go over and stop the ping and restore the ARP
32:43
cache and check that over and then you can see on the target and on the default gateway that the ARP cache is now displaying as it was in the beginning. So the
33:05
TCP dump script so that's gonna show the traffic that came through and then you're gonna be able to see Google's IP address showing traffic to the IP addresses showing that we captured packets from Google. Okay and then for the results you can see it worked on all
33:42
the platforms. ARP spoofing mitigation on Cisco switches you can make use of the DHCP snooping and dynamic ARP inspection validation um it's not supported on the Cisco Nexus 1000B and then there's also ARP watch which runs as a service on a Linux system
34:05
and monitors the network in changes for ARP activity. Okay so to kind of wrap this up and
34:25
put it into some context um we can see that there are the results do show that virtual networking devices can pose the same sometimes even greater risks than their physical counterparts. So that's an important thing for um all the users of multi tenant environments to understand. Which systems were vulnerable varied pretty widely across
34:45
the tests. There was no one best system and there were some uh tests that everything was vulnerable to. That lack of sophisticated layer 2 security controls similar to what is available on enterprise grade physical switches greatly increases the difficulty in
35:02
securing virtual switches against attacks like these. So what is the bottom line impact then to someone running in a multi tenant environment? A single malicious virtual machine has the potential to sniff all the traffic passing over a virtual switch. It can pass through the virtual switch and potentially affect the physically connected devices as
35:22
well allowing traffic from other parts of the network to be sniffed as well. So it's a very significant threat to confidentiality integrity and availability of data that's passing over a network in a virtualized multi tenant environment. And there's a lot of very mission critical stuff being housed in virtualized multi tenant environments these days as we know. So what can users of these systems do? Well educated users can question
35:47
their hosting providers. Which virtual switch implementations are being used? Which attacks are they vulnerable to? Are they doing any additional mitigation strategies against attacks like these? They can also audit the risk of the workloads they're
36:00
using to run in the cloud with this environment with these you know with this understanding in mind. They could consider extra security measures on their own or request additional security measures from their hosting provider. Things like increased use of encryption, additional service monitoring, more detection of traffic, attack traffic that could be present, alerting. There's a lot of things that could be done. What are some of the
36:24
next steps for us? So this is uh last year was our first time at DefCon so this is our second time. Uh we're a pretty small team. Uh we made uh improvements this year. We did more attacks than we did before on more regular hardware and we're we're really happy with that. But there's a lot more we'd like to do. We'd really love to set up kind of
36:42
an institute for apples to apples testing of virtualized environments. We have kind of a long history of this. Um we've also done what kind of malicious things kind of virtual machine that's co located do if it hammers the disk or it you know hammers the CPU or it allocates a ton of memory or all sorts of malicious things. We've done apples to apples testing of different kinds of um virtual machine migration technologies and you
37:05
know what's going in the clear and what's not and how long it takes and when it can get stuck. And we think there's a real place for that kind of apples to apples independent testing of those things. If you're in a situation of wanting to deploy some of these technologies both proprietary and open source it's really hard for you to bring all of
37:23
them in house and run through all of these kind of tests. So we've seen a lot of great feedback about oh thank you for doing all of these tests and you know pointing out where the problems are. We've also seen vendors fixing things. We'd love to see you know industrial partners to participate in an institute of this kind whether it's places that
37:41
have technologies they'd like tested and would like to see our results and have a chance to say okay yes this is the results in the default environment but if you turned on this thing then the results would be completely different. We would love to partner with people like that. We'd also love to partner with people who are using these technologies in production environments and would be interested in these results. Um we
38:02
have leads we would really just like to do more testing in production environments because we're basically using best practices out of the box proprietary and open source technologies. Over time we've seen some of the work that we've done result in vulnerabilities that are then patched so we're really proud of that. Um but we we
38:20
understand that in production environments many times there's additional secret sauce or additional monitoring or additional conditions that are put in place. We actually got some great leads last year after our talk that we still need to follow up on but this is us this is a pretty small team and the you know the biggest bottleneck we have is the need for more great students like Caitlin uh to be funded to do this kind of
38:42
testing um so you know if anyone would like to help us sponsor a few students uh we promise it's good educational value. Um so this is emails uh for Ronnie and I also um all the details if if some of the typing and the demos you didn't quite get you can slow
39:02
down zoom in on the videos they're all there all the great details and um uh all of the publications, presentations, demos are all at Ronnie's website. Um also like to give a shout out to Nick Morante who uh helped us get our AV going uh after some last minute troubles and I guess now we'll take some questions. Hi. So I see you did a bunch of
39:40
testing on the hypervisors and the virtual switches that come with the hypervisors. Did you try this with anything like Open Daylight or VMware NSX these kind of SDN solutions that sit on top of the hypervisors? Not yet but we'd love to. Um I did start looking at some SDN stuff but we've seen that there's a lot of there's a lot of vulnerabilities in the
40:01
controllers out there like where you can actually take control of the controllers so by implementing SDN we're looking at implementing more security flaws into these environments when we're trying to reduce that footprint. Um I looked at with the DHCP stuff we did last last year we presented on that I found a Python script just by using simple Python and Scapi um you can write a simple script you just daemonize that will
40:20
find you know rogue DHCP servers on the network and fix that so I think by using smaller scripted daemons that we could actually deploy without putting more complexity in these networks would be a better solution than trying to throw the monster of SDN on top but I mean it is a many people are using SDN so it is a good place for us to start exploring but that's a whole other research track. Right on thank you. Yeah. Great
40:45
talk um I can see you uh tested against Xen uh you tried against Amazon inside the Amazon environment. Uh no we haven't tested within Amazon I think that is not in their uh uh terms of service but uh we did have some leads within Amazon uh which we'd
41:01
love to follow up on I'm not sure uh yeah we haven't done that yet we'd love to. So have you done any uh cam table overflow attacks against the virtual switches as well? Uh that was last year's talk so if you look on the DEFCON media server it's all there demos and everything. Perfect thank you very much. Uh so along with uh you were
41:22
talking about the 2950 uh physical switch uh so that's running I'm assuming like uh iOS 12.04 or something like that were you able to sort of do that attack on like uh a newer version of the iOS like uh like a 15 dot something? Yeah um let's go back up to the
41:41
details. Thank you. No I don't want to go to the details here I want to go to that picture. I'm not exactly sure what model of that switch is but if you look up here on the top of the rack if I can get there again. On the back there's 2 switches up top there those are brand new Cisco's I accidentally tested it against those and it did work. So I I don't
42:01
recall which environments but yeah it did I was able to switch spoof out of those as well um the double tagging didn't work because it's not using the 802 dot 1 q encapsulation. Okay. So if a switch doesn't support that your double tagging is not going to work. There's other encapsulation pipes for trunking that that are supported now in the newer devices. Awesome thank you. Yep. Hello I'm from Brazil first of all
42:21
thanks thanks for the great presentation it was wonderful. Uh have you got the first part? Uh I'm from Brazil and first of all thanks for the presentation it was great. Uh I have worked with a lot of companies in Brazil a lot of environments from small to
42:41
large and I have never seen any any one of them with ARP spoofing preventions implemented. None of them. And sometimes large environments with load balancers and to offload the applications uh they are encrypted from the the client until the load balancer and from the load balancer to the back end. The they usually take off the
43:05
the the encryption and create confirmation going on and based on your experience have you seen uh in I uh you talked about this have you seen what kind solution have you
43:21
seen if you have implemented in the the the environments that you have tested or worked with? Let's go to the ARP slide here quick. So yeah if you if you guys look at the slides online we actually have uh images that didn't show up here because of this but there's some good stuff in there for the ARP. Um so basically you're looking at ARP
43:44
watch. Cause the Cisco's have this uh this dynamic ARP inspection and DHCP snooping that allow you to to look for rogue DHCP servers and you know different ARP problems going on there. But ARP watch is a Linux utility you could demonize run a server on your network and actually look for you know malicious ARP activity on that network. It's about the
44:00
only thing we've really looked at and experimented with right now but it does work pretty well. Okay but uh uh I'm not pretty sure if it was clear. What of this kind of uh of mitigations have you seen implemented in actually implemented in the conference? Oh in the real world. And that's where we'd really like to do a lot more. We really haven't done much work in production environments. We're we are just looking at
44:23
vanilla out of the box stuff according to best practices and then looking at what the mitigations could be. We don't have a lot of visibility into how often people are doing these mitigations in production environments. For us it's interesting to hear you say that you've seen lots of environments and nobody's doing that so we'd love we'd love your email and we'd love to follow up. That would be really helpful for us. Um I see
44:42
we have a line of more questions and we got the kind of yank sign from the goons. Uh we'd be very happy to talk more with folks. Um I'm not sure where the right place to go and meet people is. Uh I guess if you come up here you can go where we go and we can follow up. Yes? Okay. Thank you so much. Okay. Thanks everybody.