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!)
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.