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. We’ll 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 internet[1]. • 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 ISN’s • TCP sessions are established with a three-way handshake. • C -> S: SYN(ISNC) • S -> C: SYN(ISNS), ACK(ISNC) • C -> 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.” • We’ll 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 ISN’s [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 don’t 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 they’re trying to manage (by enforcing the validity of the current TCP sequence number). • A man-in-the-middle isn’t hindered by this. • Never update global routing tables due to REDIRECT messages • Don’t 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 – don’t 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@rage.oubliette.org Login: dberger Name: Dan Berger Directory: /home/dberger Shell: /bin/bash2 On since Sat Feb 8 17:38 (PST) on :0 (messages off) On since Tue Feb 11 12:13 (PST) on pts/3 from walkabout.cs.ucr.edu Mail last read Tue Feb 11 12:18 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 don’t need a service, disable it. • What isn’t running can’t 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 ISP’s provide old-fashioned POP services. • Assume your email password has been compromised.

32. DNS • It’s 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 it’s 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 it’s 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 xx:xx:xx:xx:xx:xx • 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 – it’s hard to be random when the machine is booting – it’s 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 – doesn’t 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-line[6]) prescribe stratified security requirements for U.S. government systems. • Systems are rated in terms of increasing trust from D to A1.