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.
Comments
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.
Extra work, but it is possible.
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.
I'm guessing he'll charge for those kinds of answers. :)
I'm not asking him to pentest my network, just some recommended practices :)
Locking down network ports to the mac-address makes this kind of attack in-feasible, but it's rarely done.
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.
Whilst possible, this is a) more unsubtle and b) still limited to a single device - but good point.