The new interface is far easier to use and much more intuitive. This means that most script kiddie's can figure it out. In addition it has two primary types of mitm attack; the old favourite, arp poisoning and a new port stealing attack. These two methods are used to sniff traffic on a switched network and optionally inject packets. In the old days of hubs this was easy to do as the hub broadcasted everyone's traffic to everyone else. Switches on the other hand give each plug-port their own dedicated channell and only broadcasts and traffic destined for interfaces on that port will be sent down the wire. This makes sniffing harder but not impossible.

Let me give you a brief run down of how these work:

ARP Poisoning

ARP is the address resolution protocol and acts as the bridge between IP and ethernet by mapping an IP address to a MAC address. When your computer (bob) needs to send a packet to another computer (alice), bob does the equivalent of standing up in a crowd and shouting at everyone asking where alice is. Anyone who knows where alice lives will tell bob and bob can then communicate with alice. Now most machines by default accept arp packets without asking for them first (except solaris afaik). So if a malicious attacker (mallet) tells bob that he is alice and tells alice that he is bob, alice and bob will send their traffic to him. Now all mallet needs to do is forward bob's packet onto alice after rewriting them to look like they came from alice and vice-versa. Voila a man in the middle attack.

Port Stealing

Your average switch needs to work out which machine is on which port so it can send traffic to it. This is usually done dynamically by checking the MAC address on the packets sent from a port and storing it in a CAM table. Thus when bob sends a packet to alice the switch will record bob's MAC address and know to send all traffic destined for bob's MAC to that specific switch port. Now if mallet wanted to insert himself in the middle all he would need to do is broadcast two packets with an originating MAC address the same as bob's and alice's. This would make the switch think that bob and alice are on the port mallet is actually on and mallet would be able to intercept traffic destined for them.
The next part is forwarding the modified packets back to bob and alice. Mallet cannot do this in the current state as the switch would just send the packets back to him still thinking he was bob and alice. Thus mallet sends out a broadcast arp request for alice and bob's MACs. When alice and bob respond the switch's CAM table will be back in the original state and mallet can forward the modified packets to alice and bob. This process then needs to be repeated for every packet.

I hope I explained those well enough. More information can be found in the ettercap documentation, the ettercap forums or from a google search.

Defence

Ok now the most important bit: How do you defend against this? This is something I haven't quite got figured out in my mind but I have some ideas. Please give me your input if you have others or I am wrong. I am looking for easy to use solutions that do not require a network to be re-engineered.

For arp poisoning the answer seems to be static arp tables. This basically means that the IP<->MAC mapping does not expire and can't be changed. Arp poisoning can only be used per-subnet. Now it is impractical to statically map all 254 MAC addresses on each of the 254 possible machines. However statically mapping the gateway on each machine is possible and seems a good idea, just don't do it over DHCP or the like. This does not prevent an attacker from inserting himself between two other machines however. Thus in addition configure the machines with solaris like behaviour to not accept arp packets unless they specifically ask for them and/or to only accept arp packets from trusted MAC's like the gateway. In addition run arpwatch on the subnet and maybe combine it with and IDS (e.g. snort with its arpwatch like capabilities). Given that most organisation (should be) register(ing) each machine on the network, they should have the MAC address to feed to the tool.

This bring us to the switch and port stealing. As mentioned above the sysadmin should know which MAC's are mapped to which IP's and which port they are plugged into, with this they can make a static CAM table on the switch (I just realised this excludes wireless networks and laptops). This is an additional burden to the sysadmin but it shouldn't be too difficult to automate with a decent systems database to start with.

CISCO has some ideas using Dynamic Arp Inspection, IP Source Guard and DHCP Snooping.

So why won't this work? Wireless netoworks provide their own headache, but how could you handle laptops with a static CAM table?

UPDATE:
After speaking to our resident network's guru, Guy Halse, it was pointed out that since these attacks are limited to one subnet and/or one switch a good network design can go a long way in mitigating most of these risks. This basically involved intelligent subnetting and routing to make sure that important traffic doesn't go near potentially dangerous subnets.