Spoofed MAC addresses and Power Line Networking - two new FUIT tactics I learned at BriForum

David Stafford has spent his entire life in the End User Computing space, so he knows exactly where we're coming from when we say FUIT.

One of the few sessions I was able to attend at BriForum Chicago last week was given by David Stafford, who spent some time regaling us with FUIT stories from his time as the head of desktop management at Cisco. David has spent his entire life in the End User Computing space (he currently works in the office of the CTO for VMware's EUC group), so he knows exactly where we're coming from when we say FUIT. In fact, he might now it better than we do!

When we think of FUIT, we're drawing from past experiences that we have done or had to deal with over the years. I used to run my Slingbox on port 443, for instance, and I know people that have all but abandoned their corporate email in favor of GMail (going so far as to forward all email there and set up an alias so they can use GMail entirely). But that is all stuff that normal users can do with a bit of Googling. David's situation was a bit different. At Cisco, they have their office workers, but the vast majority of people at Cisco are well above average when it comes to computer savvy. 

Two things that were brought up in the session that I wanted to share here as an FUIT article are definitely for the more technical users out there, but are still FUIT situations at the end of the day. And while I don't expect Betty the accountant to do any of this, it's not unfathomable to picture an IT person doing this (since, after all, that's what happened to David).

Scenario 1: Bypass Network Access Control by stealing excluded MAC addresses

This one probably wouldn't have occurred to me since I never really worked on the network side of the house. The situation breaks down like this:

Tegratchet, Inc. (remember our fake company?) deploys a MAC-based Network Address Control (NAC) solution so that users must be on authorized devices to access the network. Sometimes it does this with authentication, but most of the time it's much like your SSL VPN - checking for OS versions, patch levels, antivirus, etc… Imagine the inconvenience, say, if someone has a laptop at home that performs better than their work computer, and they want to bring that into the office (For work…or gaming. Probably for work, though). The device probably doesn't have the appropriate configuration to pass the NAC check, and because of that it won't be allowed on the network.[

The solution, as David mentioned, is to more or less steal the MAC address off of something that's excluded from NAC policies. Things like printers, for instance, can be exempted from NAC policies based on their MAC address. Rather than exclude specific MAC addresses, companies are more inclined to exclude all printers by using the common OUI (Organizationally Unique Identifier) that all network interfaces from the same company would have. For instance, an HP JetDirect MAC might begin with 08:00:09, and if you exclude just that prefix, you would exclude all JetDirect cards from NAC.

In that situation, anyone with the ability to print a test page can simply walk up to a printer (on another network, of course) and copy its MAC address. Then, they can set the MAC address on their network card in the office, or worse, use it on the WAN port of a $30 router to open up a whole network for other people to use without any NAC!

Scenario #2: Power Line Networking

This one is so fantastical I'd like to believe it's not true, but I'm sure that it is. Development networks are often isolated from production networks so much that there is a virtual "air-gap" between them so that nothing can accidentally make it into production. You would think that simply not having a way of connecting one network to another would be enough, especially if that development network were in another room or a datacenter.

Like most assumptions when it comes to FUIT, you would be wrong. :)

The situation David laid out was just like the above, and one day a tech noticed a box under a developers desk with a bunch of cables plugged into it. The box was, in turn plugged into a wall. Upon further investigation, the developer had actually used a power line networking (PLN) kit that you could buy at Best Buy or Office Depot to bridge the air gap. 

The process is alarmingly simple! Connect the development network to the PLN box via Cat5, then plug the PLN box into the wall. Back in the cubicle, connect the computer (or switch) to the Cat5 jack on the PLN box, then plug it into the wall, too. Push a button to connect the two devices, and voila! Air gap breached. Not to mention the fact that it could have just been plugged into the production network, or into another NIC in the developers workstation that has a bridged connection.


The essence of FUIT!

And so it is that users will find new ways to say "FUIT!" even as we start to acknowledge that it exists and start looking for it. There are others, and we'd love to hear about them. It's a topic I can't get enough of, and the more we know about the ways users can do this, the better. For the time being, though, good luck finding the spoofed printer MAC addresses and Power Line Networking devices in your organization! (and thanks to David for putting on a great session!)

Join the conversation

6 comments

Send me notifications when other members comment.

Please create a username to comment.

Thanks Gabe - I'm thrilled this session provided both insights and humor to so many people!


Before folks start commenting on how more sophisticated NAC systems or datacenter power conditioners can suppress these examples - I'll acknowledge them right here at the beginning.


NAC was the main reason I left IT. I was convinced those developing such solutions had never supported end users before. Try forcing a corporate configured firewall software agent in a BYOD era.


Lets take the PowerLine example one step further - How many of us are in shared buildings?  It doesn't need to be a high-end network engineer to want to extend the reach of their cubicle access.


...and yes - To all reading this,, please provide more FUIT examples!  - I've already got a few ready for BriForum 2013 !


Cancel

SSH over (valid) SSL is the best I've seen. Not just running ssh on 443, but actually wrapping SSH inside an HTTPS proxy. All it takes on the outside is a server running apache and proxytunnel, and it looks like valid (albeit higher bandwidth) web browsing.


That isn't something that easily gets caught by automated rules; looking for dynamic DNS providers can sniff out the home-based ones, but anyone with a VPC host will be a harder target.


Thanks again to Dave for a great session, and to everyone else at Briforum for making it a great experience.


Cancel

I've used PLN technology to bridge Hotel internet down to the Hotel pool.  Some PLN units are also wifi access points so data can be bridged down to a maintenance outlet on the outside of a corporate building and exposed by Wifi for laptop access from a nearby car in the parking lot.  Not implying I've ever done something that scandalous of course.


Cancel

Another way around MAC based Network Access Control is simply to use a type 2 hypervisor with NAT based networking.  Simply put, the MAC address of a compliant base image is all the network will see for a hosted VM if the 'NAT' mode networking option is selection.  Bridged mode networking exposes the MAC of the hosted VM but NAT mode simply passes all traffic through the already authenticated MAC of the base image.  


Cancel

In the past, when VPN solutions weren't as readily available and I wanted to access the corporate network from outside the firewall, I've established an SSH tunnel from inside the corporate network to some server on the outside and I setup port forwarding from the outside to the inside. This did wonders for me. If you do this with '-g' option in ssh (check the doc) the box on the outside can act as a gateway and anybody connecting to it on the forwarded ports can get into the corporate network. Not sure whether there's a way to protect against such approach since the traffic on the corporate network looks rather normal ...


Cancel

Interested to know if the employees involved in these FUIT exploits were formally reprimanded?


Whilst these stories are amusing and can teach us a lot about the ways which are used to contravene corporate security, it would be good to know if a corporate policy which enforces draconian penalties for any contravention which could result in corporate IP leakage, are actually useful?


Regardlless of the amusement factor of having broken through corporate security, the contractual threat of being dismissed would certainly deter me from trying to secretly procure access to networks or data in a way which could compromise my organisation.


In effect, FUIT is 'hacking from the inside' and should be dealth with pretty severely!!


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close