ARP Poisoning and the Man in the Middle

How ARP poisoning works

The attacker exploits the lack of authentication to insert themselves between two parties, typically a victim and the network's gateway (the router to the rest of the world), because most interesting traffic flows through the gateway.

Conceptually, the attacker sends forged ARP replies:

• to the victim, claiming that the gateway's IP address is at the attacker's MAC address;
• to the gateway, claiming that the victim's IP address is at the attacker's MAC address.

Both the victim and the gateway update their ARP caches with these false mappings (their caches are now poisoned), and as a result:

• traffic the victim sends toward the gateway is delivered to the attacker instead;
• traffic the gateway sends toward the victim is delivered to the attacker instead.

The attacker now sits in the middle. To keep the connection working so the victim notices nothing, the attacker forwards each packet on to its real destination after reading it. This is the man-in-the-middle position: the attacker sees, and can alter, everything passing between the two parties, while both believe they are talking directly to each other.

Because it works at the local-network level and does not depend on the switch's forwarding table, ARP poisoning defeats the switch where the previous chapter's MAC flooding might not: the switch is delivering frames correctly to the attacker's port, because as far as it knows the attacker's MAC legitimately holds that traffic. That is why ARP poisoning is the more reliable and more important of the two.

What the attacker gains, and the crucial limit

The man-in-the-middle position is powerful, and its limit is the most important point in the block.

What it gains: the attacker sees all traffic between the two parties and can modify it in transit, not only read it, which is why a man-in-the-middle threatens integrity as well as confidentiality.

The crucial limit: ARP poisoning diverts traffic; it does not decrypt it. If the traffic is encrypted end to end, the attacker relays ciphertext they cannot read, and cannot usefully alter, because tampering with authenticated ciphertext is detected. So:

• Unencrypted traffic is fully exposed and alterable.
• Encrypted traffic (HTTPS, a VPN, SSH) is diverted but stays confidential and integrity-protected, and any attempt to impersonate the far end fails the certificate check, because the attacker cannot present a valid certificate for the real name.

This is the distinction the countermeasures chapter builds its argument on: being in the middle is not the same as being able to read the middle. An attacker who successfully poisons ARP against a victim using HTTPS everywhere obtains diverted ciphertext and a browser certificate warning on any impersonation attempt, which is very different from the plaintext they would get from an unencrypted connection.

The countermeasures

The defences divide into stopping the poisoning and neutralising its value.

Stopping or detecting the poisoning:

