For whatever it's worth, this idea is at least 15 years old; it was a L0pht project that Mudge demo'd at Pumpcon in '97. If I'm remembering it right, it was a Palm device with Ethernet rigged to it and a modem.
I'd wager that many if not most corporate internal networks are vulnerable to ARP poisoning. A little computer hooked up to the network via ethernet is all one would need to launch such an attack, and https is vulnerable since many users have been conditioned to click through any kind of invalid certificate warning. Consider downloading Cain&Abel and experimenting on your own home network just to see how powerful these tools are. Fortunately, methods of detecting ARP poisoning exist, but undoubtedly many IT departments invest heavily in firewalls without worrying about attacks originating from inside.
I don't know why anyone would bother with ARP poisoning. Internal pentests are invariably bloodbaths; you spend 3 hours getting shells on 2-3 systems, and then another hour getting shells on 200-300 more as a result of all the stuff you find on those 3. On internal networks, the admin password is always "admin", the database password "oracle".
For those of us who go to the trouble of attempting to lock down our internal networks by changing the default passwords; setting up guest wireless networks; and running SSH and Kerberized NFS/AFP; what do you recommend as a reasonable set of measures to defend against internal attacks? What does Matasano do? I'm particularly interested in strategies for layer 2.
Most "enterprise" level switches (eg, Cisco) actually have a reasonable number of features which can be enabled to protect against things like ARP Poisoning. It doesn't need to be as inflexible as a one-to-one static mapping, they can be configured to determine whether ARP requests are valid and respond accordingly.
NAC, sticky mac, max mac/port, trusted DHCP, root guard, bpdu guard, multicast and broadcast storm control, they're all features that can help. Most people don't enable all of them because of management overhead, but each solves a problem that can happen in basically any network. It just a matter of weighing security risk vs the cost of managing the features.
It's also really frustrating at a hardware company to have to submit a ticket to IT and wait several days to add a new device to the network or create a private, non-MAC-secured VLAN for testing prototypes.
The little white box could incorporate an Ethernet switch. Then just reconnect an existing device on the network through it, and sniff traffic to find out the MAC.
Perhaps we need to move to policy of allowing only known mac addrs on internal networks. But maybe even this would be insufficient since one could sniff packets in order to steal someone else's valid mac address. That too would be insufficient since you can get the mac address off of the menu for most VOIP phones, and off the backsides of of other networked items, ...
Perhaps there is no defense against this kind of attack.
You're right, MAC-based defenses don't work for this type of attack; even if you came up with some scheme where a switch port won't get turned on until you announce yourself from a trusted MAC, you can always MITM a phone/computer on the network and get it that way.
The real solution here is proper network segregation and requiring encrypted traffic across the board, with sane key distribution schemes. But that's difficult and expensive.
For every local LAN attack there are mitigation techniques.
Cisco Switches have great features like DHCP Snooping and Dynamic ARP Inspection (DAI) to eliminate rogue DHCP servers and ARP spoofing.
Further yet, with "switch-port security" you can lock down mac addresses per port. With port security and proper device segregation if you spoofed a phones mac address and plugged in to that port the switch would still put you in to only the voice vlan not the data lan. It's not perfect but there are a lot of things you can do to secure a local LAN.
Unfortunately, most businesses must not even do the bare minimum if all they have to do is plug in a single PwnPlug without any attack vectors implemented like mac spoofing.
Yep. My University implemented switch-port security before I arrived in 2001. Managed switches, central MAC register, you were placed on the VLAN your MAC said you belonged to.
If your MAC appeared twice, you'd be locked out of the network and need to go and do some explaining (!). If your MAC moved around too much, ditto. If you had more than one ARP entry for your port, ditto.
While this makes some sense, what happens if you plug your laptop into your roommates port?
My university had a policy of disallowing students on the internal network - there was wifi and some special network ports with red cables for students. A classmate had a virus and was tracked down and yelled at in class because he was also plugged into the internal network...
The FE College I teach at (not residential) has a 'guest' wifi for any device you want. Just internet access, no https let alone any other protocol. The teenagers mainly use it with their Blackberry phones to get on BBM :-)
Full authentication is only for College owned devices, not sure how they are managing that.
Really you need 802.1x to do per port authentication. Though really you should still use encryption for all protocols and have strong passwords internally too.
Another, similar project is the Minipwner (http://www.minipwner.com/). It's effectively a TLINK router, flashed with OpenWRT and connected to a cellphone batttery pack, with a very small USB drive for storage and swap. It's also much cheaper - it cost me about $50, including shipping. Highly recommended if you want to play with this sort of thing.
It seems more and more like the concept of an 'internal network' needs to die. Open everything up to the Internet at large, and harden it all accordingly. It makes sense from a user experience perspective (why shouldn't I be able to access my work from home or on the road), and with the increasing number of easily concealable connected devices it makes sense from a security perspective too.
That is an extremely naïve perspective. Imagine you run IT for 10,000 PCs across the US. For one, maybe 10% of these would need to be upgraded to get to an OS with modern security. Then there's the servers for internal applications which can't be upgraded without breaking things. And then you'll need to deal with all the support, explaining to employees why, yes, although they have tasks which need to run overnight, no, they can't disable automatic update, because it would put the corporation at risk. Not to mention the amount of work it takes to keep computers up to date even when the user isn't a problem.
And even with all of that, one day one of the computers gets a backdoor installed, and the attacker is able to copy everything off your network drive, because you didn't have any sort of IDS or firewall to prevent it.
Smarter people than you have thought about this. There's a reason the idea of an internal network exists at all; NAT certainly wasn't something people were considering right from the start.
There are 7 billion people alive today. It's silly to assume otherwise.
What's more is that it prevents learning. I was talking with friend of mine the other day about an idea to set up a sqlite database with a html/css/javascript front end in order to organize all the word documents and spreadsheets that currently are haphazardly tossed onto a shared drive at work.
He pointed out that that's basically a content management system, and I realized that up until that point I assumed I was the first person to ever think about this problem. Now I have a bunch of people's code to read and learn from.
It may be true but it's also rude, just like calling a fat person "fat" is probably truthful but rude and not very helpful to say in most conversations. tylermenezes used the phrase as an appeal to authority in order to demean the notatoad's argument. I don't think your example compares to that case (shutting down trains of thought vs. re-inventing wheels).
I disagree that it is naive. At the recently finished RSA conference it was a common theme in many of the discussions. Basically operations is going to 'lose the war' of trying to control every device that is inside your network because there are phones, and tablets, and personal computers etc. which all want to be 'connected' at some level. So creating an infrastructure that is tolerant of that may ultimately become the norm.
Apparently in some sensitive facilities there are networks keyed off by MAC address, and then 802.1x key, so you need to have both the right MAC and the right key for that MAC to get an address and to send and receive packets. Connecting to the network switch with a 'non-authorized' MAC puts you on a different VPN than the if you connect with an authorized machine.
One of the attendees at the show told me they assumed that their network was 'unsafe' all the time and planned accordingly.
Now its probably naive to think we would go there in a year or two but it does seem to be a road we're being inexorably forced down.
How does an intranet/VPN help with avoiding malware on end user computers? I don't see the connection, isn't that entirely orthogonal? The OP wasn't arguing that you shouldn't control end user's devices, just that having an intranet of some sorts is not helpful.
If you run a large network, you'll have to deal with malware on users devices, and you'll have to deal with people gaining access to your network in other ways, such as this white box.
Having an "internal" network that isn't actually internal only gives you a false sense of security. Having access to an internal network should never give anyone higher access levels, but the whole idea of a "corporate intranet" pushes you in that direction.
There are two new paradigms gaining momentum in enterprise environments:
- Assumption of breach
- Bring your own device
Assumption of breach is driven by the industry's over-emphasis on protection, versus detection and response. The harsh reality is an attacker will always be successful gaining access. The detection and response capabilities are historically anemic due to repeated under-investment. That's why you see so many intrusions reported and the attackers have been in place for months or years.
One of the natural results of assuming breach is to shift focus from protecting _devices_ to protecting _data_. An attacker can always land on the secretary's machine, but you can put additional layers of protection around the organization's critical data.
Bring your own device (BYOD) is a natural extension of assuming breach and shifting focus from data to devices, and aligns nicely with the user desires to use their iPads and smartphones. The result in these environments is the IT shop becomes more ISP and less Dell technical support.
Many industries are adopting the assumption of breach and inevitability of compromise. RSA Exec Chairman at the RSA Conf a couple weeks ago: "We need to acknowledge once and for all that our networks will be penetrated." BYOD is harder - popular for universities and hospitals with significant user mobility, less so for governments and financials with higher protection thresholds and more static environments.
In another five years, these ideas will be common practice for many industries. If you HN'ers have some crafty plans in the enterprise space, take note.
It seems more and more like the concept of 'local law enforcement' needs to die. Open everything up to everyone at large, and harden all men, women and children to the realities of violence.
We should disbanded corporate, local, state, federal and country law enforcement. there should be no countries, borders or walls anywhere and you should also leave your house/apartment/car door unlocked because we have all been hard ended by carrying loaded assult weapons and heavy armor 100% of the time, including your 5yo school kid.
“Right now they’re actually flying people out to the stores to spot check and do penetration basis, but now with something like this you don’t have to travel.”
They send them out in jiffy bags to the regional branches, manager plugs one in, they can stay at head office and check the (branch) network. Saves money, provides hard data.
1) Send a small devise that's actually a box of rocks to bank that plugs into wall
2) Call bank, ask if they installed the box.
3) Save tons of money hiring people with overpriced gadgets.
4) Profit
I'd really like to see a wireless version of this. Plug it in, let it take as long as it likes to crack a weak WEP key, then send you an email. On the down side, you might not be able to access as much via a wireless network. On the up side, the "air freshener" disguise is much more believable without the network cable. You could have a wifi+cel version, but a dual-wifi version would probably broaden the range of hardware/software you could use and would also be a bit more useful.
FWIW, I hardly ever see WEP any more on wireless tests. WPA-PSK is still reasonably common even in corporates (mainly for guest networks), but realistically most companies I see are running 802.1X and PEAP against either Active Directory or a Cisco RADIUS Server.
