Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP - - PDF document

▶
recap and overview
SMART_READER_LITE
LIVE PREVIEW

Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP - - PDF document

Sep 22, 2022 209 likes •281 views

1/24/2012 Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP TCP/IP: ICMP, UDP Sniffing the network and forging packets tcpdump, wireshark Today: ICMP and UDP Network Security Lecture 5 Eike Ritter Network

slide-1
SLIDE 1

1/24/2012

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 1 Network 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

Eike Ritter Network Security - Lecture 5 3

4 8 16 12 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

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

slide-2
SLIDE 2

1/24/2012

ICMP Echo request/reply

Type = 0 or 8 Code = 0 Checksum Identifier Sequence number Optional data

Eike Ritter Network Security - Lecture 5 6

4 8 16 12 31 20 24 28

ICMP echo request

Eike Ritter 7 Network Security - Lecture 5

ICMP encapsulation

Eike Ritter 8 Network Security - Lecture 5

ping

Eike Ritter Network Security - Lecture 5 9

$ 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

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

Eike Ritter Network Security - Lecture 5 10

$ 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

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

slide-3
SLIDE 3

1/24/2012

ICMP echo-based attacks: smurf

Eike Ritter Network Security - Lecture 5 12

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

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

ICMP redirect

Eike Ritter Network Security - Lecture 5 14

Host: 172.16.48.100 Gateway: 172.16.48.1 Gateway: 172.16.48.2 Destination Gateway Flags 0.0.0.0 172.16.48.1 UG 1.1.1.255 172.16.48.2 UGHD Destination Gateway 1.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

Eike Ritter Network Security - Lecture 5 15

Type = 5 Code = 0, 1, 2, or 3 Checksum IP Address IP header + First 8 bytes of original datagram 4 8 16 12 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

Eike Ritter Network Security - Lecture 5 16

ICMP redirect attack

Eike Ritter Network Security - Lecture 5 17

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

slide-4
SLIDE 4

1/24/2012

ICMP redirect attack – cont’d

Eike Ritter Network Security - Lecture 5 18

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

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

Eike Ritter Network Security - Lecture 5 20

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)

Eike Ritter Network Security - Lecture 5 21

Type = 11 Code = 0 or 1 Checksum Unused IP header + First 8 bytes of original datagram 4 8 16 12 31 20 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 debugging

Eike Ritter Network Security - Lecture 5 22

traceroute – cont’d

Eike Ritter Network Security - Lecture 5 23

$ 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

slide-5
SLIDE 5

1/24/2012

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

Eike Ritter Network Security - Lecture 5 24

UDP message format

UDP source port UDP dest port UDP message length Checksum Data

Eike Ritter Network Security - Lecture 5 25

4 8 16 12 31 20 24 28

UDP message

Eike Ritter 26 Network Security - Lecture 5

UDP encapsulation

Eike Ritter Network Security - Lecture 5 27

Frame data Frame data Frame header Frame header IP header IP header IP data IP data UDP header UDP header UDP data UDP data

UDP encapsulation

Eike Ritter 28 Network Security - Lecture 5

UDP spoofing

  • Essentially, it is IP spoofing

Eike Ritter Network Security - Lecture 5 29

Server: 192.168.0.3 Attacker: 192.168.0.2 Client: 192.168.0.1 UDP request Spoofed UDP reply UDP reply

slide-6
SLIDE 6

1/24/2012

UDP hijacking

  • Variation of UDP spoofing attack

Eike Ritter Network Security - Lecture 5 30

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

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

Eike Ritter Network Security - Lecture 5 33

$ 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

UDP portscan

Eike Ritter Network Security - Lecture 5 34

$ 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

NEXT ON

Eike Ritter 35 Network Security - Lecture 5

slide-7
SLIDE 7

1/24/2012

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

Next time

  • TCP

Eike Ritter 37 Network Security - Lecture 5