Man-in-the-Middle via ARP Spoofing
The attacker poisons the ARP caches of both the client and the gateway, then relays all traffic.
sequenceDiagram
autonumber
participant C as Client
10.0.0.5 participant A as Attacker participant G as Gateway
10.0.0.1 participant I as Internet Note over C,I: Normal flow (before the attack) C->>G: ARP request — who has 10.0.0.1? G-->>C: ARP reply — 10.0.0.1 is at MAC AA:BB:CC C->>G: HTTP request G->>I: forwarded request Note over A,G: Attack begins — attacker sends gratuitous ARP replies A->>C: forged ARP — 10.0.0.1 is at MAC ATTACKER A->>G: forged ARP — 10.0.0.5 is at MAC ATTACKER Note over C,I: After ARP poisoning — attacker is on path C->>A: HTTP request (thinks A is the gateway) A->>G: relayed HTTP request (after reading or modifying) G-->>A: HTTP response A-->>C: relayed HTTP response
10.0.0.5 participant A as Attacker participant G as Gateway
10.0.0.1 participant I as Internet Note over C,I: Normal flow (before the attack) C->>G: ARP request — who has 10.0.0.1? G-->>C: ARP reply — 10.0.0.1 is at MAC AA:BB:CC C->>G: HTTP request G->>I: forwarded request Note over A,G: Attack begins — attacker sends gratuitous ARP replies A->>C: forged ARP — 10.0.0.1 is at MAC ATTACKER A->>G: forged ARP — 10.0.0.5 is at MAC ATTACKER Note over C,I: After ARP poisoning — attacker is on path C->>A: HTTP request (thinks A is the gateway) A->>G: relayed HTTP request (after reading or modifying) G-->>A: HTTP response A-->>C: relayed HTTP response
The defense: if the client uses HTTPS with proper certificate
validation, the attacker cannot impersonate the server. The relayed traffic is
opaque ciphertext, and any certificate the attacker presents fails validation —
so the client sees a warning instead of a silent compromise. ARP spoofing still
lets the attacker see that you are talking to a server, but not
what you say.