Security Problems in the TCP/IP Protocol Suite

1
Security Problems in the TCP/IP Protocol Suite

• S.M. Bellovin
• Computer Communications Review April 1989

2
Overview

• Bellovin takes a critical look at each of the
  components of the TCP/IP protocol suite.
• From the network layer (e.g. routing) to the
  application layer.
• He discusses (potentially) exploitable flaws in
  each, and where possible defenses against
  them.

3
Well be back, after these messages

• Excellent memoir, penned by the head of
  communications for the SOE.
• Invaluable as a historical record.
• Inspiring, enlightening, and torturously
  bitter-suite.

4
Setting the Stage

• In April 1989 (when this paper was published)
  there were between 80k and 130k hosts on the
  internet1.
• There were 162 Million as of 7/2002
• In November 1988, the the Morris worm infected
  10 of the internet (some 6000 hosts) causing an
  estimated 98 Million in damage.2

5
TCP Sequence Number Prediction

• Initially described by Morris in 1985.
• Exploits predictability in ISN generation as a
  foot in the door.

6
SYNs ACKs and ISNs

• TCP sessions are established with a three-way
  handshake.
• C -gt S SYN(ISNC)
• S -gt C SYN(ISNS), ACK(ISNC)
• C -gt S ACK(ISNS)
• If the ISNs generated by a host are predictable,
  the other end-point need not see the SYN response
  to successfully establish a TCP session.

7
About That Door

• If an adversary can establish a TCP session
  without seeing the response packets, they can
  fly blind.
• Well look at this again when we talk about
  source address spoofing the r-protocols.

8
Vulnerability Status 1989

• Bellovin discusses Berkley-derived TCP stacks,
  which increment the sequence number 1/second.
• Highly predictable with a single observation at a
  known time.

9
Proposed Defense

• If an attacker can accurately measure and predict
  the round-trip time, any scheme that increments
  linearly can be compromised with some effort.
• So, the ISN should be randomized.
• Bellovin suggests using DES in ECB mode,
  encrypting the value of a simple counter.
• Also note p4, 3 a recipe for log analysis (IDS)

10
Vulnerability Status 2003

• As of June 2002, several Operating Systems still
  have highly predictable ISNs 3
• Notably
• Windows NT4
• Windows 9x
• AIX 4.3
• HPUX 11
• MacOS 9

11
Source Routing

• Giving a packet an explicit path to follow to a
  destination.
• If the target uses the inverse of the supplied
  route as the return path, it permits address
  spoofing.
• Note that even if the target ignores the inverse
  path, if you can predict an ISN, you can still
  address spoof.

12
Proposed Defense

• Bellovin suggests that
• the best idea would be for gateways into the
  local net to reject external packets that claim
  to be from the local net.
• But points out that sometimes this is not
  practical for arbitrary wide-area topologies.
• He then suggests that such topologies should be
  avoided.

13
Vulnerability Status 2003

• Most routers have explicit rules to handle
  source-routed packets.
• Many (like Cisco IOS as of version 9) ship with
  source-routing enabled.4
• At least some broadband routers dont have
  explicit source-routing configuration options.
  4
• This presents a potential vulnerability

14
Poisoning Routing Tables RIP

• Two attack modes are discussed
• Host impersonation diverting packets for a
  specific host to compromise schemes which use
  source address for authentication.
• Man-In-The-Middle diverting packets for
  inspection and forwarding them on via
  source-routing.

15
RIP Backgrounder

• RIP (Routing Information Protocol) is a broadcast
  based routing protocol hosts announce (and
  propagate) hosts and networks they have routes to.

16
Proposed Defense

• Bellovin suggests two approaches
• Skepticism
• In most scenarios, it is useful to be strict
  about what you generate and be lenient about what
  you accept this is not the case in a security
  context.
• Cryptographic Authentication
• For a broadcast protocol like RIP, this requires
  pervasive PKI.

17
Vulnerability State 2003

• RIP has fallen out of fashion, but is still run
  on some medium sized networks.

18
IDS Note

