Security Problems in the
TCP/IP Protocol Suite
S.M. Bellovin
Computer Communications
Review; April 1989
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.
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 bittersuite.
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]
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.
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 rprotocols.
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.
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)
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
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.
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
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.
RIP: Backgrounder

RIP (Routing Information Protocol) is a
broadcast based routing protocol –
hosts announce (and propagate) hosts
and networks they have routes to.
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.
Vulnerability State: 2003

RIP has fallen out of fashion, but is still
run on some medium sized networks.
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.
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.
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.
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
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.
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.
Proposed Defense

Essentially – don’t trust ident for
anything important.
Application Protocols

Bellovin also enumerates issues with
several “standard” services:





Finger
Email (SMTP, POP)
DNS
SNMP
Remote Boot
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.
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.
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.
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.
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.
Vulnerability Status: 2003


While POP3 includes provisions for onetime 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.
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.
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.
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.
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 misconfigured the system, causing information
leaks.
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.
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.
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.
Remote Boot



How many people used/remember XTerms?
“thin clients” – they were diskless, and
so needed to load their kernel over the
network during bootstrap.
Two schemes were common:


RARP/TFTP
BOOTP
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


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.
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.
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.
Trivial Attacks: Reserved Ports

Suffice to say that since the first nonUnix machine appeared on the Internet,
relying on privileged ports (lower than
1024) for any form of authentication or
security is a Bad Idea™
Comprehensive Defenses


Authentication
Encryption
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.
Vulnerability Status: 2003


Most connections are still
unauthenticated.
SSL provides authentication based on
centralized trust.
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.
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.
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
Conclusions


Hosts should not give away knowledge
gratuitously.
Network control mechanisms are
dangerous and must be guarded.
References






[1]
[2]
[3]
[4]
[5]
[6]
http://www.isc.org/ds/host-count-history.html
http://www.sans.org/rr/malicious/morris.php
http://razor.bindview.com/publish/papers/tcpseq.html
Personal experience
http://www.cert.org/advisories/CA-2002-03.html
http://www.radium.ncsc.mil/tpep/library/rainbow/