TCP/IP: ICMP, UDP - cs.bham.ac.uk - School of Computer...

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 1Network Security - Lecture 5

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

Type Code Checksum

Data


0 4 8 1612 31

• Type: ICMP type

• Code: ICMP subtype

• Checksum: Error checking code

- Computed on the ICMP header and data (with checksum field set to 0)

20 24 28

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


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


ICMP Echo request/reply

Type = 0 or 8 Code = 0 Checksum

Identifier Sequence number

Optional data


0 4 8 1612 3120 24 28

ICMP echo request


ICMP encapsulation


ping


$ ping 192.168.0.1PING 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 ms64 bytes from 192.168.0.1: icmp_seq=2 ttl=52 time=8.24 ms64 bytes from 192.168.0.1: icmp_seq=3 ttl=52 time=8.02 ms64 bytes from 192.168.0.1: icmp_seq=4 ttl=52 time=8.02 ms64 bytes from 192.168.0.1: icmp_seq=5 ttl=52 time=8.16 ms64 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 25082msrtt min/avg/max/mdev = 8.021/8.106/8.245/0.125 ms

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 PSTHost 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

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




Attacker: 6.6.6.6 Victim: 1.1.1.1

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

2.2.2.253


• Defenses

– Ignore ICMP echo requests destined to the

broadcast address

– Linux:

$ sysctlnet.ipv4.icmp_echo_ignore_broadcasts


ICMP redirect


Host: 172.16.48.100

Gateway:

172.16.48.1

Gateway:

172.16.48.2

Destination Gateway Flags0.0.0.0 172.16.48.1 UG1.1.1.255 172.16.48.2 UGHD

Destination Gateway1.1.1.255 172.16.48.2

(4)

(1) Datagram to 1.1.1.42

(2) Datagram to 1.1.1.42

(3) ICMP redirect message:

“use 172.16.48.2 as gateway

to communicate with 1.1.1/24”

ICMP redirect


Type = 5 Code = 0, 1, 2, or 3 Checksum

IP Address

IP header + First 8 bytes of original datagram

0 4 8 1612 31

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

20 24 28

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


ICMP redirect attack


Address Hwaddress Role172.16.48.1 00:50:56:00:00:01 Gateway172.16.48.2 00:50:56:00:00:02 Linux host172.16.48.100 00:50:56:00:00:64 Windows host

C:\windows\system32> route print -4IPv4 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 11172.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 266172.16.48.255 255.255.255.255 On-link 172.16.48.100 266

============================================================================

# tcpdump –n00: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

ICMP redirect attack – cont’d


C:\Windows\system32> route print -4IPv4 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 11128.111.48.6 255.255.255.255 172.16.48.2 172.16.48.100 10172.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 266172.16.48.255 255.255.255.255 On-link 172.16.48.100 266

============================================================================

C:\Windows\system32> ping 128.111.48.600:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request

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


ICMP unreachable attack


From 172.16.48.1

To: 172.16.48.100

Destination unreachable

Victim:

172.16.48.100

Attacker:

172.16.48.101

Gateway:

172.16.48.1

ICMP time exceeded

• Sent when

– TTL becomes 0 (code: 0)

– The reassembling of a fragment times out (code: 1)


Type = 11 Code = 0 or 1 Checksum

Unused

IP header + First 8 bytes of original datagram

0 4 8 1612 3120 24 28

traceroute

• Use ICMP time exceeded messages to determine the path used to deliver a datagram

• A series of IP datagrams are 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 debuggingEike Ritter Network Security - Lecture 5 22

traceroute – cont’d


$ traceroute www.google.co.uktraceroute to www.google.co.uk (173.194.37.104), 30 hops max, 40 byte pkts1 rita-rw (147.188.193.6) 1.115 ms 1.087 ms 1.082 ms2 bes (10.0.9.1) 0.322 ms 0.315 ms 0.299 ms3 hscn-gw (147.188.199.1) 0.633 ms 0.621 ms 0.609 ms4 cs-ac00b7e1-2.bham.ac.uk (147.188.121.129) 0.937 ms 0.933 ms 0.923 ms5 cs-lb00b1e5-8b2e5-8.bham.ac.uk (147.188.120.13) 0.893 ms 0.884 ms

0.875 ms6 fw-sr00.bham.ac.uk (147.188.121.234) 0.865 ms 1.044 ms 1.043 ms7 147.188.121.245 (147.188.121.245) 1.747 ms 1.788 ms 1.775 ms8 193.63.208.21 (193.63.208.21) 1.764 ms 0.980 ms 3.367 ms9 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 ms11 as0.lond-sbr3.ja.net (146.97.33.166) 9.121 ms 9.108 ms 9.453 ms12 po1.lond-ban3.ja.net (146.97.35.106) 9.443 ms 9.788 ms 9.775 ms13 google.lond-ban3.ja.net (193.62.157.30) 70.751 ms 71.101 ms 71.088 ms14 209.85.255.175 (209.85.255.175) 8.066 ms 8.271 ms 209.85.252.76 (209.85.252.76) 8.321 ms15 209.85.251.58 (209.85.251.58) 9.036 ms 9.385 ms 209.85.251.202 (209.85.251.202) 9.382 ms16 lhr14s02-in-f104.1e100.net (173.194.37.104) 8.994 ms 9.342 ms 9.336 ms

UDP

• Based on IP

• Provides a connectionless, unreliable, best-effort datagram 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


UDP message format

UDP source port UDP dest port

UDP message length Checksum

Data


0 4 8 1612 3120 24 28

UDP message


UDP encapsulation


Frame dataFrame dataFrame headerFrame header

IP headerIP header IP dataIP data

UDP headerUDP header UDP dataUDP data

UDP encapsulation


UDP spoofing

• Essentially, it is IP spoofing


Server:

192.168.0.3

Attacker:

192.168.0.2

Client:

192.168.0.1

UDP request

Spoofed

UDP reply

UDP reply

UDP hijacking

• Variation of UDP spoofing attack


Server:

192.168.0.3

Attacker:

192.168.0.2

Trusted client:

192.168.0.1

UDP reply to spoofed request

UDP spoofing

• Vulnerable protocols

– DNS

– RPC

• NFS

• NIS


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)


UDP portscan


$ sudo nmap -sU 172.16.48.130

Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 17:17 PSTInteresting ports on 172.16.48.130:Not shown: 997 closed portsPORT STATE SERVICE111/udp open|filtered rpcbind137/udp open|filtered netbios-ns2049/udp open|filtered nfsMAC Address: 00:0C:29:27:25:40 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 1075.62 seconds

UDP portscan


$ sudo tcpdump -n host 172.16.48.130 172.16.48.139.43866 > 172.16.48.130.1433: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1433 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.51554: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 51554 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.40915: UDP, length 0172.16.48.139.43867 > 172.16.48.130.40915: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 40915 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.36489: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 36489 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.1033: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1033 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.34862: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 34862 unreachable, length 36

NEXT ON


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


Next time

• TCP


TCP/IP: ICMP, UDP - cs.bham.ac.uk - School of Computer...

Documents

Transcript of TCP/IP: ICMP, UDP - cs.bham.ac.uk - School of Computer...