Security Problems in the TCP/IP Protocol Suite S.M. Bellovin Presented By, Sammer Zai Computer Vision and Pattern Recognition Laboratory, Hanyang University

Overview TCP/IP and their associated protocols were designed without any security consideration in mind. This paper was written in It gave the security perspective on TCP/IP protocols in the early days. It acted as a wake up call for network researchers, listing many security vulnerabilities.

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.

TCP Sequence Number Prediction Initially described by Morris in Exploits predictability in ISN generation as a “foot in the door.”

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. If an adversary can establish a TCP session without seeing the response packets, they can “fly blind”.

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. An additional defense involves good logging and alerting mechanism. Timing measurement techniques would involve attempted TCP connections. Spoofing an active host will eventually generate unusual types of RST packets.

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.

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.

RIP RIP (Routing Information Protocol) is a broadcast based routing protocol – used to propagate routing information on local networks. Typically, the information received is unchecked.

Poisoning Routing Tables: RIP Two attack modes are discussed: Host impersonation – this would cause all the packets destined for that host to be sent to intruder’s machine. “Man-In-The-Middle” – diverting packets for inspection and forwarding them on via source-routing.

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”. Cryptographic Authentication For a broadcast protocol like RIP, this requires pervasive PKI.

Proposed Defense 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.

Authentication Server 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.

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. Risks: All hosts are not competent to run authentication servers. Authentication message itself can be compromised by routing table attacks. If the target host is down, a variant on the TCP sequence number attack may be used.

Proposed Defense TCP itself is not adequate. User should use a more secure means of validation, such as Needham Schroeder algorithm.

Application Protocols Bellovin also enumerates issues with several “standard” services: DNS FTP Authentication Anonymous FTP Remote Boot

DNS DNS provides for a distributed database mapping host names to IP addresses. Interference with the proper operation of DNS can mount a variety of attacks such as denial of service and password collection. A combined attack on the domain system and the routing mechanism can be a great damage.

Domain servers should only run on highly secure machines. Authentication techniques on domain server must be used. Proposed Defense

FTP Like nearly all protocols of it’s day, FTP transmits authentication secrets in plaintext over an insecure channel. Bellovin mentions one-time passwords: A user was issued a device/program for generating the next password given a challenge.

Anonymous FTP Bellovin said that; “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. Unfortunately, often administrators mis- configured the system, causing information leaks.

Remote Boot Booting up a client machine from the server. “thin clients” – they were diskless, and so needed to load their kernel over the network during bootstrap. Two schemes were common: RARP with TFTP BOOTP with TFTP

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.

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.

BOOTP BOOTP is a protocol that gives the information to a diskless device. It uses UDP protocol. 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.

Comprehensive Defenses Authentication Encryption

Authentication Needham Schroeder – which requires that each participating host share a key with an authentication server. DNS provides an ideal base for authentication system.

Encryption Bellovin discussed both link-level and end-to-end encryption. Link-level encryption End-to-end encryption

Conclusions Relying on the IP source address for authentication is extremely dangerous. Hosts should not give away knowledge gratuitously. Network control mechanisms are dangerous and must be guarded.