I’m an IP network engineer. When something goes wrong, the first thing I do is sniff packets. Got a SIP phone that won’t register? Forget reading logs; sniff 5060/udp and read the SIP chatter directly. A customer complains that “Yahoo chat doesn’t work”? Sniff 5050/tcp and look for TCP hangups, login failures, or ICMP “port unreachable” messages.
Sniffing is easy when you have access to the intermediate router, but that isn’t always the case. What if you’re just another PC on the same switch? That’s impossible, right?
- Use a monitor port. With a managed switch, configure one port to receive copies of data sent to other port(s). Useful if you have administrator access to a managed switch.
- MAC flooding. Fill up the switch’s MAC table with false entries, causing it to failover into broadcast mode. All packets will be sent to all ports. Easy to detect and hard to do on modern switches.
- ARP poisoning. Send unsolicited ARP responses to the target devices (for instance, a PC and its default gateway), telling them to direct traffic to you. Silently route their traffic so they don’t notice an interruption.
It is the last technique that I want to discuss. Many tools exist to poison ARP, from simple command line utilities like arpspoof (part of dsniff), seringe, and arp-sk, to full-featured man-in-the-middle attack suites like Ettercap. Ettercap can poison ARP caches, sniff packets and write them to files, route traffic, and filter/change traffic content. You can find a very helpful step-by-step Ettercap tutorial here, so I won’t cover the same ground. I’d rather explain what these tools do.
ARP poisoning attacks work by sending gratuitous ARP replies to two targets, informing each of them that the attacker’s PC is the opposite target. For instance, suppose I have three devices:
- gateway, a router on 192.168.0.1, with MAC 00:1d:73:36:ad:0c
- alice, a PC on 192.168.0.101, with MAC 00:13:02:02:56:da
- My PC on 192.168.0.102, with MAC 00:17:09:d2:30:25
Alice knows Gateway’s MAC address:
user@alice:~$ ip neigh show 192.168.0.1 dev wlan0 lladdr 00:1d:73:36:ad:0c REACHABLE
Gateway knows Alice’s MAC address:
user@gateway:~$ ip neigh show 192.168.0.101 dev eth1 lladdr 00:13:02:02:56:da REACHABLE
When I start the ARP poisoning attack, both Alice and Gateway learn different MAC addresses for each other:
user@alice:~$ ip neigh show 192.168.0.1 dev wlan0 lladdr 00:17:09:d2:30:25 REACHABLE user@gateway:~$ ip neigh show 192.168.0.101 dev eth1 lladdr 00:17:09:d2:30:25 REACHABLE
Now Alice will send traffic for Gateway (probably all Internet traffic) to my PC, and Gateway will do the same for traffic intended for Alice. If we stop here, we’ll be able to see what Alice is trying to do, but Alice will quickly realise something is wrong because traffic will stop without explanation.
This is the second part of ARP poisoning (and of any Man-in-the-Middle attack): silently routing traffic onward. You can use the kernel’s IP forwarding to do this:
echo 1 > /proc/sys/net/ipv4/ip_forward
But if you do, you’ll appear in Alice’s traceroute path:
1 192.168.0.102 2.580 ms 2.754 ms 3.312 ms 2 192.168.0.1 1.530 ms 2.321 ms 2.964 ms 3 192.168.1.254 60.537 ms 60.028 ms 59.573 ms 4 188.8.131.52 19.854 ms 16.007 ms 17.413 ms 5 ....
If you use “unified sniffing” with Ettercap, it will silently route traffic in software. Other tools, such as fragrouter (also part of dsniff), can do the same thing from the command line. Both of these tools forward traffic without decrementing the TTL, which makes them invisible to traceroute.
ARP poisoning is not silent. It can be detected by both hosts, because you are manipulating their ARP tables. These gratuitous ARP replies are easily visible with a sniffer:
0.636848 00:17:09:d2:30:25 -> 00:1d:73:36:ad:0c ARP 192.168.0.1 is at 00:17:09:d2:30:25 0.637622 00:17:09:d2:30:25 -> 00:13:02:02:56:da ARP 192.168.0.101 is at 00:17:09:d2:30:25 10.680712 00:17:09:d2:30:25 -> 00:1d:73:36:ad:0c ARP 192.168.0.1 is at 00:17:09:d2:30:25 10.684618 00:17:09:d2:30:25 -> 00:13:02:02:56:da ARP 192.168.0.101 is at 00:17:09:d2:30:25
Most tools send these ARP replies regularly, to keep ARP table entries from timing out. For instance, Ettercap sends them every 10 seconds. This is suspicious, as ARP requests are normally only seen when a host is first discovering another one. It is necessary to prevent true ARP requests from briefly changing the ARP table back to its correct state. Several tools exist to detect or prevent ARP poisoning, like ArpON, arpwatch, and DHCP snooping.
I’ve used traditional security terms like “victim” and “attacker” in this post, and of course ARP poisoning is a useful technique for unauthorised spying. However, it has legitimate uses. I’ve used it a number of times in situations where I had to sniff but couldn’t interrupt the physical cabling or didn’t have a managed switch. Whatever the problem, there is no faster way to understand a network problem than sniffing the raw data.