• On p5, 7, Bellovin makes an interesting aside
• Good log generation would help, but it is hard
  to distinguish a genuine intrusion from the
  routing instability that can accompany a gateway
  crash.
• This is a hard problem in general and the focus
  of modern IDS systems.

19
Fun with ICMP

• ICMP (Internet Control Message Protocol) is the
  basic network management tool of the TCP/IP
  world.
• ICMP REDIRECT was intended to allow gateways to
  inform clients of better routes to their
  destination.
• Under some circumstances, this may be equivalent
  to poisoning a routing table.

20
ICMP DoS

• An attacker may be able to disrupt a TCP session
  by sending an ICMP Destination Unreachable or TTL
  Expired message.
• Additionally an unsolicited Subnet Mask Reply
  could disrupt connectivity to the target host.

21
Proposed Defense

• A modicum of paranoia
• Insure that ICMP messages truly associate with
  the session theyre trying to manage (by
  enforcing the validity of the current TCP
  sequence number).
• A man-in-the-middle isnt hindered by this.
• Never update global routing tables due to
  REDIRECT messages
• Dont propagate the lie

22
Auth Server (identd)

• Many hosts run an authentication server which
  will, given a port, return the effective user id
  of the process attached to that port.
• This request involves a second TCP connection
  so it can help prevent ISN and source routing
  attacks.

23
Who Do You Trust?

• The trouble is that you still need to trust the
  information coming back from identd
• if the host is compromised or untrustworthy, this
  authentication is meaningless.

24
Proposed Defense

• Essentially dont trust ident for anything
  important.

25
Application Protocols

• Bellovin also enumerates issues with several
  standard services
• Finger
• Email (SMTP, POP)
• DNS
• SNMP
• Remote Boot

26
Finger Who?

• In the Good Old Days when everyone was running
  Unix you could gather information on a user by
  fingering the user at their host.
• finger dberger_at_rage.oubliette.org
• Login dberger Name Dan
  Berger
• Directory /home/dberger Shell
  /bin/bash2
• On since Sat Feb 8 1738 (PST) on 0 (messages
  off)
• On since Tue Feb 11 1213 (PST) on pts/3 from
  walkabout.cs.ucr.edu
• Mail last read Tue Feb 11 1218 2003 (PST)
• No Plan.

27
Finger (Cont)

• Additionally, if you fingered a host it would
  report all currently logged in users.
• The trouble is that finger gave out loads of
  potentially valuable information.
• The activity level of the account
• Last login, last mail read
• Name, office, etc.

28
Proposed Defense

• Simple Turn the service off.
• In general, this turns out to be a good idea
• If you dont need a service, disable it.
• What isnt running cant be exploited.

29
Email The Killer App

• In his brief treatment of email Bellovin
  mentions a proposed new encryption standard for
  email (PEM)
• It was essentially still-born.
• Notably absent is a discussion of SMTP
• One of the avenues exploited by the Morris worm
  only a few months prior.

30
POP

• POP, then POP2, and now POP3 are all similar
  they provide a line-oriented protocol for simple
  mailbox retrieval.
• They are all plain-text protocols, and pass
  authentication secrets over a typically
  unprotected channel.

31
Vulnerability Status 2003

• While POP3 includes provisions for one-time
  secrets and non-plain text authentication, as
  well as SSL channel encryption, the majority of
  ISPs provide old-fashioned POP services.
• Assume your email password has been compromised.

32
DNS

• Its interesting that DNS gets such a just
  another service treatment.
• Recall that in 1989 the internet was a bunch of
  islands of connectivity.
• The need for pervasive DNS really came with the
  web.

33
DNS (II)

• Bellovin concerns himself primarily with
  information leakage from DNS by transferring a
  zone file, you can
• Learn the relative size of an organization
• potentially learn something about its intranet
  topology
• Extract a list of interesting looking targets.
• Remember this is several years before the
  notion of firewall was common place.

34
FTP

• Like nearly all protocols of its day, FTP
  transmits authentication secrets in plaintext
  over an insecure channel.
• Bellovin mentions one-time passwords
• Systems like SKEY, SecureID, and others
• A user was issued a device/program for generating
  the next password given a challenge.

