Security Problems in the TCP/IP Protocol Suite

S.M. Bellovin

Presented By, Sammer Zai

23-09-2014Computer 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 1989. 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 1985.

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(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.

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.