So the very idea that someone's unemployed neighbor, three apartments down on the floor below, might use an old wireless laptop they bought off eBay for $346, along with some freely downloadable software they got from the Internet, to take over your own wireless Ethernet-based network and capture your credit card information as you transfer funds into your online bank account  . . . was not something old Bob Metcalfe, the principal designer of Ethernet, ever considered or, frankly, could have possibly imagined.

No authentication
The problem is that Ethernet, upon which virtually all modern LANs are based, was designed without ANY sort of authentication technology whatsoever. So it is horrifyingly trivial for ANY computer with access to an Ethernet LAN, to re-route any other computer's traffic through itself simply by impersonating one or more other computers on the LAN. In fact, any computer can re-route ALL of the LAN's traffic through itself, allowing it to not only monitor but also to edit and alter anything sent to or received from any other machine on the local network.

Exactly how is this done?
The Internet is a so-called "Wide Area Network" or WAN because its Internet Protocol (IP) uses a hierarchal addressing system (IP addresses) that was designed to allow its data packets to be efficiently "routed" among billions of machines.

Ethernet, by comparison, is a "Local Area Network", or LAN technology because it utilizes a "flat addressing model" where every Network Interface Controller (NIC) on the local network is guaranteed to have a unique Media Access Control (MAC) address and traffic is either sent directly to the destination NIC, or broadcast and received by all NICs.

This means that we have two different addressing schemes for computers on the LAN, the global IP address and the local MAC address. In order for Ethernet to carry the Internet's IP traffic, some means was needed to associate the Internet's IP addresses with the Ethernet's NIC adapter MAC addresses. The Address Resolution Protocol "ARP" was created to fill this need.

When IP traffic enters the LAN's gateway, presumably bound for one of the machines within the LAN, the IP packet must be "wrapped" inside an Ethernet packet for its travel across the Ethernet LAN. If the gateway computer has already learned the specific Ethernet MAC address of the machine having the destination IP address, it simply addresses the Ethernet packet with that destination MAC address and puts the packet out onto the LAN where it will be "heard by" and received by the proper computer.

But if the gateway computer's knowledge of the destination computer's MAC address is either missing or too old and expired, it must send a broadcast to all of the computers on the LAN network asking which specific computer is assigned to the IP address of the packet the gateway is trying to forward. To do this the gateway broadcasts an ARP Request that will be received by every computer on the Ethernet LAN. The request simply asks for a reply from the one machine that is currently assigned to the IP contained in the request. Each computer on the LAN checks to see whether the IP is (one of) its own. The computer finding a match with (one of) its own IPs will send an ARP Reply back to the requesting device.

When the gateway computer receives the ARP Reply, it has the MAC address of the replying computer along with the replying computer's IP address, contained in the reply packet. The receiving machine enters this information into a "cache" of all similar IP-address-to-MAC-address pairings which is maintained for every machine it has communicated with on the LAN. This is known as the machine's "ARP Cache" since it retains the history of all previous unexpired ARP Replies which it has received.

Every computer participating on the LAN maintains its own similar ARP cache containing the IP-to-MAC relationships that allow them to properly address IP packets with Ethernet MAC addresses.

Notice that in this example, our gateway computer added this new entry into its ARP cache upon the receipt of an ARP Reply packet. The ARP protocol is so simple — just asking who has the IP and replying "I have the IP" — that there is no provision for any sort of security or authentication of the replying computer. In other words, any computer on the LAN could claim to have the IP in question.

The implementation of the ARP protocol is so simple and straightforward that the receipt of an ARP reply at any time, even when there are no ARP requests outstanding, causes the receiving computer to add the newly received information to its ARP cache.

Consequently, if the gateway computer were to receive a SPOOFED ARP REPLY from an attacking computer claiming that it was assigned an IP that belonged to some other computer, the gateway would trustingly and blindly REPLACE its current correct entry with the maliciously misleading replacement!

If at the same time the malicious attacking computer were to send a similar ARP reply to the computer being hijacked, maliciously replacing the ARP cache entry for the gateway computer, then any subsequent traffic bound for the gateway would instead be sent to the attacking computer. If the attacker forwards any of the redirected traffic it receives onto the proper original computer — after inspecting and perhaps even modifying the data — neither of the intercepted computers will detect that all of their communications is now being relayed through an unknown and probably malicious intermediary computer.

Internet "switches" offer no help
As you can see from the diagram above, the use of a standard Internet switch (as compared with a hub), which prevents passive monitoring and sniffing of the LAN's traffic by isolating the traffic of each computer from all others, is of no help in the face of active ARP cache poisoning since the LAN's traffic is being actively sent to the attacking computer.