35
Anonymous FTP

• Note the statement on p10, 2
• Some implementations of FTP require creation of
  a partial replica of the directory tree
• The idea was to put anonymous FTP in a restricted
  environment. (a chroot jail)
• Unfortunately, often administrators
  mis-configured the system, causing information
  leaks.

36
Vulnerability Status 2003

• Modern FTP servers can be configured to handle
  anonymous ftp safely
• so the danger is now that someone places
  materials on your machine which open you to
  (legal) repercussions.

37
SNMP

• What Bellovin gives a one-line treatment turns
  out to be one of the most problematic parts of
  the protocol suite.
• SNMP protects access to data with shared secrets
  which are (you guess it) transferred in the clear
  over insecure channels.

38
Vulnerability Status 2003

• In 2002, a exploitable behavior was found in many
  SMNP implementations. 5
• It is likely, given history, that many of these
  affected versions are still active in the wild.

39
Remote Boot

• How many people used/remember X-Terms?
• thin clients they were diskless, and so
  needed to load their kernel over the network
  during bootstrap.
• Two schemes were common
• RARP/TFTP
• BOOTP

40
RARP/TFTP

• RARP ARP (Address Resolution Protocol) run in
  reverse.
• Rather than asking what MAC address maps to IP
  address xxx.xxx.xxx.xxx, it asked what IP
  address maps to MAC address xxxxxxxxxxxx
• TFTP allowed file transfer without authentication.

41
The Trust of a Child

• The potential for misadventure should be obvious.
• If I can compromise the boot process, I can
  install my own kernel.

42
BOOTP

• BOOT adds a random transaction ID to prevent an
  attacker from blindly replying to a booting
  machine.
• Trouble is its hard to be random when the
  machine is booting its a very deterministic
  process.

43
Vulnerability Status 2003

• DHCP (Dynamic Host Configuration Protocol) is a
  direct descendant of BOOTP.
• Compromising a DHCP server, or spoofing responses
  could, in principal, be an effective DoS.

44
Trivial Attacks Ethernet

• Bellovin notes that Ethernet is extremely
  vulnerable to eavesdropping and host-spoofing.
• For a short time it was said that fibre optic
  (rather than copper) removed this vulnerability,
  but that was quickly recanted when a simple
  device to tap fibre was demonstrated.

45
Trivial Attacks Reserved Ports

• Suffice to say that since the first non-Unix
  machine appeared on the Internet, relying on
  privileged ports (lower than 1024) for any form
  of authentication or security is a Bad Idea

46
Comprehensive Defenses

• Authentication
• Encryption

47
Who am I Speaking To?

• Needham Schroeder which requires that each
  participating host share a key with an
  authentication server doesnt scale.
• It goes against the distributed nature of the
  internet.

48
Vulnerability Status 2003

• Most connections are still unauthenticated.
• SSL provides authentication based on centralized
  trust.

49
Encryption

• Bellovin discussed both link-level and end-to-end
  encryption.
• Link-level encryption is still a viable solution
  in some contexts.
• End-to-end encryption relies on pervasive PKI.
  Still a pipe-dream.

50
Trusted Systems

• The So-called Rainbow Books (available
  on-line6) prescribe stratified security
  requirements for U.S. government systems.
• Systems are rated in terms of increasing trust
  from D to A1.

51
Alphabet Soup

• D No security any system which fails to
  qualify for any higher rating
• C-1, C-2 Basic Access Controls Credentials,
  ACLs, etc.
• B-1, B-2, B-3 C-2 explicit security policy
  statement
• A-1 Verified design

52
Conclusions

• Hosts should not give away knowledge
  gratuitously.
• Network control mechanisms are dangerous and must
  be guarded.

53
References

• 1 http//www.isc.org/ds/host-count-history.html
• 2 http//www.sans.org/rr/malicious/morris.php
• 3 http//razor.bindview.com/publish/papers/tcpse
  q.html
• 4 Personal experience
• 5 http//www.cert.org/advisories/CA-2002-03.html
  
• 6 http//www.radium.ncsc.mil/tpep/library/rainbo
  w/