• Dynamic ARP Inspection, a managed-switch feature that checks ARP replies against a trusted database of legitimate IP-to-MAC bindings (built from the switch's knowledge of which addresses are validly assigned to which ports) and drops forged replies. This directly defeats the attack at the switch and is the primary technical control.
• Static ARP entries for critical hosts, such as the gateway, so that a forged reply for that address is ignored, because the mapping is fixed and not learned. Effective but administratively heavy, so reserved for a few important mappings.
• ARP monitoring tools that watch for the signs of poisoning: an IP address suddenly mapping to a new MAC address, or one MAC address claiming many IP addresses (the attacker's MAC appearing for both the victim and the gateway). These raise an alert on the poisoning itself.

Neutralising its value, and the durable control:

• Encryption in transit. Because the attacker diverts but cannot decrypt, end-to-end encryption with certificate checking makes a successful man-in-the-middle nearly worthless: they relay ciphertext, and impersonation fails the certificate check. This is why the countermeasures chapter concludes that the deepest defence against the whole block is to encrypt, and to ensure clients verify certificates and do not click through warnings.

The professional recommendation combines them: Dynamic ARP Inspection to stop the poisoning, monitoring to detect attempts, and encryption everywhere so that even a successful attack yields only ciphertext. Defence in depth, because any one control may be absent on some segment.

A worked example, run as a defender

An assessor evaluates a client's exposure to a local man-in-the-middle, on the client's own network with authorisation, reasoning from configuration rather than by intercepting colleagues' traffic.

• The access switches do not have Dynamic ARP Inspection enabled, so forged ARP replies would be accepted and a man-in-the-middle position could be established. Finding: the network does not prevent ARP poisoning at the switch.
• However, the organisation uses HTTPS and a VPN throughout, so an attacker in the middle would relay only encrypted traffic and any impersonation would fail the certificate check. The exposure is therefore diversion of ciphertext, not disclosure of contents.
• One internal application uses an unencrypted protocol. This is the serious finding, because for that application a man-in-the-middle would read and could alter the traffic.
• No ARP monitoring is in place, so an attempt would not be detected. Finding: no detection of poisoning.

Recommendations, in order: enable Dynamic ARP Inspection (stop the poisoning); move the unencrypted application to an encrypted protocol (remove the one exposure that matters); add ARP monitoring (detect attempts); and set static ARP entries for the gateway on critical hosts. The assessor notes the general lesson: encryption already limits the damage to almost nothing except where a protocol is unencrypted, which is exactly where to focus.

What beginners get wrong

• Thinking ARP poisoning is a flaw in an implementation. It exploits a design decision: ARP has no authentication and hosts believe any reply, including unsolicited ones.
• Believing being in the middle means being able to read the traffic. It means diverting the traffic; encrypted traffic is relayed as ciphertext and impersonation fails the certificate check.
• Assuming the switch protects against it. ARP poisoning operates at the ARP level, and the switch delivers frames to the attacker's port correctly; Dynamic ARP Inspection is the switch feature that does stop it.
• Overlooking integrity. A man-in-the-middle can alter unencrypted traffic, not only read it, so it threatens integrity as well as confidentiality.
• Relying on a single control. Dynamic ARP Inspection, monitoring and encryption are combined, because any one may be missing on some segment.
• Clicking through certificate warnings. The certificate check is what defeats impersonation by a man-in-the-middle; ignoring the warning discards that protection.

Quick revision

• ARP maps an IP address to a MAC address on the local network, by broadcast request and reply, cached in the ARP cache. Every local conversation begins with it.
• The enabling flaw: ARP has no authentication, so a host believes any reply, including unsolicited ones, and a later reply overwrites an earlier one.
• ARP poisoning: the attacker sends forged replies telling the victim the gateway is at the attacker's MAC, and the gateway the victim is at the attacker's MAC, so both send their traffic to the attacker, who forwards it: the man-in-the-middle position, which sees and can alter traffic.
• It defeats the switch, which delivers to the attacker's port correctly.
• Crucial limit: it diverts but does not decrypt. Encrypted traffic is relayed as ciphertext and impersonation fails the certificate check; unencrypted traffic is fully exposed and alterable.
• Countermeasures: Dynamic ARP Inspection (drops forged replies), static ARP entries for critical hosts, ARP monitoring, and, decisively, encryption in transit with certificate checking.

Test yourself

1. What is ARP for, and which of its design properties makes poisoning possible?

ARP maps a known IP address to the MAC address needed for local delivery, by broadcasting a request and caching the reply. Poisoning is possible because ARP has no authentication: a host believes any ARP reply it receives, including unsolicited ones, without verifying that the responder truly owns the claimed IP address, and a later reply overwrites an earlier one.

1. Describe how ARP poisoning establishes a man-in-the-middle position.

The attacker sends forged ARP replies telling the victim that the gateway's IP address is at the attacker's MAC address, and telling the gateway that the victim's IP address is at the attacker's MAC address. Both update their ARP caches with these false mappings, so each sends toward the attacker traffic intended for the other, and the attacker forwards each packet on after reading it, sitting invisibly between the two parties.

1. Why does ARP poisoning defeat a switch when MAC flooding might not?

Because it operates at the ARP level rather than by overwhelming the switch's forwarding table. The switch delivers frames correctly to the attacker's port, since the poisoned caches cause the victim and gateway to address their traffic to the attacker's MAC, which the switch legitimately maps to the attacker's port, so no switch failure is required.

1. What is the crucial limit of the man-in-the-middle position, and what follows for defence?

That it diverts traffic but does not decrypt it: encrypted traffic is relayed as ciphertext the attacker cannot read or usefully alter, and any attempt to impersonate the far end fails the certificate check, whereas unencrypted traffic is fully exposed and alterable. It follows that end-to-end encryption with certificate verification makes a successful poisoning nearly worthless, so the unencrypted protocols are where the real exposure lies.

1. Name the switch feature that directly stops ARP poisoning and explain how it works.

Dynamic ARP Inspection, a managed-switch feature that checks each ARP reply against a trusted database of legitimate IP-to-MAC bindings, derived from the switch's knowledge of which addresses are validly assigned to which ports, and drops any reply that does not match. Forged replies are therefore discarded before they can poison a host's cache.