A Bridge Too Far: Defeating Wired 802.1x with a Transparent Bridge Using Linux
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 | 122 | |
| 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/40535 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 19108 / 122
3
5
10
11
12
22
23
24
30
31
32
38
43
46
47
49
51
54
56
59
60
62
71
73
76
84
85
88
92
93
96
97
98
104
106
109
112
113
115
119
00:00
EmailKernel (computing)Information securityAlphabet (computer science)Statistical hypothesis testingRandom matrixComputer networkTelecommunicationSystem administratorWorkstation <Musikinstrument>NetbookLaptopBefehlsprozessorRead-only memoryComputerData storage devicePersonal digital assistantDuality (mathematics)ApproximationArmBootingPlastikkarteAxiom of choiceBacktrackingDefault (computer science)Service (economics)Computer hardwareRevision controlDistribution (mathematics)Polar coordinate systemAddress spaceOpen sourceImage resolutionFrame problemCommunications protocolLengthVariable (mathematics)ARPVirtual machineVector potentialLocal ringSystem programmingCache (computing)Random numberComputer configurationUDP <Protokoll>Total S.A.FlagSystem identificationGateway (telecommunications)RoutingImplementationLatent heatAuthenticationSoftware frameworkLocal area networkEAP-ProtokollTransport Layer SecurityClient (computing)Server (computing)ZugriffskontrolleIndustrie-PCFrame problemHard disk driveLocal ringCache (computing)Address spaceLocal area networkStandard deviationIP addressSoftware frameworkAuthenticationCommunications protocolSoftwarePhysicalismRouter (computing)Gateway (telecommunications)Virtual machineTable (information)Image resolutionRouting1 (number)Game controllerLine (geometry)Extension (kinesiology)Computer hardwareFigurate number2 (number)NeuroinformatikArmOpen sourceWindowLevel (video gaming)Client (computing)BacktrackingPoint (geometry)Virtual LANBefehlsprozessorDigital photographyImplementationDifferent (Kate Ryan album)Integrated development environmentType theoryStatistical hypothesis testingPresentation of a groupPolar coordinate systemPlastikkarteRegular graphLaptopMonster groupSound effectWorkstation <Musikinstrument>CuboidConnected spaceInteractive televisionSystem administratorGroup actionInformation securityObject (grammar)Slide ruleMultiplication signMappingKernel (computing)Data storage deviceInjektivität
08:28
RadiusInformationAuthenticationClient (computing)Server (computing)Computer networkDecision theoryPublic domainElement (mathematics)Virtual LANChemical equationStructural loadPatch (Unix)Local ringVirtual machineOverhead (computing)Term (mathematics)Exception handlingProxy serverBackupComputer hardwareSoftwareLink (knot theory)Configuration spacePower (physics)Open sourceInformation securityDefault (computer science)UDP <Protokoll>Classical physicsAuthenticationProjective planePublic domainWorkstation <Musikinstrument>Element (mathematics)Server (computing)SoftwareWindowMultiplication signStatistical hypothesis testingCASE <Informatik>Address spacePlanningConfiguration spaceType theoryInformationRadiusQuicksortNetbookPatch (Unix)Motion captureDecision theoryPublic key certificateGoodness of fitPasswordFront and back endsClassical physicsSharewareCondition numberConnected spaceLink (knot theory)Adventure gameBitClient (computing)NumberBootingInformation securityNeuroinformatikSoftware testingLocal area networkLastteilungImplementationOffice suiteIntegrated development environmentMaxima and minimaComputer hardwareProxy serverSelf-organizationException handlingTerm (mathematics)Power (physics)Virtual LANCuboidGame controllerFlagVirtual machinePrice indexSheaf (mathematics)BlogComputer animation
16:56
Configuration spaceSharewareComputer networkStandard deviationOSI modelOSI modelKernel (computing)Module (mathematics)Series (mathematics)DisintegrationDistribution (mathematics)Installation artInterface (computing)Utility softwareVirtual machinePlastikkarteDefault (computer science)Address spaceOpen sourceDigital filterRegulärer Ausdruck <Textverarbeitung>Motion captureStatisticsFrame problemGoogolExecution unitInformationCommunications protocolPatch (Unix)Block (periodic table)CodeInformation securityBlogLink (knot theory)Sheaf (mathematics)Java appletInjektivitätDrop (liquid)CompilerPhysical lawUser interfaceMass flow rateComputer iconInfinityVideoconferencingHill differential equationComa BerenicesIP addressInterface (computing)Set (mathematics)CodePatch (Unix)Series (mathematics)Address spaceAdaptive behaviorConnected spaceSoftware protection dongleStandard deviationRemote procedure callVideo gameDefault (computer science)Server (computing)Module (mathematics)Capability Maturity ModelClient (computing)Line (geometry)RadiusHookingUtility softwareWindowFirewall (computing)SharewareSoftwarePresentation of a groupKernel (computing)Stress (mechanics)BootingPower (physics)Link (knot theory)Point (geometry)Variable (mathematics)Information security2 (number)GodBitVirtual machineSinc functionResource allocationMessage passingDistribution (mathematics)Configuration spaceGateway (telecommunications)CASE <Informatik>Workstation <Musikinstrument>Kerberos <Kryptologie>Virtual LANService (economics)Local area networkInjektivitätFilesharing-SystemOpen sourceObject-oriented programmingWeb 2.0Integrated development environmentSineDirectory serviceLecture/Conference
25:24
SharewareInteractive televisionInformation securityComputerReverse engineeringConfiguration spaceAddress spaceClient (computing)Open sourceFunction (mathematics)Server (computing)Service (economics)Direct numerical simulationQuery languageBootingBlock (periodic table)Drop (liquid)Interface (computing)ChainDataflowLocal ringProcess (computing)outputTraverse (surveying)Table (information)OSI modelSlide ruleVirtual machineTelecommunicationRoutingOperations researchStack (abstract data type)TupleDaylight saving timeComputer networkGame controllerPublic domainEvent horizonLimit (category theory)UDP <Protokoll>Range (statistics)Gastropod shellComputer configurationWorkstation <Musikinstrument>System callDynamic Host Configuration ProtocolSelf-organizationSoftware testingInformationWeb pageComa BerenicesDefault (computer science)Rule of inferenceGateway (telecommunications)Fluid staticsFirewall (computing)Router (computing)QuicksortEmailMathematical analysisVariable (mathematics)NoiseCoefficient of determinationImage resolutionFlagNumerical analysisStreaming mediaCache (computing)Kerberos <Kryptologie>Active DirectoryPhysical systemLoginBlogPresentation of a groupCodeImplementationAutomationStatement (computer science)Execution unitComputerLink (knot theory)LaptopAverageProxy serverCharacteristic polynomialWindowOrder of magnitudeOrder (biology)System administratorDuplex (telecommunications)Quantum fluctuationPower (physics)Pressure volume diagramBoundary value problemIntrusion detection systemFiber (mathematics)Mechanism designAnalog-to-digital converterOpticsSubstitute goodFrame problemAmsterdam Ordnance DatumAuthenticationDecision theoryBasis <Mathematik>Point (geometry)InternetworkingIPSecAuthorizationQuicksortMathematicsLevel (video gaming)CuboidBootingDecision theoryGateway (telecommunications)BitAddress spaceNumberFluid staticsResultantRoutingChainVirtual machineClient (computing)Service (economics)Cycle (graph theory)CASE <Informatik>Characteristic polynomialVideo gameFunction (mathematics)Rule of inferenceLocal ringRange (statistics)RandomizationAmenable groupLink (knot theory)Integrated development environmentSign (mathematics)Vapor barrierOpen sourceConnected spaceoutputInterface (computing)Default (computer science)Server (computing)Right angleWindowStreaming mediaTable (information)Sinc functionAuthenticationProcess (computing)Logistic distributionSingle-precision floating-point formatComputer fileLine (geometry)Public domainOrder (biology)HookingBlock (periodic table)Drop (liquid)InformationPatch (Unix)Duplex (telecommunications)Sound effectExtreme programmingGame controllerNeuroinformatikOperator (mathematics)Information securityAuthorizationMathematical analysisSystem administratorMetropolitan area networkCube1 (number)MalwareContext awarenessWeb 2.0FlagOffice suiteMereologySimulationIP addressLocal area networkPort scannerLastteilungPoint (geometry)Likelihood functionKerberos <Kryptologie>ParsingExploit (computer security)Motion captureDirectory serviceConfiguration spaceSharewareSurjective functionFigurate numberWorkstation <Musikinstrument>SoftwareDirect numerical simulationFirewall (computing)Software testingArc (geometry)Existential quantificationMaxima and minimaPhysicalismMeasurementCore dumpSystem callScripting languageAdditionEvent horizonDependent and independent variablesSimilarity (geometry)TelecommunicationArithmetic meanFiber (mathematics)Revision controlMultiplication signGoodness of fitOSI modelProxy serverStandard deviationComa BerenicesVirtuelles privates NetzwerkKernel (computing)Noise (electronics)Transport Layer SecurityWind tunnelLaptopIPSecDynamic Host Configuration ProtocolDisk read-and-write headSpacetimePoint cloudTriangulation (psychology)WordDistribution (mathematics)10 (number)BacktrackingTranslation (relic)Validity (statistics)Arithmetic progressionBasis <Mathematik>InternetworkingTask (computing)Wireless LANStatistical hypothesis testingNetwork topologyEmailWebsiteMatching (graph theory)Price indexAverageGastropod shellReverse engineeringDifferent (Kate Ryan album)WeightAmsterdam Ordnance DatumBuildingGodVector potentialSeries (mathematics)Physical systemComputer configurationStatement (computer science)Data conversionStack (abstract data type)Real numberWave packetFrame problemType theoryTupleAsynchronous Transfer ModeQuery languageCausalityFunctional (mathematics)Self-organizationPresentation of a groupEncryptionPower (physics)Interactive televisionGroup actionForm (programming)Order of magnitudeSubsetVariable (mathematics)Perfect groupThumbnailParameter (computer programming)Square numberSupremumMetric systemAuditory maskingHost Identity ProtocolTrailSoftware bugFilesharing-SystemVorwärtsverkettungMultilaterationLimit (category theory)Remote procedure callOpen setPhishingExtension (kinesiology)Computer virus2 (number)Resolvent formalismProof theoryInvariant (mathematics)
Transcript: English(auto-generated)
00:00
My name's Skip Duckwell, I'm here to talk about bypassing wired 802.1X with a bridge using Linux. So I'll just kind of get right into it. Whoops, it's not, is that pushing
00:22
slides? There we go. Alright, so I've been working with Linux since 1993. It's a really long time, back before there was a 1.0 kernel. Unix admin by trade, I transitioned to IT security a while back. Got a whole bunch of
00:44
initials after my name. Missing 12 letters, so I think the new certs I go after are probably going to try to go for some of the oddballs like Q. Picked up X a little while back, but anyway, I work for
01:00
Northrop Grumman on a team that does full scope penetration tests. So anyway, let's just go over some basics here. The objective is to introduce onto a network that is secured with wired 802.1X, a device that we can inject traffic with, communicate with,
01:25
interact with remotely, and that is undetectable to the people who run the network. Let's face it, if they could see it, it really wouldn't be much fun to play with. So what do we need? A Linux box with two network ports, an extra network cable or two. This
01:43
uses an existing workstation with an existing authorized connection, and a box off an ether somewhere that we use to handle callbacks. So you can actually use a little USB ethernet cards in them. The upside is they're
02:05
x86 based, so you don't have to worry about any cross compiling or anything like that. You can use backtrack. But this monster is a little hard to hide under somebody's desk. So somebody would figure it out pretty easily. But if you had to do an in
02:22
person demonstration walking into someone's conference room, just jacking yourself in, it could be a pretty effective presentation device. So I also got something like this. It's
02:41
an atom based industrial PC. Pretty small. This one's got two ethernet ports already on it. Bunch of USB. You can put an SSD hard drive in it or a regular hard drive. It's completely fanless. Pretty quiet. Pretty easy to shove under a desk somewhere. I want
03:06
to say this one was four or five hundred bucks, but they make cheaper ones or more expensive ones. Anyway, there's a lot of industrial PCs or this kind of technology meant to run in environments
03:23
where it's not terribly computer equipment friendly. So high temperature humidity environments, that type of thing. So the other fun one to play with is plug computer. This looks like kind of a big wall wart. And
03:44
it's based on an ARM CPU. Runs Linux. And it's fanless. And if you saw this on the floor with another cable coming out, you probably wouldn't give it a second thought if it was shoved under someone's desk. And I've got it plugged in
04:03
line, but you can also get on the photo, you see the little dual wall port. It just looks like a big wall wart. You put a sticker on it that says air freshener or something like that. Yeah, alarm company. That's a good one.
04:20
No one will really know the difference. So for the x86 implementation, this is actually what I got working initially. I used backtrack R4. Yeah, I know. Five is out. But I had it working on four. So haven't gotten around to five. And on the plug, it currently has Ubuntu 904, which is
04:42
currently no longer supported. So I'll either switch it over to Debian or probably just roll my own distro at some point to have a finer grain control over what goes on it. Quick review. An ethernet frame. This is what a typical ethernet frame without using
05:02
VLANs looks like. It communicates to other devices on the wire using destination and source MAC addresses. And typical ethernet traffic is either the ethernet frame that encapsulates a higher level packet or ARP. ARP is
05:22
the address resolution protocol. It maps IP addresses to physical hardware addresses. It's a question and reply protocol. It's typically somebody will yell out on the local segment who has 192.168.1.1 and the 192.168.1.1 will
05:43
reply back directly to the person asking the question, I'm here and this is my MAC address. To keep the ARP traffic from getting completely crazy for every packet that gets sent out on the wire, there's typically a local ARP cache on the at the
06:02
higher level on the local machine. The ARP cache is typically on Windows XP would last up to 10 minutes. On Vista 7 2008 it's a random interval between 15 and 45 seconds. And on Linux typically it's 60 seconds but
06:22
it is tunable. IP address or IP protocol. IP encapsulates TCP, UDP and it uses IP addresses to communicate with who it needs to talk to next. So what happens
06:40
if a destination IP is outside the local network? Well the packet has to get routed. There's a local routing table on the device that decides what needs to happen to the packet once it leaves the device. Typically the only networks that a local device can route to directly
07:01
are on the local segment it's on. To go outside that, you typically forward to a gateway. When an IP packet gets routed to its next hop, the local machine will check the routing table, figure out what the
07:21
next hop router is, it will check its local local ARP cache to see if the MAC address is known for the next hop, and if it doesn't know it, it will ARP for it, store it in a local cache, it'll construct the Ethernet frame and the frame gets
07:40
fired off down the line. EAP is the extensible authentication protocol. It's not really a, it's a framework. It's not a standard. More like guidelines. Everybody tends to implement kind of their own little thing. There's 40 or so. The big ones that we're
08:04
concerned with is EAP-TLS and EAP-over-LAN or EAPOL. EAPOL is what is used to authenticate using 802.1X. 802.1X is an IEEE standard for port-based network access
08:22
control. It's got three pieces. There's a supplicant, namely the client that is authenticating to the network, an authenticator, which is the device that the supplicant is authenticating to, and then there's some sort of back-end authentication server,
08:40
usually RADIUS, something like that, that takes the credentials from the authenticator and validates them and then gives the ultimate decision about whether or not to let the supplicant onto the network. So the supplicant packages up the authentication information.
09:01
It could be a password. It could be a certificate. It could be any number of things. Package it with EAPOL, send it to the switch. The switch will then repackage it into a RADIUS request. The authentication server takes a look at it and gives the ultimate decision, and
09:21
then if successful, the traffic is allowed to pass through the network. There's a quick Wireshark capture of EAPOL exchanged from front to back. 802.1X also has the ability through an agent on the
09:45
supplicant side to make network policy decisions. For example, you can have an agent that will check to see if a road warriors netbook is up to date with patches and has a current AV. If not, it'll, instead of allowing
10:04
it onto the general business land, it will shoot it off to a remediation subnet where the only things they can talk to are the AV server or a remediation server of some sort to get brought back up to speed, scanned, whatever, and then you can fire it back over to the
10:21
workstation land. You can do things like require an account membership to a Windows domain. So you have to actually be logged into a domain to be able to use the local network resources, and if not, either deny access or toss people onto a guest VLAN, depending on how friendly you are. And you can also use it to load
10:42
balance to a lesser populated VLAN. So you don't just wake up one day and decide, hey, I'm going to implement 802.1X today. There's a lot of planning required because you have to have an authentication server, more than likely one or two. You need more
11:03
power, more licenses. All of your equipment needs to be able to support 802.1X. Printers are a notorious special case for a lot of things. It's complicated to set up. You have to plan your deployment carefully. You have
11:25
to start office by office, making sure your switches are upgraded, making sure the supplicants are communicating correctly. Then when you turn it on, you have to make sure it all works. It's often a very long-term project that requires a lot of planning. And you also, for your
11:44
organization, typically have to have a fairly robust and mature infrastructure before you even consider implementing it. If you've just got one network guy, he's not going to, he'll probably quit if you just decide you're going to do it one day. There's always going to be exceptions.
12:04
Printers I mentioned before, typically those are going to be secured with either sticky Macs or Cisco calls it Mac off bypass, which basically allows you to specify a Mac address that will authenticate via RADIUS, but it's kind of
12:23
a special case. We'll let him on anyway, even though he's not fully 802.1X capable. You've got pixie booting, potentially in your environment, hardware, software, test networks, where the configuration may change over time and 802.1X may not be the best thing to do to
12:45
facilitate your testing. OS reloads, booting from Windows to Linux, that sort of thing. These are all things that will cause you issues if you have a strict 802.1X implementation. On the client side, how often does the link
13:02
on the client actually go down? People kick cables all the time. Power cables get taken out of computers underneath the desk. Reboots, people will shut down or suspend their computer at the end of the day, and then there's good old reboot Wednesday after patch Tuesday. Every one of those
13:24
machines, as soon as it goes back to CMOS, drops its link. So, you can't just, you know, it's something you have to pay attention to and you have to be aware of, that you can't just be very strict about once the link drops, it's
13:42
never going to come back without human intervention. Typically it's configured in such a way that it will come back up after re-authentication, just forces another re-authentication. And then obviously you have to configure your various clients, be it Linux, Windows, or whatever, to support 802.1X, and that can be a bit of an adventure if you have a very heterogeneous
14:02
network. In 2004, a security researcher demonstrated an attack using 802.1X against a wired network, basically injecting a hub, and using the hub to add a rogue device
14:25
along with an authorized client at the same time. So, once the authorized client would authenticate to the network, the rogue device could then piggyback off of the existing connection. There were a few problems. And interestingly enough, when I was researching who to give
14:43
credit to for this particular attack, there were a couple of names that came up. One was a gentleman from Microsoft who posted on their TechNet blog, but there was another guy that I saw that actually was dated about a year earlier, so I don't know who actually gets credit, so I put both of them at the end in my links section.
15:04
Anyway, the problem with having two devices on the network that respond to the same information, you can really only use EDP because TCP causes a race condition. If the rogue device sends out a TCP SYN packet, SYNAC
15:21
comes back, well, a legitimate device, if it sees a SYNAC packet, because a hub will broadcast to every port on the hub, it will respond with a reset ACK. Well, your rogue device will respond with an ACK, so it's a race whose packet will get to where it's going first, and
15:42
even then, the whole time, it will be causing problems. So the best thing to do is improve on the existing classics. Nobody ever really has any new ideas anymore. It's all improving on existing things, so you can't really go to the store and buy a hub anymore. That
16:02
really does make it kind of hard to do the classic attack, or if you do go buy something that they claim is a hub, it's actually a switch, and the hub was cheaper to print on the label. Yeah, less letters exactly. Plus, they get to use the H and B, which are not that common. Makes them feel better. We want to
16:25
be able to use TCP, or for that matter, anything, and if you have all sorts of weird traffic going on on the network, such as having a rogue device or two devices responding to the same types of traffic, that can cause, that can raise some flags if you're paying
16:41
attention, that sort of thing. So, my demo configuration is mostly virtual. I've got a server subnet that has a radius box, a domain controller, and a WSUS server. It's separated out by a firewall.
17:04
The firewall has a connection to the switch. The switch also has a connection to a Windows 7 virtual client. So, once I get everything hooked up, the Windows 7 client will authenticate to the radius
17:22
server. The switch will let it go hot, and away we go. So, what's a bridge? A bridge is a network device that connects multiple segments at the layer 2. There's
17:45
an IEEE standard, and a switch is essentially a special kind of bridge in that it has multiple ports. So, to use a bridge in Linux, there is a kernel module. It's integrated into the 2.6 series,
18:01
but it's also available, I believe, for the 2.4 as well. Standard in most distributions. There's some userland utilities that you use to configure a bridge, and they're available almost everywhere, although they may not be installed by default. You'd probably have to go install them yourself. So, setting up a
18:22
bridge is fairly straightforward. You create the bridge interface. In this case, I used BR0. You add NICs to the bridge interface. You bring everything up. One side, the other side, then the bridge interface. So, what happens when you hook up an 802.1X connection with just a straight bridge in
18:43
Linux? Yeah, not much. Well, yeah, it couldn't be that easy, could it? Well, as it turns out, the reason for it not working is because the traffic that EPOL uses is supposed to be dropped per spec on
19:02
the 801D spec. So, per standard 802.1D bridge standard, there's a series of 15 MAC addresses that, if you see that traffic, you're not supposed to pass on the bridge. All right, well, it doesn't seem like rocket science. We pass it. It all works. So, back
19:24
out the patch, and away we go. Well, unfortunately, the bridge code has seen a fair amount of maturity over the past few years, so simply backing out the patch from four years ago doesn't really work. Fortunately,
19:43
there's a gentleman at Gremmell Security who figured it out. He wrote a tool called Marvin that is a Java-based tool that is used to inject traffic onto a network using 802.1X wired. So, he
20:03
figured out what you needed to do. It's written in Java. It requires three network ports, a source, a destination, and an injection, and allows you to manually jack with the traffic going across the wire. It does require a manual setting of MACs and IPs on all sides, so it's not something you can just drop
20:22
and walk away from. It requires a fair amount of setup. It's an interesting little tool. Depending on what you're doing, it might be worth looking at. But his patch basically commented out the new 2.6 code that drops the EPOL traffic, and now we can pass EPOL on the
20:45
bridge. So, it's pretty easy to get the transparent configuration going. Just set up some environmental variables to make life easier, enable IP forwarding, create the bridge, bring up the interfaces, and then
21:01
using the MII tool in Linux, we can actually reset the link by forcing speed renegotiation. So, it actually will physically drop the link and bring it back up so we can simulate disconnecting the cable remotely. So, that's
21:22
pretty cool. Let me get my VM set up here. Any questions about anything so far? Wow, you guys still hung over or something? I was expecting a little more boisterous audience or something. Somebody have a question? I'm
21:46
sorry? Yeah. Yeah, since the bridging by default is done at layer 2, it doesn't know anything about what's going across the wire. So, it just blindly forwards traffic
22:03
from point A to point B. Yeah, I dropped the link because that's the easiest way to force a re-authentication. Typically, you can, if you drop the
22:24
supplicant side, it will say, hey, I'm Bob again, but the switch may or may not pick it up or be expecting it. You drop it on the switch side, the switch will say, who are you? So, by switching it, by doing it on both sides, you just simulate the link going
22:41
down and it forces the re-authentication. Correct.
23:14
Sorry about this. I had a little bit of, unfortunately, the switch I have takes like 10 minutes to boot from no power. So, I had to get things rolling
23:24
with the presentation before it was ready. Fortunately, hooking up two cables, it's not that hard to do.
23:58
Any other questions while I'm getting this thing
24:00
going? One more VM to bring up and then
24:39
hopefully this will be all working. Praying to the
24:45
demo gods. Yeah, they are. Actually, yesterday when setting up the demo, I ended up separating the USB
25:01
dongle from the USB portion on one of the four adapters I brought. I need three for the demonstration. That was a little stressful. I'll
25:40
get this switched over real quick as soon as the window of the machine gets finished booting.
26:25
Ah, yes, invariably. I'll tell you what. There's really not a lot to see with the transparent demo. I plug it in, it works. I'll get to the pre-populated one and I'll get this thing figured
26:41
out. One of the ports is not behaving right, so I've got to SSH into the switch and get that fixed. Anyway, it's fairly straightforward. You plug it in, it works. Interesting stuff is later on when you interact with the device remotely. So, anyway, right now on the device,
27:06
the bridge looks like a piece of wire. You don't really see anything. Um, it passes traffic from point A to point B. The EPOL traffic goes across just fine. All the traffic from the client goes across, uh, unmolested. And, um, so
27:30
from a proof of concept point, we've introduced, uh, 802.1X onto, or, introduced a rogue access device onto a network that's secured by 802.1X. Now, this is kind of like the
27:46
pet rock of, uh, exploits here. You just demonstrated that it works, but it's not really a lot of fun to play with. So, let's, uh, see what we can do to, uh, to fix that.
28:05
So, uh, what do we need to actually make our, uh, pet rock a little more fun to play with? Well, we need to, uh, first and foremost, not trip up any, uh, additional security measures that are, that are in place. Um, we really
28:22
don't want to, uh, to cause, uh, port security to get tripped because, uh, typically port security violations don't automatically get reset. So, it requires a human to come out and take a look or somebody calling and saying, hey, my computer doesn't work, what's going
28:41
on? Um, so that's, that's not a good situation to have. Um, for, we also want to make sure that we're NATing all of our traffic so that it looks like we're coming from the computer whose connection we're
29:00
piggybacking. And we want to establish callouts. Um, sticky macs, like I mentioned, typically are, uh, that's a pretty fatal problem to have if you drop one of these devices in remotely because it's a real sign that something's going on that shouldn't be going on. So, try to avoid that at all costs. However, you can typically force an
29:23
802.1X authentic, reauthentication without any sort of, uh, ill effects simply because there's going to be so many different devices out there that reboot periodically or the connection goes away or a switch gets, uh, rebooted or
29:40
something. So, seeing reauthentication traffic usually doesn't set off any alarms. Now, uh, port security, a single stray MAC address flying across the wire will be the end of you. So, you have to make sure that no traffic leaves until everything is set up. And we're going to start dark and slowly bring
30:01
up functionality until we're good to go. So, things that have bitten me in the past. Uh, excess services. Uh, Apache is really good at that. What's the first thing Apache does when it starts up? Sends out a name server request for its IP address because typically
30:22
it's going to be host www.cnn.com. What's the first thing it does? Oh, who is www.cnn.com? Sends out a name server request. Well, a name server request goes on the wire. So, if you're not paying attention, that's something that can happen in the background. Many other services also do the same sort
30:41
of thing. Uh, IPv6. Um, most modern kernels will automatically have IPv6 support enabled and there may or may not be IPv6 traffic on the wire that you're on. But, since I'm not doing anything with IPv6, it's best to disable it because it has burned me in
31:01
the past. Uh, DNS, like I mentioned, sometimes simply starting networking under Linux can cause a DNS query to go out. So I typically blank out the resolve conf to make sure that doesn't happen. And then, uh, ARP is usually the, the culprit for all of the
31:23
woes when it comes to tripping port security. Because everything you do, if it doesn't know how to get to that particular IP address, it fires ARP and off, uh, fires off an ARP request. So, simplest thing to do is to make sure you don't fire off any ARP requests. Uh, ARP tables is a
31:43
tool that, uh, allows you to, uh, block all ARP traffic from an interface. Now, using the output chain here, uh, the output chain is only used by traffic that leaves the local network or leaves the local
32:01
device. So traffic going across the bridge actually traverses the forward chain and not the output chain. Uh, this is a quick overview of the basic chains that are, uh, IP tables, ARP tables, and EB tables. Pre-routing, all traffic coming into the device,
32:21
uh, passes through the pre-routing chain. Forward is traffic moving from one interface to another, so the bridge traffic traverses the forward chain. Input is traffic destined for the local device. Output is traffic leaving the local device, and post routing is all traffic that leaves the local device, or, uh, including the,
32:42
uh, the forward. So all traffic crossing the bridge will go pre-routing, forward, post-routing, so we can manipulate the output chain as much as we want and not affect any of the traffic that's going on with the client. So, uh, MAC addresses are
33:04
actually pretty easy to spoof, but, uh, since we're operating at layer two, they can cause some unusual problems. Um, and since we need to interact at layer three, uh, in order to be able to remotely communicate with the device, uh, there, there's
33:22
a better solution out there, and it's called EB tables. Uh, EB tables basically allows you to specify a series of rules that operate on the bridge itself, and, uh, the easiest, the best thing it does is allows you to NAT with MAC addresses. Uh,
33:41
so yeah, we want to be able to interact with the device. Makes sense. Um, we can use source NAT with IP tables to, uh, create, uh, to, um, to NAT all of our traffic to make it look like the device that we're in front of. Now, uh, with source
34:01
NATing, there is a quick caveat, namely that in the most modern TCP IP stacks, connections are internally by source IP, the tuple, source IP, uh, source port, destination
34:23
IP, destination port. Since we're stealing a client's connection, if we interact with the same device that our client that we're stealing is interacting with, we're automatically matching potentially three out of four
34:41
of the connections. So if we're going after the local domain controller on port 135, we're matching the source IP, the destination IP, and the destination port. So the source port is the only source of randomness that we have left to play with. So what
35:04
would happen if we actually jumped all over a connection? Um, in all honesty, the connection would probably reset and things would move on to normal, but it would be weird to stomp all over an active client's connection, and it's not terribly stealthy. And
35:22
in a real, in the theoretical world, we have basically a 1 in 64,000 chance of stomping on a connection that way. However, Microsoft, in their infallible wisdom, thought that 64,000 ports was just too big of a
35:41
number. So on 2000 and, 2003 and XP, TCP and UDP source ports would pretty much always be in the range of 1025 to 5,000. That is less than 64,000. You actually have on an active machine a really good
36:01
chance of stomping all over that. Plus, if your traffic, when you net out, uses port 6,000, that's weird, because all XP and 2003 traffic will be from 1025 to 5,000. And then Vista 7, 2008 uses 49,
36:21
152 to 65535. So what we can do is we can use, we can specify ports that we use with our source netting so that we will restrict our traffic to be in a particular range. Now in this particular example, I'm
36:41
using, restricting it to a thousand ports and assuming we're going after a Vista 7, 2008 client. It's in the high end, so the average, unless you're on a machine that has seen a lot of activity, it will, you'll occasionally run into a chance of stomping all over it, but hopefully you won't.
37:04
We can use destination net to create a virtual service that only we can connect to. So by SSHing to, say, port 9876, we can have the IP
37:21
tables pick off that connection and redirect it to local host 22 and we can SSH into the device that we're using. So we can use this as a call to the machine. So you SSH to the client and the client computer will never see it, it will get picked off by the bridge. And we can
37:42
further restrict that by putting a source IP address on the statement there so that only traffic coming from one particular IP or a series of
38:01
networks or whatever you want. So if anyone else tries to go to that port, it'll just go right to the computer and won't see anything. We can also set up a reverse shell where we have the bridge call us. And in all honesty,
38:20
this is probably the safest way to go because if you're in a network that has 802.1X, you're probably going to allow random traffic from the outside world directly to your workstations. So it would be best to call out, but I've implemented everything both ways to
38:41
just demonstrate the technique. And there's plenty of ways to phone home, SSH, open VPN, netcat, whatever, it's all good. So we need a layer 3 IP address in order to do any of the translations with the
39:01
bridge. I chose something in the 169.254 reserved IANA range because this is the range that you will self-assign if you don't have access to a DHCP server. So in other words, it's something you
39:20
should never see flying across the wire. You're not going to be screwing with their IP space, you shouldn't have any problems interacting on the wire. Yeah, before we get too far gone, I want to mention that I haven't found a good way using
39:41
this device to actually interact directly with the client behind the bridge. You run into little problems like, since I'm stealing his network connection and I'm behaving like his IP address, what source IP address do I use for any communication with him? I mean, I
40:01
could set up a remote one and then just filter out all the traffic, but you need to make sure it's something that he wouldn't want to visit on a normal basis. It's really kind of a pain in the ass. So I haven't found a good solution to it. So the current scenario, we've got a,
40:22
since our group does full scope pen testing, we've got folks walking around inside their building, pretending to be employees, doing all sorts of fun stuff. So they've managed to give us a printer config. So we're going to take the information on the printer config, because if you've looked at any network
40:41
printer configs, they've got MAC addresses, IP addresses, network information, all that stuff, and pre-populate one of our little devices so that we can imitate the printer and then interact with that device. So once again, set up some shell variables, set up the
41:03
MAC addresses, set up the IP addresses, the network range, the interfaces that the bridge is using, bring up the bridge, start IP tables and ARP tables in drop mode so that no traffic will leave the device
41:21
while we're configuring it. One of the interesting side effects of creating a bridge in Linux is what MAC address gets assigned to the bridge. It's actually either the highest or the lowest MAC address. I can't remember which one it is, but invariably, it's
41:42
going to be the one you don't think it is. So I have a line in here using MAC changer to force the bridge IP to always be the switch-side interface. That way, moving forward, we always know what to use in our rules. So we bring up
42:03
the bridge interface, we add the local network via the bridge, we set up the default gateway, and we use the post-routing EB tables rule with NAT to NAT the MAC
42:22
address of the bridge to the MAC address of the computer. So now all Ethernet traffic, all Ethernet frames look like they came from the computer behind us. There's the IP tables rule to set up
42:41
the destination NAT. There's the source NATing rules that for TCP, UDP, and ICMP, start up an SSH server, which is listening, I believe, on the And then we drop the ARP tables
43:01
and the IP tables rules. And now we can interact with what's going on in the wire. So now, I think I've got everything set up.
43:24
So what I've got going on here is I have a plug that's in line with a fiber converter, because people seem to think that fiber is the end-all, be-all solution to all of your network You can't man
43:41
in the middle of this stuff, right? So I've got the fiber going to the switch, the fiber adapter
44:01
going into the plug, plug going into the computer. So assuming everything's working right. Let me see what the switch has to say about that.
44:21
And of course it's not. Gotta love it. Give me one sec. Typically, this particular problem I have to reroute the firewall. I also love it when demonstrations go smoothly.
44:42
So anyway, while I hopefully try to debug this, anybody have any questions so far? Anybody still awake?
45:13
Yeah. Yes.
45:21
Yes. Yeah.
45:41
I guess I should repeat the question. I'm just too quiet. I'll eat the mic. You'd mention that you have a hard time hiding or interacting with the host that you're hiding in front of. Right. One of the things that popped in my head,
46:01
and it might not actually be a feasible idea, but one of the things I do is load balancing. And you got a load balancer hiding in front of a bunch of servers. Right. Acting transparently. Have you thought about any of those kind of methods, LVS or pound? Well, the problem you have is, let's say you want to do a port scan on the device.
46:20
What source IP do you use? What source IP do you originate your NMAP scan from of the client behind you? Oh, okay. Do you pretend to be the domain controller? Do you pretend to be www.china.com?
46:41
That's the problem that I haven't really found a good solution for. All right, that makes sense. Now granted, the traffic is only going to go from here to here on just across a single wire, but if they have some sort of an IPS or a HIPS install,
47:01
you would probably want to try to mimic something on the local wire, but like I said, I just haven't really found a good solution for that. I mean, I could see all the traffic going just fine, but just establishing a two-way communication, I just, you know, I'm open to suggestions.
48:23
All righty, let's see if this works. Got time for a comment or no? Yeah, go ahead. There's sort of two approaches there. You could actually use any IP. Yeah, I mean, that's the thing. You can use any IP. Then it gets a little bit
48:40
more complicated with, you know, your IP tables and EBTables stuff, but you could also just pick any IP that's on the local subnet there. Those are the two options you're sort of limited to. My big concern is, I don't want to do something on the local wire that would potentially
49:00
adversely affect anything going on. I mean, you'd have to limit the, you'd have to limit it to a particular series of ports and things like that. Plus, I wouldn't want to run afoul of any sort of, like host intrusion profession system, something like that. You know, because if they only allow you
49:20
to talk to local networks or something like that on the client or the client firewall or something like that, you could run into some problems. It's, like I said, I haven't found a good solution. There's a bunch of okay solutions.
49:42
Using the gateway to come back, I can barely hear you, sorry man. What about using the gateway of the network
50:01
that the client's on? The gateway rarely talks directly to the client. Well, what the problem is, if you communicate with the gateway, the traffic's just going to come right back to you because you're in line. But use its IP address. Oh, so use the gateway's IP address.
50:20
I got you. That's possible. That might work. You'd still have to do some restrictions on the NAT and things like that, but that's a possibility. I'll look at doing that.
51:00
Oh guys, I'm sorry. This demo is just not going as planned. Yeah, that's also a possibility. That's something worth looking at. It,
51:22
yeah, I mean, you're depending on the client actually using IPV6 to be able to respond to it, but most Windows clients actually by default, unless you go in and change it, won't do anything. all right,
51:43
this is going to be one of those days the demo got to take me one more time,
52:08
and then I'm just going to move on. Sorry guys. Unfortunately, watching traffic go across a wire in a complicated setup is kind of not really much to look at anyway.
52:22
Yeah, yeah, I typically drop both. Yeah, the connection will still stay hot. Yep, and then the client, when it comes back up, will probably send a re-authentication.
52:42
The switch goes, yeah, okay, you're still good, but thanks for telling me. Yeah, I touched on that a little bit later on, but typically, I mean, since all the packets are going through, it can add up to a few
53:03
tens or possibly hundreds of milliseconds, depending on how much traffic is going through. But for the average network, you're not really going to notice that. I mean, that doesn't really affect, you know, somebody surfing eBay or checking their email or something like that. Most people are sadly conditioned
53:22
to expect delays when doing simple tasks like that. They assume it's the internet, not their local link, and that's even if they notice that it took a few extra milliseconds.
54:02
Best laid plans. And get up and juggle, but you know, I probably wouldn't want to see that. All right, so I can talk through the rest of this and maybe I can get this stupid config to come up by the time we're done.
54:20
So pre-populating the bridge is cool, but it's nowhere near as interesting as just being able to walk in, drop a device onto the network and walk away. Uh, so the basic process would be you start transparent, you gather up all the info you want off the wire, take a look at it, analyze, find the useful bits,
54:41
and then you, uh, configure the bridge and bring it up. So, the printer config we had before provided the IP address, the MAC address, network mask, and the gateway IP. But, what if we can't easily get that information? Um, what we really need is
55:01
the IP address of the computer, the MAC address of the computer behind us, and, really, all we need is the MAC address of the gateway, because the gateway knows how to get to everything, and so if we set the gateway to be the destination for all of our ethernet frames, it'll figure out where to send it. So we don't even need it
55:20
to talk to the local, we don't need anything other than the MAC address of the gateway to communicate with anything on the local segment. assuming we have the gateway MAC, how would we bolt that into our configuration to make it work? Well,
55:40
we can create a static ARC entry for a bogus IP address, and then route to that bogus IP address, and basically set that as the default route, and, the layer 3 stuff is happy, the layer 2 stuff is happy, and away we go. Uh, that does actually cause a bit of an issue
56:01
when interacting with the local network segment, because, remember, the local network segment's usually the only thing the computers know how to talk to on the local network segment, they communicate directly with the other machines on the local segment. So,
56:20
the way we're transmitting our traffic would be fire to the gateway, the gateway would come back to the local segment, which can cause some interesting things. I've seen our traffic appear to the client that we're attacking to actually be sourced from the gateway, so the gateway almost natted it.
56:42
Huh? Yeah. But, the traffic goes out that way, but it comes directly to us, which is an interesting little side effect of what we're doing. We can fix it, but, uh, I'm of the opinion that if we're on an assessment
57:00
and somebody figures out that something weird's going on based on local MAC addresses on a local segment, uh, I think they got their shit together. I think that's a safe assessment. So anyway, for a typical network, what sorts of assumptions can we make?
57:21
Since 802.1X is a big, hairy, complicated beast, it's probably safe to say that your average mom-and-pop five-computer shop is not going to be implementing it. So it's going to be a fairly robust infrastructure. There's going to be a server subnet or network. There's going to be a workstation subnet.
57:42
There's probably some sort of a firewall or a router in between routing packets. Network services, such as active directory, DNS, web, et cetera, in all likelihood, are not going to be in the workstation segment.
58:02
So we can use that later on. So if we watch the packets crossing the bridge, what sorts of traffic would we expect to see? Obviously, you know, anything UDP, RTCP, but what would be most useful for gathering the information we need?
58:21
Once again, we need the computer's MAC address, the computer's IP address, and the gateway's MAC address. Well, UDP, DNS, there might be some worthwhile information there. The problem there is sometimes, depending on the firewall configuration, the local firewall burb could actually act
58:41
as the local segment's DNS server. So while that would be interesting, and it could work, I would rather look someplace else to try to make it just be on the safe side. LDAP's another possibility if you're in an active directory environment.
59:02
DHCP is not really useful, and NetBIOS isn't terribly useful. So UDP, aside from grabbing the DNS for use later on, I don't really think that UDP is the way to go. ARP actually is a pretty good candidate because it's got all the information we need.
59:22
It'll have the IP address, it'll have the MAC addresses, the only problem with that is, you have to, the way the questions are structured, it asks a question, and it says, who has this IP address?
59:41
Tell this other guy, and then ARP will respond to that other guy, I'm here. Well, you can get the MAC address from the reply, but in order to figure out who asked the question, you have to go back and look at the question itself, so it's kind of a two-step process. It can be done.
01:00:00
And on a local network segment, it's probably a fairly safe guess that if you captured 50 or 100 ARP packets, that the gateway is going to be the most ARP'd for item on the local network. Because that's where, assuming you're on a client VLAN, that's where most of the
01:00:23
traffic is going to go. Now, you could run into problems if there's services being offered up on the local machines or there are file shares among the workstations or things like that, which is why I can't really give ARP the official seal of approval, but it does work fairly well.
01:00:44
So it works. I've implemented it. It seems to be the fastest way, especially given the fact that local networks will ARP out fairly frequently, every 15, 45 seconds for modern Windows OSes.
01:01:02
So you can typically get it up and going fairly quickly in a matter of a couple minutes of just sitting and watching. But I think TCP is actually the way to go, because you can get everything in one packet. So if you send a SYN request, and you're in an Active Directory environment, you send a SYN request out for Kerberos or web or whatever, it's going to have the source destination,
01:01:28
the source MAC of the computer, the destination MAC of the gateway, because it's going outside the network, and it will have the IP address of the client behind it.
01:01:42
So you can actually pick off everything you want just by grabbing one packet. And just coincidentally, a cold boot of a Windows box on an Active Directory network sent out 600 or more TCP packets to the domain controller immediately after booting
01:02:07
up. So there's a lot of traffic if you can force a reboot, plus every 15 minutes or so when the Kerberos tickets expire, there will be another burst of traffic. So as long as you're patient and willing to leave the device up for a while and you're
01:02:23
on an Active Directory environment, you'll get all the traffic you need to be able to self-configure. But like I said, it takes a little while. So I've done it both ways. ARP is generally faster, but potentially unreliable. TCP is going to be more reliable, but takes a little while.
01:02:45
To implement it with ARP, you just capture a bunch of ARP traffic, do a little gymnastics with a Unix command line to a capture file. You read from the capture file.
01:03:02
You grep for the questions. You grep out the information. You sort it. You count it. You sort it in reverse. So you get the top number of the top item that was ARPed for on the local wire. And then you can, using that information, go back into the file and figure out who asked
01:03:24
the question so you can get the last piece of information you need. So TCP is actually really a lot easier. You just wait for the one packet you want and grab all the information you need.
01:03:41
I use Kerberos because in an Active Directory environment, typically Kerberos tickets will be going out periodically. You're guaranteed that the Kerberos ticket is going to go to a domain controller. It's not going to go off in the never-never land. And in all likelihood, the domain controller is not going to be on the local segment with the workstations.
01:04:02
So wait for one packet, parse through it, and away we go. So the grabbing that information is actually pretty straightforward. You know, you read. You capture the packet. You dump it to a file. You read it from the file. You awk out the information you want.
01:04:23
And you get the source MAC, the destination MAC, the computer IP. So the fully automated script set up the various interfaces. I went ahead and automatically grabbed the MAC address of the switch side of the interface.
01:04:42
Computer interface, bridge interface, all the stuff's the same. Bring up the bridge, switch the MAC address, reset the link. So at this point, we're up transparent. So now we wait with the TCP dump line until we see a Kerberos packet fly across the wire.
01:05:05
We then basically awk out the information we want, set it to the variables, set up the ARP tables and IP tables to drop all of our traffic, configure up the bridge interface,
01:05:22
set up our NAT rules, start up SSH if we're listening, set ARP tables and IP tables to drop the rules. And once again, we're still not unfortunately going real well with the demo.
01:05:43
I'll see if I can get it working here in a few minutes. But I'll just kind of press on through since things aren't going well on the demo side. So is there any good way of detecting whether or not this is going on in the local wire?
01:06:02
The answer is probably not. Yeah, user awareness. The same guys that bring in laptops from home, bring in picture frames pre-infected with malware to plug into their computers, you know, the ones that leave the badges,
01:06:20
piggyback, do all those things that users aren't supposed to do on your network. They're probably the best people to figure out what's wrong in their cube. Unfortunately, you could probably put a sticker on something like this with network cables running in and out of it says network signal booster and defeat the first line of security.
01:06:48
But in all honesty, this is a physical attack. So physically looking at the wires, physical inspection is the best way to see whether or not something unusual is plugged into your network.
01:07:00
Now, if you have a hundred thousand square foot building with thousands of network drops, obviously the users are the best way of doing that. So you have to be able to empower your users to be able to look at what's under there and ask questions if they see something that they think they shouldn't. Unfortunately, most places aren't like that.
01:07:22
Most admins don't want their users anywhere near anything that they could screw up. So in all likelihood, user awareness is probably not the best way to go. Perfect world, yes. So traffic analysis. Now the packets that we sent out are being sourced from a Linux box.
01:07:43
So the TTLs will be by default 64, whereas Windows boxes are usually 128. Now we can change this, but once again, if you figure out something, the hankies going on your network by noticing that traffic leaving the local subnet has different TTL values, I am more than willing to give you the thumbs up.
01:08:09
It's possible, but most of the environments I've been to, it's highly unlikely that this will get caught. And the default TCP window size differs between Windows and Linux.
01:08:23
And there's some tunables, I've played with it, but it didn't really seem to do much. So once again, if you've got your stuff buttoned down to that level, hey, congrats. So like I talked about, there seemed to be a lot of traffic destined for the local
01:08:45
network coming from the local segment as a side effect of our using the MAC address of the gateway to do all of our routing. We could probably fix that just by watching ARP requests on the wire and creating static
01:09:00
ARP entries for every item that we see, so we can communicate with local devices without going through the gateway. And probably wouldn't be too hard to repurpose something like ARP watch to do that automatically for us. But you know, if you're capable of seeing that something weird like that is going off
01:09:23
on the network, then hey, more power to you. Latency. Yeah, it can add up to a couple orders of magnitude on packet latency. Seems like on local tests I've done on 100 meg, it maybe adds 40, 50 milliseconds,
01:09:45
if the link is saturated it might go higher than that, but the average user isn't going to catch that. Same thing with throughput, I managed to SCP a three and a half gig file through one of these plugs on a 100 meg link and it went through at about 70 megs, so that's
01:10:05
actually pretty good. It's not horribly slow. Now, some of the embedded devices out there, you know, if it's running a really slow processor you could probably run into some problems, but these plugs for example are 1200 megahertz,
01:10:22
so you probably got enough horsepower. I haven't been brave enough, and I don't have a USB gig adapter, but I haven't been brave enough to try gig to see what kind of throughput you actually have to push through it to break it. But large files over 100 meg don't seem to be a problem.
01:10:43
Speed duplex mismatch, so if you're running gig and all of a sudden a port drops to 100 meg or something like that, well that could be a sign something weird is going on. But in all honesty I think for any large environment the chances of every single device
01:11:00
on the network being all the same is probably pretty low with lifecycle replacement and things like that, plus you'd have to be really awake to be able to catch the fact that port 3 on switch 5 building 3 floor 2 switched from gig to 100.
01:11:22
That seems like just a noise level alert that unless you were looking specifically for something weird like that you probably wouldn't catch. I could be wrong, but so once again the likely result is probably not going to be able to see to detect it that way.
01:11:43
Excessive up down notices, touched on this a little bit earlier. In all honesty the authentication server is probably going to see a fairly steady stream of requests coming in and out. Link statuses go up and down a fair amount, it's pretty easy to kick a cable, it's pretty
01:12:04
easy to unplug, reboot a machine, even a switch reboot, stuff like that. All that would cause a link to reset and even a flaky cable.
01:12:20
So I don't really see that that would be a reliable way, but it's something that if you had a SIM you could probably try to picture, come up with an event for and maybe see what you consider to be excessive up down notices on a particular link if that's what you want to try.
01:12:41
So sadly the best technological solution is to really understand the characteristics of what your network traffic looks like and then focus on trying to look for anomalies. So yeah, we don't have any Linux boxes on the wire, so why are we seeing TTLs of 64
01:13:00
leaving our network? Well yeah, good luck with that. The other possibility would be link speed to changes or excessive up down notices, you might be able to come up with some sort of a SIM event for that, but in all honesty I don't really see that that's a realistic way to detect this. The best method is probably user awareness, like everything else.
01:13:26
Educate your users on what should be under their desk, let them know what a network cable looks like, let them know what a fiber transceiver looks like if you use fiber, and let them understand and be a part of your security, incorporated into your annual
01:13:46
security refreshers or your monthly refreshers as necessary, and encourage them to ask questions. And you know, the problem is if you find one of these devices on your network, you
01:14:01
should probably be pissed off, but you should really be pissed off about how it got there and not the fact that it is there. You know, because someone walked into your office, walked past the guards, walked past the secretary, walked past the users, walked into somebody's cube, monkeyed around underneath somebody's desk, and put one of these in, and nobody raised a flag.
01:14:24
So, what sorts of fun things can we do with this? You can poison web traffic, obviously you're in a perfect position to man in the middle. Ettercap has done some initial work on that. I haven't had a lot of time to do any extensive testing on that, but I think that's a potential
01:14:47
for a lot of fun to be able to do any sort of client-side attack on any website by proxying through the device itself. You can obviously capture credentials, you can scan the network.
01:15:01
You know, imagine sending a phishing email where the email just appears in the inbox without actually hitting their server, because you just injected it into the IMAP stream. That would be something kind of fun to play with. I haven't had a chance to implement any of that stuff or even look at implementing it, but I thought the email thing would be kind of a fun thing to do.
01:15:24
You can pivot through it. You know, if you set up an open VPN callout, you have a full connection you can route traffic through, you're already set up to NAT, you can do whatever you want with it. And plus you're blaming the guy behind you. So anytime a network defender would see something weird, they'd RDP into that box,
01:15:45
go, what the hell is going on here? And you got the perfect alibi. You could also have callbacks that are directed inwards. So you set up a listener on the plug computer itself and have all your local callbacks
01:16:04
call back to it and have it call back to the outside world, or you can just interact with it on the plug. Or if you're using one of these, you have a full backtrack distribution available to you so you can do anything you can do with backtrack on the thing remotely.
01:16:22
And these are also useful for a trusted insider type of assessment. You could just configure up the plug, ship it out, tell them to plug it in somewhere, and you'll get back to them in a couple weeks after you've finished your assessment.
01:16:41
You can save on travel costs, and it can be a huge savings. Rather than sending a team of two or three people out all over the world, you can just drop ship a plug to them and surf from the comfort of your home office or wherever you have the plug calling back to.
01:17:01
So yeah, what are the common stories I've heard? Fiber. Like I said, people seem to think that fiber is the ultimate solution to all your network problems, that you can't man in the middle with it, you can't do anything with it.
01:17:21
And yeah, you can hook up fiber Ethernet, you can run another fiber connector transceiver on this, you can even hook two fiber transceivers up with a fiber cable. And it still works. IP still works, Ethernet frames are the same, it's just a transport medium. That's it. Nothing special.
01:17:44
So yeah, I mean, if you have a, obviously if you have fiber on your network, you run into some logistical problems with having the right cable connectors and using the right kind of fiber and stuff like that.
01:18:02
But if your organization is reasonably well funded, that's not really an issue. You just pick up some gig, you pick up some 100 meg, you pick up a couple dozen cables with all the various ends you could find on it and you should be good to go. Yeah, it's more stuff under a desk, but it's still, it's not a major barrier.
01:18:24
Yeah, a lot of people who I've talked with who have fully implemented a NAC solution with agents that do policy routing decisions seem to think that 802.1X is the end all be all network security solution amen.
01:18:43
And that is really not the case. 802.1X just authorizes the port to go alive and route traffic. It doesn't do any sort of per packet authorization. It doesn't do any sort of per packet anything really.
01:19:00
It just says this traffic can go through the switch and go wherever it needs to go. And the agent doesn't really change any of that. All it does is it will check to make sure that the computer behind it has the information it needs to make a decision. So if the patch level is up to snuff or you log in or you remember a domain or whatever the criteria are,
01:19:26
it will still hook you up to the network just the same. And the bridge will pass the traffic just the same. So, yeah, how do we defend against something like this? Well this is a physical attack.
01:19:42
I can't do anything to your 802.1X network if I'm outside the building. It's just the way it is. I have to have physical access to a computer that's authorized to implant the device on it. So if I can't get in the front door, guess what?
01:20:01
I can't do anything, which is sadly the way it is for most attacks. And it requires an authorized port. So if you're in an environment where you have laptops and you lock up your laptops at night and there's a clean desk with no network equipment, no nothing, well, not a lot to work with there.
01:20:23
So you would notice some weird device plugged into your network waiting for you to plug your computer in in the morning. IPSEC could be used to mitigate some of the man-in-the-middle issues. Microsoft's NAP solution basically establishes on top of 802.1X IPSEC tunnels point-to-point between all of the clients and servers.
01:20:53
So you wouldn't be able to man-in-the-middle easily any of that. In all likelihood you wouldn't be able to man-in-the-middle any of that at all.
01:21:01
But you still have to connect to the internet and unless you route all your traffic through a proxy over an IPSEC tunnel, you're still going to have web traffic and stuff like that that goes out in the clear. So there really isn't, I mean aside from locking your doors and making sure people know what's going on,
01:21:23
there really isn't a good defense for this. So 802.1X is a standard that just gives a yes or no question or yes or no answer to can this device attach to the network.
01:21:42
And is it allowed to communicate on the local wire. It doesn't do per packet authorization, it doesn't do any sort of validation that the traffic is legit. All it does is say yes, this guy can plug into the network, it makes support go hot.
01:22:06
So one of the things that I wanted to make sure people took away with was 802.1X, it does exactly what it's supposed to do. It's when you start getting all the vendors speak on top that starts clouding what its purpose is and what it does.
01:22:24
So anyway, anybody have any questions of the dozen or so people that are left? What's up man? Yeah, we got nothing but time. Almost scared everyone off.
01:22:43
What's up man? Hi. Hello. Just a little comment. In your scripts I noticed that you didn't turn off STP. So your interceptor machine, your man-in-the-middle could be leaking STP advertisements.
01:23:01
By default? Yeah, by default. If I recall correctly, it is enabled by default when you bring up the bridge. In older versions of the bridge module it was enabled. By default now it is not enabled. It is not, right. But it might be useful to put a line in it. Yeah, that's something that I'll look at doing. So it gets slightly stealthier. Yeah, okay.
01:23:26
I was talking to the Pony Express guys in the vendor booth the other day, and I think they're using some of your technology, some of your stuff here in their boxes. And you mentioned that there's not an easy way to stop this.
01:23:41
And while it's not easy, there is a way. It's pretty new. You listed it in there. 802.1 AE, Maxsec, will prevent this. It's a nightmare to set up. Well, and 802.1 AE, I believe, I haven't done a lot of research on it, but there's only two Cisco switches out there that support it.
01:24:02
2960S and the 3750Xs will do it. Yeah, I can only imagine the nightmare it would be to set up. You'd have to, if I understand it correctly, you would have to upgrade your entire infrastructure to be able to support it. Well, on the switch side, you have to have switch support for it, but then you just need a supplicant that supports 802.1 AE.
01:24:23
It's actually kind of a, I don't want to say subset, but it's sort of a subset of 802.1X. They go through 1X negotiation, and then AE kind of kicks in and they negotiate security parameters. Yeah, it's... For those of you guys that don't know, it's encryption between the endpoint and the switch port.
01:24:42
It's encryption between the endpoint, the supplicant, if you will, and the switch port itself. So it prevents a lot of these sort of man-in-the-middle attacks that we've, I shouldn't say prevents, makes them a lot harder. There's still ways around it, but it's very, very hard. You can't stick an unauthenticated device on the network. Well, that's probably where things are going to be moving is on a more per-packet authorized basis,
01:25:05
but given the fact that, you know, how many successful deployments of 802.1 and AE are there in the world today, I would bet probably you could count them on one hand, and most of them are on a Cisco campus somewhere. Agreed. Agreed. Well, I'm just saying if you want an answer, though...
01:25:22
Oh, yeah, yeah. Well, and that's probably the way to move forward with this. But, and it's, I would be interested to see, I'm sure like anything else, it's a patch to the existing problem. I'd be very curious to see an actual implementation
01:25:40
and see how well it would take care of an attack like this. Sure, cool, thanks. Yeah, no problem. Let me again, another remark. Perhaps there is a solution to this, but it's as extreme as any other ones that... Could you speak up a little bit? Yeah, perhaps there is a solution to this, but it's also very extreme.
01:26:03
If we dropped A201.X at all, and everyone connected to the network over OpenVPN or something like this, and do an entirely different layer to handle this, because, but it's just as you said about IPsec.
01:26:25
Yeah, I mean, it's the same sort of thing. You would either have to make sure all of your traffic went over that. Like I said, the NAP solution from Microsoft, that's one of their big points that they tout. Yeah, but it's the only solution, the realistic solution that I can think of.
01:26:42
Thank you. I had a quick follow-up to my previous question earlier. I brought up the TTL thing, and basically what I was wondering was once you move from fully transparent layer 2, you assign an IP to the bridge, you've moved into layer 3 territory, correct?
01:27:00
Well, what happens is the bridge, the traffic that is coming from the client will always traverse the bridge interface. It will always be considered transparent. Okay. So the only time that you see traffic that would have a different TTL would be as if it's traffic that you injected onto the network yourself.
01:27:20
Okay, so that's interesting. I know, so I've done some similar things in FreeBSD, and it's a little bit differently. Because as soon as you assign an IP to the bridge, it actually will start, you'll see a TTL difference. But one thing that I do like about FreeBSD that might help out in certain things is, I'm not sure if something's available for Linux that does this, but like with PF and dummy net,
01:27:44
you can simulate and spoof latency and TTLs. And so you could actually, you could watch for the TTLs of the client sitting behind and then spoof all of those TTLs. Well, and there's a fairly easy Linux kernel tunable in the proxys net IPv4,
01:28:05
IP default TTL, I think is that you could just do the same sort of thing so that you could match up the TTLs, just see what TTLs are on the client. But for the assessments that we do, I'm not trying to be perfect.
01:28:24
Because if they can catch, I mean... The only time I've seen environments where people are looking for that is where they're looking for like rogue access points plugged into... Yeah, well and it's the same sort of thing. I mean, if you're in an environment where you're actively hunting for rogue devices, and you know, we were able to implant a rogue device and you caught it,
01:28:44
okay, that's good for you. The next step for us would be to, you know, match up the TTLs and see if you could find it now. So it'd be kind of a multi-stage kind of thing. But most of the places I've been to, even if they were hunting for, you know, rogue APs,
01:29:00
they wouldn't necessarily be looking for it on the wire. They're hunting it down over the air. So they spend a lot of time and effort triangulating and trying to figure out wireless signals and things like that, and not necessarily, you know, watching all the traffic flying across the wire. But it's a good point. Okay, and then one last thing.
01:29:21
In your previous question about talking about interacting with the client behind the point, have you considered using any scripting to... Because you're sitting right there, so you can obviously analyze all the traffic between the client and the network, so using T-Speed Dump to like maybe gather some metrics on what IPs, other neighboring hosts on the network that that guy is allowed to talk to and then spoof those.
01:29:43
Yeah, I mean, there's ways of spending, you know, some time to do... Yeah, like you said, you track conversations for an hour and you see who he's talked to the most, who he's talked to the least, and you probably would want to try to pick the guy that you talked to the least so that you don't stomp on anything.
01:30:01
But, you know, it's for what we're doing, for interacting with the network and whatnot, I figured that not being able to talk to the guy to my right is okay if I can talk to everybody else and make it look like he did.
01:30:22
So that was kind of the approach I took because, you know, it's just... If you're on a workstation network, in all likelihood, you know, most of the workstations are going to be configured fairly similarly so you can get a similar effect communicating and mapping them out than, you know, the guy behind you. All right, thank you. Yeah, I mean, it's worth looking at.
01:30:41
All right, thanks. Uh-huh. What's up, man? I have a question in regards of a typical configuration when you have a IP phone connected to the switch and then the workstation is connected to the IP phone.
01:31:02
Is this attack going to be possible if you implement the devices between the IP phone and the switch, which would be the typical point where we can insert this device? Since there is a CDP and there is a... pretty much the port becomes like a transport and there are further complications.
01:31:25
In all honesty, I don't know because I haven't tested it in a configuration like that. My guess is in the purely transparent form it would probably work because it's just... to the network it would look like a piece of wire.
01:31:42
But as far as being able to interact with the traffic, obviously, it might not be able to. So I honestly couldn't tell you. So is this bridge going to support CDP? Probably that's what it's going to come down to.
01:32:02
Uh, yeah. In all honesty, I haven't tried setting up CDP, setting a bridge up and seeing if the other guy saw it. Off the top of my head, I can't think of any reason why it wouldn't support it, but I haven't tested it specifically.
01:32:21
Thank you. Yeah, that's what I was thinking. I mean, I haven't tested it, so I can't say for certain, but you know, I was thinking it was just straight layer 2, so it ought to just, you know, ought to work.
01:32:42
Anybody else? Anybody know any good jokes? Alright, well, thanks for surviving my presentation. I'm glad I survived.
01:33:00
Wish I had a little better luck with the demos, but unfortunately I didn't sacrifice enough. So thanks for coming out. I guess we'll head over to the question room. Which room? Yeah, we'll be in Q&A room number 4 after I get all this crap torn down.
01:33:22
Thanks.