Security Problems in the TCP/IP Protocol Suite

puffyyaphankyonkersΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 4 χρόνια και 15 μέρες)

73 εμφανίσεις

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 bitter
-
suite.

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

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.

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

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.

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

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 mis
-
configured 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 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

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 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™

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] http://www.isc.org/ds/host
-
count
-
history.html


[2]
http://www.sans.org/rr/malicious/morris.php


[3]
http://razor.bindview.com/publish/papers/tcpseq.html


[4] Personal experience


[5]
http://www.cert.org/advisories/CA
-
2002
-
03.html


[6] http://www.radium.ncsc.mil/tpep/library/rainbow/