TCP/IP: ICMP, UDP Network Security Lecture 5
Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP Sniffing the network and forging packets tcpdump, wireshark Today: ICMP and UDP Eike Ritter Network Security - Lecture 5 1
Internet Control Message Protocol Used to exchange control/error messages about the delivery of IP datagrams Encapsulated in IP datagrams Messages can be Requests Responses Error messages RFC 792 Eike Ritter Network Security - Lecture 5 2
ICMP message format 0 4 8 12 16 20 24 28 31 Type Code Checksum Data Type: ICMP type Code: ICMP subtype Checksum: Error checking code -Computed on the ICMP header and data (with checksum field set to 0) Eike Ritter Network Security - Lecture 5 3
ICMP types Echo request/reply (type: 8, 0) Network connectivity (ping) Destination unreachable (type: 3) Inform host of the impossibility to deliver traffic to a specific destination Destination network, host, protocol, port unreachable Destination network, host unknown Fragmentation required and DF flag set Source route failed Source quench (type: 4) Congestion control Eike Ritter Network Security - Lecture 5 4
ICMP types cont d Time exceeded (type: 11) Report expired datagrams(ttl = 0) Redirect (type: 5) Inform hosts of better routes (gateways) Address mask request/reply (type: 17, 18) Used to obtain network mask at boot time Eike Ritter Network Security - Lecture 5 5
ICMP Echo request/reply 0 4 8 12 16 20 24 28 31 Type = 0 or 8 Code = 0 Checksum Identifier Sequence number Optional data Eike Ritter Network Security - Lecture 5 6
ICMP echo request Eike Ritter Network Security - Lecture 5 7
ICMP encapsulation Eike Ritter Network Security - Lecture 5 8
ping $ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=52 time=8.16 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=52 time=8.24 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=52 time=8.02 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=52 time=8.02 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=52 time=8.16 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=52 time=8.02 ms --- 192.168.0.1 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 25082ms rtt min/avg/max/mdev = 8.021/8.106/8.245/0.125 ms Eike Ritter Network Security - Lecture 5 9
ICMP echo-based attacks: scanning Attacker wants to know which hosts in a subnet are up and running Sends a ping message to all possible hosts in that subnet (pingsweep) Collects replies from hosts that are alive $ nmap -sp 172.16.48.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 09:48 PST Host 172.16.48.1 is up (0.0024s latency). Host 172.16.48.2 is up (0.00077s latency). Host 172.16.48.130 is up (0.0065s latency). Host 172.16.48.139 is up (0.00014s latency). Nmap done: 256 IP addresses (4 hosts up) scanned in 2.54 seconds Eike Ritter Network Security - Lecture 5 10
ICMP echo-based attacks: smurf Broadcast ping message Echo request directed to broadcast address of network All hosts on that subnet respond with echo reply Do you see a problem with this scenario? Consider IP spoofing Eike Ritter Network Security - Lecture 5 11
ICMP echo-based attacks: smurf From: 1.1.1.1 To: 2.2.2.2.255 2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 Attacker: 6.6.6.6 Victim: 1.1.1.1 2.2.2.253 Eike Ritter Network Security - Lecture 5 12
ICMP echo-based attacks: smurf Defenses Ignore ICMP echo requests destined to the broadcast address Linux: $ sysctl net.ipv4.icmp_echo_ignore_broadcasts Eike Ritter Network Security - Lecture 5 13
Gateway: 172.16.48.1 ICMP redirect (2) Datagram to 1.1.1.42 Gateway: 172.16.48.2 Destination Gateway 1.1.1.255 172.16.48.2 (1) Datagram to 1.1.1.42 (3) ICMP redirect message: use 172.16.48.2 as gateway to communicate with 1.1.1/24 Host: 172.16.48.100 (4) Destination Gateway Flags 0.0.0.0 172.16.48.1 UG 1.1.1.255 172.16.48.2 UGHD Eike Ritter Network Security - Lecture 5 14
ICMP redirect 0 4 8 12 16 20 24 28 31 Type = 5 Code = 0, 1, 2, or 3 Checksum IP Address IP header + First 8 bytes of original datagram On receiving an ICMP redirect message, host checks that: The new gateway must be directly reachable (same subnet) The redirect must be from the current gateway for the destination The redirect cannot tell the host to act as the new gateway The route that is added must be indirect Eike Ritter Network Security - Lecture 5 15
ICMP redirect-based attacks ICMP redirect can be abused to re-route traffic to specific router or to a specific host Hijack traffic Denial-of-service attack How? The attacks works by sending a spoofed ICMP redirect message that appears to come from the host s default gateway Eike Ritter Network Security - Lecture 5 16
ICMP redirect attack Address Hwaddress Role 172.16.48.1 00:50:56:00:00:01 Gateway 172.16.48.2 00:50:56:00:00:02 Linux host 172.16.48.100 00:50:56:00:00:64 Windows host C:\windows\system32> route print -4 IPv4 Route Table ============================================================================ Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 172.16.48.1 172.16.48.100 11 172.16.48.0 255.255.255.0 On-link 172.16.48.100 266 172.16.48.100 255.255.255.255 On-link 172.16.48.100 266 172.16.48.255 255.255.255.255 On-link 172.16.48.100 266 ============================================================================ # tcpdump n 00:50:56:00:00:02 > 00:50:56:00:00:64, IP 172.16.48.1 > 172.16.48.100: ICMP redirect 128.111.48.6 to host 172.16.48.2, length 68 Eike Ritter Network Security - Lecture 5 17
ICMP redirect attack cont d C:\Windows\system32> route print -4 IPv4 Route Table ============================================================================ Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 172.16.48.1 172.16.48.100 11 128.111.48.6 255.255.255.255 172.16.48.2 172.16.48.100 10 172.16.48.0 255.255.255.0 On-link 172.16.48.100 266 172.16.48.100 255.255.255.255 On-link 172.16.48.100 266 172.16.48.255 255.255.255.255 On-link 172.16.48.100 266 ============================================================================ C:\Windows\system32> ping 128.111.48.6 00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request 00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request Eike Ritter Network Security - Lecture 5 18
ICMP destination unreachable Used by gateway to inform host that destination is unreachable Different subtypes Network unreachable Host unreachable Protocol unreachable Port unreachable Fragmentation needed and DF flag set Destination host unknown Destination network unknown Eike Ritter Network Security - Lecture 5 19
ICMP unreachable attack From 172.16.48.1 To: 172.16.48.100 Destination unreachable Gateway: 172.16.48.1 Attacker: 172.16.48.101 Victim: 172.16.48.100 Eike Ritter Network Security - Lecture 5 20
ICMP time exceeded 0 4 8 12 16 20 24 28 31 Type = 11 Code = 0 or 1 Checksum Unused IP header + First 8 bytes of original datagram Sent when TTL becomes 0 (code: 0) The reassembling of a fragment times out (code: 1) Eike Ritter Network Security - Lecture 5 21
traceroute Use ICMP time exceeded messages to determine the path used to deliver a datagram A series of IP datagramsare sent to the destination Each datagram has an increasing TTL field value (start value: 1) Router decrements TTL; if it is 0, sends back a ICMP unreachable message Useful for network analysis and debugging Eike Ritter Network Security - Lecture 5 22
traceroute cont d $ traceroute www.google.co.uk traceroute to www.google.co.uk (173.194.37.104), 30 hops max, 40 byte pkts 1 rita-rw (147.188.193.6) 1.115 ms 1.087 ms 1.082 ms 2 bes (10.0.9.1) 0.322 ms 0.315 ms 0.299 ms 3 hscn-gw (147.188.199.1) 0.633 ms 0.621 ms 0.609 ms 4 cs-ac00b7e1-2.bham.ac.uk (147.188.121.129) 0.937 ms 0.933 ms 0.923 ms 5 cs-lb00b1e5-8b2e5-8.bham.ac.uk (147.188.120.13) 0.893 ms 0.884 ms 0.875 ms 6 fw-sr00.bham.ac.uk (147.188.121.234) 0.865 ms 1.044 ms 1.043 ms 7 147.188.121.245 (147.188.121.245) 1.747 ms 1.788 ms 1.775 ms 8 193.63.208.21 (193.63.208.21) 1.764 ms 0.980 ms 3.367 ms 9 so-1-0-0.warr-sbr1.ja.net (146.97.42.189) 3.314 ms 3.660 ms 3.649 ms 10 so-5-1-0.read-sbr1.ja.net (146.97.33.89) 7.324 ms 7.311 ms 7.655 ms 11 as0.lond-sbr3.ja.net (146.97.33.166) 9.121 ms 9.108 ms 9.453 ms 12 po1.lond-ban3.ja.net (146.97.35.106) 9.443 ms 9.788 ms 9.775 ms 13 google.lond-ban3.ja.net (193.62.157.30) 70.751 ms 71.101 ms 71.088 ms 14 209.85.255.175 (209.85.255.175) 8.066 ms 8.271 ms 209.85.252.76 (209.85.252.76) 8.321 ms 15 209.85.251.58 (209.85.251.58) 9.036 ms 9.385 ms 209.85.251.202 (209.85.251.202) 9.382 ms 16 lhr14s02-in-f104.1e100.net (173.194.37.104) 8.994 ms 9.342 ms 9.336 ms Eike Ritter Network Security - Lecture 5 23
UDP Based on IP Provides a connectionless, unreliable, best-effortdatagram delivery service delivery, integrity, non-duplication, ordering, and bandwidth are not guaranteed Introduces the abstraction of ports Allows one to address different message destinations for the same IP address Commonly used for Multimedia Services based on request/reply schema (e.g., DNS, NFS, RPC) RFC 768 Eike Ritter Network Security - Lecture 5 24
UDP message format 0 4 8 12 16 20 24 28 31 UDP source port UDP message length UDP dest port Checksum Data Eike Ritter Network Security - Lecture 5 25
UDP message Eike Ritter Network Security - Lecture 5 26
UDP encapsulation UDP header UDP data IP header IP data Frame header Frame data Eike Ritter Network Security - Lecture 5 27
UDP encapsulation Eike Ritter Network Security - Lecture 5 28
UDP spoofing Essentially, it is IP spoofing UDP request Spoofed UDP reply UDP reply Client: 192.168.0.1 Attacker: 192.168.0.2 Server: 192.168.0.3 Eike Ritter Network Security - Lecture 5 29
UDP hijacking Variation of UDP spoofing attack UDP reply to spoofed request Trusted client: 192.168.0.1 Attacker: 192.168.0.2 Server: 192.168.0.3 Eike Ritter Network Security - Lecture 5 30
UDP spoofing Vulnerable protocols DNS RPC NFS NIS Eike Ritter Network Security - Lecture 5 31
UDP portscan Used to determine which UDP services are available A zero-length UDP packet is sent to each port If an ICMP error message port unreachable is received the service is assumed to be unavailable Note that the sending rate of ICMP messages can be limited (depending on the OS): the scan can be slow Linux: $ sysctl net.ipv4.icmp_ratelimit (number of jiffies to wait before sending another message) Eike Ritter Network Security - Lecture 5 32
UDP portscan $ sudo nmap -su 172.16.48.130 Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 17:17 PST Interesting ports on 172.16.48.130: Not shown: 997 closed ports PORT STATE SERVICE 111/udp open filtered rpcbind 137/udp open filtered netbios-ns 2049/udp open filtered nfs MAC Address: 00:0C:29:27:25:40 (VMware) Nmap done: 1 IP address (1 host up) scanned in 1075.62 seconds Eike Ritter Network Security - Lecture 5 33
UDP portscan $ sudo tcpdump -n host 172.16.48.130 172.16.48.139.43866 > 172.16.48.130.1433: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1433 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.51554: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 51554 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.40915: UDP, length 0 172.16.48.139.43867 > 172.16.48.130.40915: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 40915 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.36489: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 36489 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.1033: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1033 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.34862: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 34862 unreachable, length 36 Eike Ritter Network Security - Lecture 5 34
NEXT ON Eike Ritter Network Security - Lecture 5 35
Take away points ICMP has good functionalities to debug and control network. Some of them can be abused by attackers ICMP scanning (pingsweep) ICMP smurf attack ICMP redirection UDP Format Portscan nmap Eike Ritter Network Security - Lecture 5 36
Next time TCP Eike Ritter Network Security - Lecture 5 37