The harsh reality of today's Ethernet LAN technology carrying IP traffic is that:

In situations where only trusted users are connecting to a LAN, the threat to the integrity and privacy of any computer's data is negligible. But the prevalence and popularity of the Internet has spread the use of Ethernet LAN technology into many environments where unknown and inherently untrusted computers and users may be sharing a common local area network.

For example, WiFi wireless networking technology uses Ethernet LAN technology for carrying its Internet IP traffic. Since the reception range of WiFi is generally out of the user's control, using WiFi is exactly like running a wire out of your network hub or switch out into the front yard with a big sign inviting any interested hackers to come by and plug in. You should now be able to clearly see just how dangerous this can be.

Only if your WiFi network is strongly secured with WPA encryption can you be assured that no one can gain access to your traffic. Since WiFi's Ethernet packets are themselves encrypted by the network's encryption, ARP cache poisoning cannot be accomplished without knowing the encryption key.

Another high-risk LAN environment for travelling road warriors is the increasingly common high-speed access offered by hotels. A hotel will typically have a single very large and very active Ethernet LAN. Such LANs will offer incredibly rich opportunities for ARP cache poisoning attackers.

Only if your computer's network traffic is securely encrypted through the use of some sort of virtual private network or other encrypted tunneling technology would your use of public LANs be immune from exploitation of ARP cache poisoning.

Is the threat from ARP poisoning just theoretical, or can it be easily accomplished?

The intrinsic weakness of Ethernet LAN security is well known within the hacker community and many easy-to-use "point and click" tools have been developed and are in constant use by malicious hackers. Since many of these tools have recently migrated from the less common Linux and Unix platform to the ubiquitous Windows environment, their use is rapidly becoming more widespread.

Here's text from the introductory description of a well known Windows tool set known as Cain & Abel v2.8.1:

Or this bit from the list of features added to Cain & Abel v2.8:

As a work of reverse engineering and technology hacking, I tip my hat to Cain's author, who is clearly a talented software engineer in his own right. Just LOOK at the complete (and horrifying) Cain & Abel feature list and the online manual (javascript required). Unfortunately, impressive as this work is, the ready availability of these tools to malicious hackers who would never be able to create them for themselves opens up the exploitation of these inherent Ethernet LAN technology weaknesses to a much larger audience.

But Cain & Abel is hardly alone in the field of ARP cache poisoning exploitation:

 Arpoison — is a simple and straightforward command-line utility which generates and sends spoofed ARP replies. The user simply specifies the source and destination IP and MAC addresses and the target's ARP cache will be poisoned with whatever information the user desires.

 dsniff — is an advanced password sniffing tool set which includes "arpspoof" and "dnsspoof" to allow man-in-the-middle (MITM) attacks against redirected SSH and HTTPS (secure web) sessions.

 ettercap — Quoting Ettercap's home page: "Ettercap is a suite for man in the middle attacks on LAN. It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis." Check out the Ettercap screen shots showing, among other things, it capturing eMail passwords passing over a LAN.

 Parasite — Parasite supports traffic sniffing on switched networks by performing ARP man-in-the-middle spoofing. It supports target selection, denial of service (DOS) and a host of other features.

 WinArpSpoofer — From the program's description: "WinArpSpoofer is a program to manipulate the ARP table of another computer on a LAN. Especially, by changing the ARP table of a router, this program can in effect pull all packets on the local area network. After pulling and collecting all packets, this has a function that can forward them to the router (gateway). If you run this program and any sniffer program, you can even get and see all user IDs/passwords on the switch network."

So . . . you get the idea. The complete lack of Ethernet endpoint authentication, and the ease with which it can be exploited, continues to spawn an already large and growing number of easily written tools for compromising the security and privacy of local area networks.

Once upon a time, when every machine on one's own local area network was known and trustworthy this wasn't a huge problem. But here again the demand for features and convenience has out paced any serious consideration of security and privacy.

Is there no hope for securing Ethernet LAN networks?

The complete lack of Ethernet LAN endpoint authentication is an obvious, critical, and glaring problem which has not been missed by the people who design and implement new networking standards. The "802.1X" and "802.11X" standards which provide for "Port Based Network Access Control" are emerging but not yet widely supported. Windows XP implements 802.1X for wired LAN environments, but since nothing that Windows is plugged into generally does, this solution is not yet readily available. And huge public LAN environments such as hotels will probably never be able to manage any sort of ad hoc secure authentication.

Now and for the foreseeable future, the security and privacy of roaming users will remain their own individual responsibility.

How can you arrange to securely encrypt all of your Internet communications when using public LANs?

Answering this question has been the subject of several installments of "Security Now!", the weekly security awareness audio podcast program created by Steve Gibson and Leo Laporte.