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(ISN C ) S -> C: SYN(ISN S ), ACK(ISN C ) C -> S: ACK(ISN S ) 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 finger ing 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 finger ed 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.

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.phphttp://www.sans.org/rr/malicious/morris.php [3] http://razor.bindview.com/publish/papers/tcpseq.htmlhttp://razor.bindview.com/publish/papers/tcpseq.html [4] Personal experience [5] http://www.cert.org/advisories/CA-2002-03.htmlhttp://www.cert.org/advisories/CA-2002-03.html [6] http://www.radium.ncsc.mil/tpep/library/rainbow/