A current analysis of man in the middle (mitm) attacks

1. A current analysis of man in the middle (mitm) attacks Sachin Deodhar <sdeodhar@kpmg.com>

2. The scenario Server Attacker Client

3. MITM attack scenarios TOC Different attacks in different scenarios: LOCAL AREA NETWORK: - ARP poisoning - DNS spoofing - STP mangling - Port stealing FROM LOCAL TO REMOTE (through a gateway): - ARP poisoning - DNS spoofing - DHCP spoofing - ICMP redirection - IRDP spoofing - route mangling REMOTE: - DNS poisoning - traffic tunneling - route mangling

4. MITM attack techniquesThe local scenario

5. Local attacks (1)ARP poisoning • ARP is stateless (we all knows how it works and what the problems are) • Some operating systems do not update an entry if it is not already in the cache, others accept only the first received reply (e.g. Solaris) • The attacker can forge spoofed ICMP packets to force the host to make an ARP request. Immediately after the ICMP it sends the fake ARP reply

6. The scenario Gratuitous ARP (forged) Server Attacker Client Gratuitous ARP (forged)

7. Local attacks (1)ARP poisoning - Tools • ettercap(http://ettercap.sf.net) • Poisoning • Sniffing • Hijacking • Filtering • SSH v.1 sniffing (transparent attack) • dsniff(http://www.monkey.org/~dugsong/dsniff) • Poisoning • Sniffing • SSH v.1 sniffing (proxy attack)

8. Local attacks (1)ARP poisoning - countermeasures • YES - passive monitoring (arpwatch) • YES - active monitoring (ettercap) • YES - IDS (detect but not avoid) • YES - Static ARP entries (avoid it) • YES - Secure-ARP (public key authentication)

9. 10.1.1.1 10.1.1.50 serverX.localdomain.in Local attacks (2)DNS spoofing If the attacker is able to sniff the ID of the DNS request, he/she can reply before the real DNS server MITM HOST DNS

10. Local attacks (2)DNS spoofing - tools • ettercap(http://ettercap.sf.net) • Phantom plugin • dsniff(http://www.monkey.org/~dugsong/dsniff) • Dnsspoof • zodiac (http://www.packetfactory.com/Projects/zodiac)

11. Local attacks (2)DNS spoofing - countermeasures • YES - detect multiple replies (IDS) • YES - use lmhost or host file for static resolution of critical hosts • YES - DNSSEC

12. Local attacks (3)STP mangling • It is not a real MITM attack since the attacker is able to receive only “unmanaged” traffic • The attacker can forge BPDU with high priority pretending to be the new root of the spanning tree

13. Local attacks (3)STP mangling - tools • Ettercap(http://ettercap.sf.net) • With the Lamia plugin

14. Local attacks (3)STP mangling - countermeasures • YES - Disable STP on VLAN without loops • YES - Root Guard, BPDU Guard.

15. Local attacks (4)Port stealing • Attacker floods the switch with forged gratuitous ARP packets with the source MAC address being that of the target host and the destination MAC address being that of the attacker. • Since the destination MAC address of each flooding packet is the attackers MAC address, the switch will not forward these packets to other ports, meaning they will not be seen by other hosts on the network • A race condition: because the target host will send packets too. The switch will see packets with the same source MAC address on two different ports and will constantly change the binding of the MAC address to the port. Remember that the switch binds a MAC address to a single port. If the attacker is fast enough, packets intended for the target host will be sent to the attacker’s switch port and not the target host. • When a packet arrives, the attacker performs an ARP request asking for the target hosts’ IP address. Next, the attacker stops the flooding and waits for the ARP reply. When the attacker receives the reply, it means that the target hosts’ switch port has been restored to its original binding. • The attacker now sniffs the packet and forwards it to the target host and restarts the attack ad naseum …

16. Local attacks (5)Port stealing how to Layer 2 switch 1 2 3 Gratuitous ARP (forged) A Attacker B

17. Local attacks (4)Port stealing - tools • ettercap (http://ettercap.sf.net) • With the Confusion plugin

18. Local Attacks (4)Port stealing - countermeasures • YES - port security on the switch

19. Attack techniquesFrom local to remote

20. Local to remote attacks (1)DHCP spoofing • The DHCP requests are made in broadcast mode. • If the attacker replies before the real DHCP server it can manipulate: • IP address of the victim • GW address assigned to the victim • DNS address

21. Local to remote attacks (1)DHCP spoofing - countermeasures • YES - detection of multiple DHCP replies

22. AT ICMP redirect to AT Local to remote attacks (2)ICMP redirect The attacker can forge ICMP redirect packet in order to redirect traffic to himself T G1 LAN H

23. Local to remote attacks (2)ICMP redirect - tools • IRPAS icmp_redirect (Phenoelit)(http://www.phenoelit.de/irpas/) • icmp_redir (Yuri Volobuev)

24. Local to remote attacks (2)ICMP redirect - countermeasures • YES - Disable the ICMP REDIRECT • NO - Linux has the “secure redirect” options but it seems to be ineffective against this attack

25. Local to remote attacks (3)IRDP spoofing • The attacker can forge some advertisement packet pretending to be the router for the LAN. He/she can set the “preference level” and the “lifetime” at high values to be sure the hosts will choose it as the preferred router. • The attack can be improved by sending some spoofed ICMP Host Unreachable pretending to be the real router

26. Local to remote attacks (3)IRDP spoofing - tools • IRPAS by Phenoelit(http://www.phenoelit.de/irpas/)

27. Local to remote attacks (3)IRDP spoofing - countermeasures • YES - Disable IRDP on hosts if the operating system permit it.

28. Local to remote attacks (4)ROUTE mangling INTERNET GW AT H The attacker can forge packets for the gateway (GW) pretending to be a router with a good metric for a specified host on the internet

29. Tunnel GW AT AT2 H D Local to remote attacks (4)ROUTE mangling • Now the problem for the attacker is to send packets to the real destination. He/she cannot send it through GW since it is convinced that the best route is AT. INTERNET

30. Local to remote attacks (4)ROUTE mangling - tools • IRPAS (Phenoelit)(http://www.phenoelit.de/irpas/) • Nemesis (http://www.packetfactory.net/Projects/nemesis/)

31. Local to remote attacks (4)ROUTE mangling - countermeasures • YES - Disable dynamic routing protocols in this type of scenario • YES - Enable ACLs to block unexpected update • YES - Enable authentication on the protocols that support authentication

32. Attacks techniquesRemote scenarios

33. Remote attacks (1)DNS poisoning • Type 1 attack • The attacker sends a request to the victim DNS asking for one host • The attacker spoofs the reply which is expected to come from the real DNS • The spoofed reply must contain the correct ID (brute force or semi-blind guessing)

34. Remote attacks (1)DNS poisoning • Type 2 attack • The attacker can send a “dynamic update” to the victim DNS • If the DNS processes it, it is even worst because it will be authoritative for those entries

35. Remote attacks (1)DNS poisoning - tools • ADMIdPack • Zodiac (http://www.packetfactory.com/Projects/zodiac)

36. Remote attacks (1)DNS poisoning - countermeasures • YES - Use DNS with random transaction ID (Bind v9) • YES - DNSSec (Bind v9) allows the digital signature of the replies. • NO - restrict the dynamic update to a range of IPs (they can be spoofed)

37. Tunnel GRE Fake host Remote attacks (2)Traffic tunneling Server Router 1 INTERNET Client Gateway Attacker

38. Remote attacks (2)Traffic tunneling - tools • ettercap(http://ettercap.sf.net) • Zaratan plugin • tunnelX(http://www.phrack.com)

39. Remote attacks (2)Traffic tunneling - countermeasure • YES - Strong passwords and community on routers

40. Remote attacks (3)ROUTE mangling revisited • The attacker aims to hijack the traffic between the two victims A and B • The attack will collect sensitive information through: • Traceroute • port scanning • protoscanning • Quite impossible against link state protocols

41. Remote attacks (3)ROUTE mangling revisited • Scenario 1 a(IGRP inside the AS) A R1 B R2 The attacker pretends to be the GW

42. Remote attacks (3)ROUTE mangling revisited • Scenario 1 b (IGRP inside the AS) A R1 R3 B R2

43. AS 1 AS 2 AS 3 BG 1 BG 2 BG 3 Remote attacks (3)ROUTE mangling revisited • Scenario 2 a(the traffic does not pass thru the AS) BGP RIP

44. Remote attacks (3)ROUTE mangling revisited - tools • IRPAS di Phenoelit(http://www.phenoelit.de/irpas/) • Nemesis (http://www.packetfactory.net/Projects/nemesis/)

45. Remote attacks (3)ROUTE mangling revisited - countermeasure • YES - Use routing protocol authentication

46. Conclusions • The security of a connection relies on: • Proper configuration of the client (avoiding ICMP Redirect, ARP Poisoning etc.) • the other endpoint infrastructure (e.g.. DNS dynamic update), • the strength of a third party appliances on which we don’t have access (e.g.. Tunneling and Route Mangling). • The best way to ensure secure communication is the correct and conscious use of cryptographic systems • both client and server side • at the network layer (i.e.. IPSec) • at transport layer (i.e.. SSLv3) • at application layer (i.e.. PGP).

47. Once in the middle… • Injection attacks • Key Manipulation attacks • Downgrade attacks • Filtering attacks

48. Injection attacks • Add packets to an already established connection (only possible in full-duplex mitm) • The attacker can modify the sequence numbers and keep the connection synchronized while injecting packets. • If the mitm attack is a “proxy attack” it is even easier to inject (there are two distinct connections)

49. Injection attack examples Command injection • Useful in scenarios where a one time authentication is used (e.g. RSA token).In such scenarios sniffing the password is useless, but hijacking an already authenticated session is critical • Injection of commands to the server • Emulation of fake replies to the client

50. Key Manipulation in the case of popular VPN/crypto systems • SSH v1 • IPSEC • HTTPS