 My name is Skip Duckwall, I'm here to talk about bypassing wire data to an X with a bridge using Linux, so I'll just kind of get right into it. Oops, it's not, is that pushing 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, transitioned to IT Security a while back, got a whole bunch of 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 odd balls like Q, picked up X a little while back, but anyway, I worked for 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 device that we can inject traffic with, communicate with, 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 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 laptop with two network cards, you know, a little USB ethernet cards in them. The upside is they're X86 based so you don't have to worry about any cross compiling or anything like that. You can use backtrack, but you know, 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-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 an atom based industrial PC, pretty small. This one's got two ethernet ports already on it, a 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 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 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 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 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, and yeah, alarm company, that's a good one. 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 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 typical Ethernet frame without using 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 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 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 at the 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 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 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 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 and figure out what the next hop router is. It will check its 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 and it will construct the Ethernet frame and the frame gets fired off down the line. IP is the extensible authentication protocol. It's not really 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 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 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, usually radius, something like that, that takes 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. 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 an radius request. The authentication server takes a look at it and gives the ultimate decision and then if successful, the traffic is allowed to pass through the network. There's a quick wire shark capture of EAPOL exchanged from front to back. 802.1x also has the ability through an agent on the supplicant side to make network policy decisions. For example, you can have an agent that will check to see if a road warrior's net book is up to date with patches and has a current AV. If not, it'll instead of allowing it onto the general business land, it will shoot it off to a remediation subnet where the only things it can talk to are the AV server or a remediation server of some sort to get brought back up to speed, scan, whatever, and then you can fire it back over to the work station 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. You can also use it to load balance to a lesser populated VLAN. 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 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 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. You also, for your 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. 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 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 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 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 machines, as soon as it goes back to CMOS, drops its link. 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 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 network. In 2004, 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 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 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 link section. 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 SIN packet, a SIN act comes back, well, a legitimate device, if it sees a SIN act packet because a hub will broadcast to every port on the hub, it'll respond with a reset act. Well, your rogue device will respond with an act, so it's a race whose packet will get to where it's going first, and even then the whole time it'll be cause and problems. So 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 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 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 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 the same types of traffic, that can cause, that can raise some flags if you're paying attention, that sort of thing. So my demo configuration is mostly virtual. I've got a server sub net that has a radius box, a domain controller, and a WSUS server. It's set up to separate it out by a firewall. 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 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 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, but it's also available, I believe, for the 2.4 as well, standard in most distributions. There's some user land 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 bridge is fairly straightforward. You create the bridge interface, in this case I use BR0. You add nicks 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 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 E-POL uses is supposed to be dropped per spec on 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 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. But fortunately, there's a gentleman, Ab at Gremel Security, who figured it out. He wrote a tool called Marvin that is a Java-based tool that is used to inject traffic onto an network using 802.1X, wired. So he figured out what you needed to do. It's written in Java, it requires three network ports, a source, a destination, 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 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 E-paul traffic, and now we can pass E-paul on the 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 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 pretty cool. Let me get my VM set up here. Any questions about anything so far? Wow, are you guys still hung over or something? I was expecting a little more boisterous audience or something. Somebody have a question? I'm sorry? Yeah. Yeah, since the bridging by default is done at layer two, it doesn't know anything about what's going across the wire. So it just blindly forwards traffic from point A to point B. Yeah, I dropped the link because that's the easiest way to force a re-authentication. Typically, if you drop the link on the 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 down and it forces the re-authentication. Correct. 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 with the presentation before I was ready. Unfortunately, you know, hooking up two cables, it's not that hard to do. Any other questions while I'm getting this thing going? One more VM to bring up and then hopefully this will be all working. Praying to the demo gods. Yeah, they are. Actually, yesterday when I was setting up the demo, I ended up separating the USB 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 get this switched over real quick, since the machine gets finished booting. Ah, yes, invariably. There's really not a lot to see with the transparent demo. I plug it in, it works. We'll get to the pre-populated one and I'll get this thing figured out. One of the ports is not behaving right, so I got a SSH into the switch and get that fixed. But anyway, it's fairly straightforward. You plug it in, it works. The interesting stuff is later on when you interact with the device remotely. So anyway, right now on the device, the bridge looks like a piece of wire. You don't really see anything. It passes traffic from point A to point B. The E-Pull traffic goes across just fine. All the traffic from the client goes across unmolested. And so from a proof of concept point, we've introduced 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 pet rock of X-Boy tier. You just demonstrate that it works, but it's not really a lot of fun to play with. So let's see what we can do to, oh crap, to fix that. So what do we need to actually make our pet rock a little more fun to play with? Well, we need to, first and foremost, not trip up any additional security measures that are in place. We really don't want to cause, you know, poor security to get tripped because typically poor 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 on? So that's not a good situation to have. For, we also want to make sure that we're netting all of our traffic so that it looks like we're coming from the computer whose connection we're piggybacking. And we want to establish call-outs. Sticky Macs, like I mentioned, typically are, 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 8 or 2 and X re-authentication without any sort of 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 rebooted or something. So seeing re-authentication traffic usually doesn't set off any alarms. Now, poor 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 up functionality until we're good to go. So things that have bitten me in the past, access services. 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 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 of thing. IPv6. 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 the past. 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 ARP is usually the culprit for all of the 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 off an ARP request. So the simplest thing to do is to make sure you don't fire off any ARP requests. ARP tables is a tool that allows you to block all ARP traffic from an interface. Now, using the output chain here, the output chain is only used by traffic that leaves the local network or leaves the local device. So traffic going across the bridge actually traverses the forward chain and not the output chain. This is a quick overview of the basic chains that IP tables, ARP tables, and EB tables pre-routing. All traffic coming into the device 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 device, including 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 MAC addresses are actually pretty easy to spoof, but since we're operating at Layer 2 they can cause some unusual problems and since we need to interact at Layer 3 in order to be able to remotely communicate with the device, there's a better solution out there and it's called EB tables. EB tables basically allows you to specify a series of rules that operate on the bridge itself and the easiest, the best thing it does is allows you to NAT with MAC addresses. So yeah, we want to be able to interact with the device. Makes sense. We can use source NAT with IP tables to create, to NAT all of our traffic to make it look like the device that we're in front of. Now with source NATing, there is a quick caveat, namely that in the most modern TCP IP stacks, connections are tracked internally by source IP, the tuple, source IP, source port, destination 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 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 would happen if we actually jumped all over a connection? 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 in a real, in the theoretical world, we have basically a one 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 number. So on 2000 and 2003 in XP, TCP and UDP source ports were 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 chance of stomping all over that. Plus, if your traffic, when you nat out, uses port 6000, that's weird because all XP and 2003 traffic will be from 1025 to 5,000. And then Vista 72008 uses 49152 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 using restricting it to a thousand ports and assuming we're going after a Vista 72008 client. And 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. We can use destination net to create a virtual service that only we can use to connect to. So by SSHing to say port 9876, we can have the IP tables pick off that connection and redirect it to localhost 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 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 networks or whatever you want. So if anyone else tries to go to that port, it will 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, this is probably the safest way to go because if you're in a network that has 802 and X, you're probably going to not 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 just demonstrate the technique. And there's plenty of ways to phone home, SSH open VPN, you know, Netcat, whatever, it's all good. So we need a layer three IP address in order to do any of the translations with the bridge. I chose something in the 169.254 reserve Diana 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 should never see flying across the wire. You're not going to be screwing with their IP space. You're not going to, you shouldn't have any problems interacting on the wire. Yeah, before we get too far, too far gone, I want to mention that I haven't found a good way using 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 could set up a remote one and then just filter out all the traffic, but you need to make sure it's something that, you know, 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, since our group does full scope pen testing, we've got folks walking around inside their building, you know, pretending to be employees, doing all sorts of fun stuff. So they 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 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, switch, set up the MAC addresses, set up the IP addresses, the network range, the interfaces that the bridge is using, bring up the bridge, start IP table, or IP tables and ARP tables in drop mode so that no traffic will leave the device 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 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 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 address of the bridge and then we add 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 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 bridge itself and then we drop the ARP tables 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. 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 woes. You can't man in the middle of the stuff right? So I've got the fiber going to the switch, the fiber adapter 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. And of course it's not. Gotta love it. Give me one sec. Typically this particular problem I have to reboot the firewall. I also love it when demonstrations get smoothly. So anyway while I hopefully try to debug this anybody have any questions so far? Anybody still awake? Yes. Yes. I guess I should repeat the question. I'm just too quiet. I'll eat the mic. You mentioned that you have a hard time interacting with the host that you're hiding in front of. Right. One of the things that popped in my head 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. What source IP do you use? What source IP do you originate your end map scan from of the client behind you? Okay. Do you pretend to be the domain controller? Do you pretend to be www.china.com? That's the problem that I haven't really found a good solution for. That makes sense. Now granted the traffic is only going to go from here to here just across a single wire but if they have some sort of an IPS or a HIPPS install 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. Right on. Alrighty. 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 more complicated with your IP tables and EB table stuff but you could also just pick an IP that's on the local subnet there. Yeah. Those are the two options you're sort of limited to. Right. Well my big concern is I don't want to do something on the local wire that would potentially adversely affect anything going on. So 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 a foul of any sort of like host intrusion prevention system, something like that. You know because if they only allow you 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. Sure. Using the gateway to come back. I can barely hear you. Sorry ma'am. What about using the gateway of the the network 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. I got you. That's possible. That might work. You still have to do some restrictions on the NAT, things like that but that's a possibility. I'll look at doing that. Oh guys I'm sorry this demo's just not going as planned. Yeah that's a possibility. That's something worth looking at. 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. This is going to be one of those days to demo God's hate me. One more time and then I'm just going to move on. Sorry guys. Unfortunately watching traffic go across the wire in a complicated setup is kind of not really much to look at anyway. Oh 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 reauthentication the switch goes yeah okay you're still good but thanks for telling me. Yeah I touch 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 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 to expect delays when doing simple tasks like that so they assume it's the internet not their local link and that's even if they notice that it took a few extra milliseconds. Best laid plans and get up and juggle but you know I probably wouldn't want to see that. Alright so I can talk through the rest of this and maybe I can get the stupid config to come up by the time we're done. 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. 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 and then you 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. What we really need is 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 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. So assuming we had the gateway MAC how would we bolt that into our configuration to make it work? Well 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. That does actually cause a bit of an issue when interacting with the local network segment because remember the local network segments 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 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. 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 I'm of the opinion that if we're on an assessment and somebody figures out that something weird is going on based on local MAC addresses on a local segment 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? Since 8 or 2 1x is a big hairy complicated beast it's probably safe to say that your average mom and pop 5 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. There's probably some sort of a firewall or a router in between routing packets network services such as Active Directory, DNS, web, etc. And all likelihood are not going to be in the workstation segment. So we can use that later on. So if we watch the past packets across the bridge what sorts of traffic would we expect to see? Obviously you know anything UDP, RF, TCP but what would be most useful for gathering the information we need? Once again we need the computer's MAC address, 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 as the local segment 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. LDAPs and other possibility if you're in an Active Directory environment 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. 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 tell this other guy and 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 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 ARPed for item on the local network because that's where assuming you're on a client VLAN that's where most of the 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. 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 OSs 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 SIN request and you're in an active directory environment you send a SIN request out for Kerberos or Web or whatever it's going to have the source destination the source MAC of the computer. You'll have 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. 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 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'll 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 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. To implement it with ARP you just capture a bunch of ARP traffic. Do some do a little gymnastics with a Unix command line to capture file. You read from the capture file. You grep for the questions. You grep out the information. You sort it. You count it. You sort it and reverse it. 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 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. 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. So wait for one packet, parse through it and away we go. So the grabbing that information is actually pretty straightforward. 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. 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. Computer interface, bridge interface, all the stuff is 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. 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, 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. 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? 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, 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. 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. 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. 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. 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, Hanky's 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. 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. 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 seem to be a lot of traffic destined for the local 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 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 if you're capable of seeing that something weird like that is going off 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. If the link saturated, it might go higher than that. But the average user isn't going to catch that. Same thing with throughput. I mean, 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 it about 70 megs. So that's actually pretty good. It's not horribly slow. Now some of the embedded devices out there, if it's running a really slow processor, you could probably run into some problems. But these plugs, for example, are 1200 megahertz, 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. Speed duplex mismatch. So if you're running gig and all of a sudden, you know, a port drops to 100 meg or something like that, well, that could be a sign, something weird's going on. But in all honesty, I think for any large environment, the chances of every single device 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 three on switch five, building three, floor two, switched from gig to 100. That would be a, 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 detect it that way. 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 easy to unplug, reboot a machine, even, you know, switch reboot, stuff like that. All that would cause a link to reset and even a flaky cable, you know. 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, I don't see what you consider to be excessive up-down notices on a particular link if that's what you want to try. 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 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. 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 you know, let them understand and be a part of your security. Incorporated into your annual security refreshers or your monthly refreshers as necessary, and encourage them to ask questions. The problem is, if you find one of these devices on your network, you 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. 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. So what sorts of fun things can we do with this? You can poison web traffic, obviously you're in a perfect position, the 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 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 obviously capture credentials, you can scan the network. 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. You could pivot through it. You know if you set up an open VPN call out, 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 already peed into that box, what the hell's 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 on the plug computer itself and have all your local callbacks 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 the, 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. 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 know you'll get back to them in a couple weeks after you've finished your assessment. It's a save on travel costs and it can be, it can be a huge savings rather than sending a team of two or three people out all over the world. You can just you know drop ship a plug to them and surf from the comfort of your home office or wherever you have the plug calling back to. 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. And yeah, you can hook up fiber ethernet. You can run another fiber connector transceiver on this. You can even hook two fiber connect transceivers up with a fiber cable. It still works. IP still works. Ethernet frames are the same. It's just a transport medium. That's it. Nothing special. So yeah, I mean if you have a, obviously if you have fiber on your network, you know, you run into some logistical problems with having the right cable connectors and using the right kind of fiber and stuff like that. 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, you know, 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. 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. And that is really not the case. 802.1x just authorizes the port to go alive and route traffic. Doesn't do any sort of per packet authorization. It doesn't do any sort of per packet anything really. 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's up to snuff or you log in or you remember a domain or whatever the criteria are, it'll 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. I can't do anything to your 802.1x network if I'm outside the building. It's just the way it is. Yeah, 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? 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. So you would notice some weird device plugged into your network waiting for you to plug your computer in in the morning. Ipsac could be used to mitigate some of the man in the middle issues. Microsoft's NAP solution basically establishes on top of 802.1x Ipsac tunnels point to point between all of the clients and servers. 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 of any of that at all. But you still have to connect to the internet and unless you route all your traffic through a proxy over an Ipsac tunnel, you're still gonna 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, 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? 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. 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. So anyway, anybody have any questions of the, you know, dozen or so people that are left? What's up man? You want to, yeah, you got nothing but time. Almost scared everyone off. 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 at middle could be leaking STP advertisements. 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 might be useful to put a line in it. Yeah, that's something that I'll look at doing. It gets slightly stealthier. Yeah, okay. I was talking to the Pony Express guys and the vendor booth every 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 and while it's not easy there is a way. It's pretty new. You listed it in there, 802.1AE, MaxSec. Yep. We'll prevent this. It's a nightmare to set up. Well and 802.1AE, I believe, I haven't done a lot of research on it, but there's only like two Cisco switches out there that support it. 2960S and the 3750X 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 you need to, on the switch side, you have to have switch support for it, but then you just need a supplicant that supports 802.1AE. 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 that it's encryption between the endpoint and the switch port. Okay. It's encryption between the endpoint, the supplicant if you will, right, 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. Right. There's still ways around it, but it's very very hard. You can't stick an unauthenticated device on the network, you know. Well that's probably where things are going to be moving is on a more per-packet authorized basis, but given the fact that, you know, how many successful deployments of 802.1AE 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. I'm just saying if you want an answer, though. Oh yeah, yeah, well that's probably the way to move forward with this, but in its, 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 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 one. Could you speak up a little bit? Yeah, perhaps there is a solution to this, but it's also very extreme. If we dropped 802.1 point x at all and everyone connected to the network over open VPN or something like this and do an entirely different layer to handle it this, because, but it's just as you said about a IPsec. 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 for Microsoft, that's one of their big points that they tout. Yeah, but it's the only solution. It's not a realistic solution that I think of. Exactly. Thank you. I had a quick quality to my previous question earlier. I brought up the TTL thing and basically what I was wondering was once you move from fully transparent later to you assign an IP to the bridge, you've moved in the layer 3 territory, correct? Well, what happens is the bridge, the traffic that is coming from the client will always traverse the bridge interface and 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. So that's interesting. I know, so I've done some similar things in FreeBSD and it's a little bit differently because if you do 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, 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 proxies net IPv4, 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 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 somebody's... Well, it's the same sort of thing, I mean if you're in an environment where you're actively hunting for rogue devices and we were able to implant a rogue device and you caught it, okay that's good for you. The next step for us would be to 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 rogue APs, 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 watching all the traffic flying across the wire. But it's a good point. Okay and then one last thing, 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 up to like maybe gather some metrics on what IPs look other like neighboring hosts on the network that that guy is allowed to talk to and then spoof those. Yeah I mean there's there's ways of spending you know some time to do, yeah like you said you you see 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 they talked to the least so you don't stomp on anything. 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. Yeah. And make it look like he did. Yeah. So that was kind of the approach I took because you know it's just if you're on a work station 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 then you know the guy behind you. Alright thank you. Yeah I mean it's it's worth looking at. Alright thanks. Uh-huh. What's that man? I have a question in regards of a typical configuration. Okay. When you have a IP phone connected to the switch and then the workstation is connected to the IP phone 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 it would further complications. Um in all honesty I don't know because I haven't tested 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. But as far as being able to interact with the traffic obviously if it's 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. Uh yeah in all honesty I haven't tried you know setting up CDP setting a bridge up and seeing if the other guy saw it off the top of my head I don't I can't think of any reason why it wouldn't support it but I haven't tested it specifically. 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 too so it ought to just you know ought to work. Anybody else? Anybody know any good jokes? Alright well uh thanks for surviving my my presentation I'm glad I survived. 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 the question Q&A room number 4 after I get all this crap torn down. Thanks.