Security Problems in the TCP/IP Protocol Suite

Download Report

Transcript Security Problems in the TCP/IP Protocol Suite

Security Problems in the
TCP/IP Protocol Suite
Presented by:
Sandra Daniels, José Nieves, Debbie
Rasnick, Gary Tusing
Article by: S. M. Bellovin
AT&T Bell Laboratories
April, 1989
TCP/IP Protocol Suite



Widely used
Developed under DOD
Serious security flaws
Topics to be Discussed

Problems and defenses






Handshake sequence numbers
Routing
Authentication
Service protocols
Comprehensive defenses
Conclusion
TCP Sequence Number





TCP Handshake
C → S: SYN (ISNc)
S → C: SYN (ISNs), ACK (ISNc)
C → S: ACK (ISNs)
C → S: data
And/or
S → C: data
Mechanism



ISNs variable incremented by constant
(once per second) and by half that
amount each time a connection is
initiated. ISNs a number precisely the
round-trip between the client and server
ISNs predictable, can be guessed by
intruder
No authentication except IP address
Problem




ISNs not true random number
Easy to calculate or predict
Can be used to spoof trusted host
Easy and cheap for Intruder
Defenses


Don’t use netstat protocol
Generate ISNs some other way
Randomization
Use cryptographic algorithm with key

Randomize increments instead of basing
them on predictable or measurable factor
1
Defenses (cont.)

USE DES to generate ISNs

Good Logging

Alerting mechanisms
Routing
ISSUES

Routing mechanisms
can be abused


Denial of Service –
confusing routing tables
Source Routing


Reverse the TCP route
on a request (if one is
used).
The attacker may be
able to identify an IP
address and network in
the source domain, the
first step gaining control
of a host
POSSIBLE DEFENSES


Hard to defend
Possibilities:


Local net rejects all
external packets claiming
to be from the local net
(not practical and
extreme)
Analyze source route and
accept it only if trusted
gateways are listed
(again, hardly practical)
RIP Attacks
ISSUES

RIP – Routing Information
Protocol (widely used)




Routing information
received is often
unchallenged
Intruder can send bogus
routing information and thus
re-direct packets to a nontrusted entity, network, or
host (impersonating)
Hard to authenticate RIP
packets
Bogus routing information
disseminates to other
routers
POSSIBLE DEFENSES

Establishing a “paranoid”
gateway


One that filters packets
based on source or
destination address only,
not on the route
Would have to make RIP
more skeptical of the routes
that the router is willing to
accept
EGP
ISSUES


Protocol for
communications
between core routers
Impersonation of a real
gateway when such is
down is not hard with
this routing protocol

Broadcast a route
directing others to an
offline router, while
impersonating that router
POSSIBLE DEFENSES

Always make exterior
gateways be on the
core network so that
attacker has a harder
time impersonating the
offline router
ICMP
ISSUES

The Internet Control
Message Protocol is
used for echo requests
from remote hosts
(connectivity)


POSSIBLE DEFENSES


ICMP attacks are difficult
because of ICMP packet’s
simplicity
Yet, ICMP packets can be
used to:


Redirect routes (such as
with RIP)
DoS attacks

Again, “paranoia”
Restrict routing changes
to specified
connections, not in
response to ICMP
Redirect messages
Check that an ICMP
packet is tied up to a
particular connection
only
Authentication Server



Used instead of address-based authentication
Nothing more than a Trusted Host that will
mediate our connections and establish trusted
identities
Should not rely solely on TCP/IP for
authentication; should use some other algorithm
Services Within
the Suite


Finger
Email






POP
PCMAIL
DNS
FTP
SNMP
Remote Booting
Finger


Problem: Gives away too much
information to hackers
Solution: Disable service
POP


Problem: Conventional passwords are
vulnerable
Solution: One-time passwords using
cryptographic key
PCMAIL


Problem: Same as POP, but also supports
password-change command with
unencrypted passwords
Solution?
DNS


Problem: Sequence number attack leading
to spying on traffic/capturing passwords
Solution: Run domain servers on highly
secure machines and use authentication
on domain server responses
DNS cont…



Problem: Recursive zone transfer requests
to download entire database
Solution: Employ “refused” error code for
any requests from unidentified servers
Also, Kerberos tickets can be used to
authenticate DNS queries
FTP




Problem: Use of simple passwords for
authentication
Solution: One-time passwords
Problem: Anonymous FTP
Solution: Be careful with sensitive data
(such as encrypted passwords)
SNMP


Problem: In the wrong hands, can divulge
too much information
Solution: Protect this service (through
authentication)
Remote Booting


Problem: Boot process can be subverted
and new kernel with altered protection
mechanism can be substituted
Solution: Ensure boot machine uses
random number for UDP source port and
use 4-byte transaction ID
Trivial Attacks



ARP
TFTP
Reserved Ports
Comprehensive Defenses



Authentication
Encryption
Trusted Systems
Authentication




One of the overall problems is TCP/IP
reliance on IP source address for
authentication
Too easy to spoof IP address
Needs some form of cryptographic
authentication
Needham-Schroeder algorithm
Needham-Schroeder algorithm




Relies on each host sharing a key with an
authentication server
Versions exists for both private-key and
public-key cryptosystems
Host wanting to communicate request key
from authentication server & passes a
sealed version along to destination
At conclusion of dialog, each side has
verified id of other
Needham-Schroeder algorithm



Allows pre-authenticated connections that
are safe
DNS provides ideal base for authentication
systems
Key distribution responses must be
authenticated and/or encrypted
Encryption

Can defend against most problems

Disadvantages:




Expensive
Slow
Hard to administer
Uncommon in civilian sector
Encryption

Two types:
Link Level including
 Multi-points link encryption



End-to-end encryption
Major benefits
Implied authentication they provide
 Provide privacy

Link Level Encryption

Encrypting each packet as it leaves the
host
Excellent to protect confidentiality
Works well against physical intrusion

Weaknesses:




Broadcast packets are difficult to secure
Implies trust of gateways
Blacker Front End
(BFE)




A multi-point link encryption device for
TCP/IP
Looks to host as an X.25 DDN interface
Sits between host and actual DDN line
Receives call with new destination,
contacts Access Control Center for
permission and Key Distribution Center for
cryptographic keys
BFE




If local host is denied permission to talk to
remote host, appropriate diagnostic code
is returned
Special Emergency Mode when link to KDS
or ACC is not working
Permission checking can protect against
DNS attacks
Totally unauthorized host does not receive
sensitive data
BFE


Also translates original “Red” IP address to
encrypted “Black” address using a
translation table supplied by ACC
Foils traffic analysis which are bane of all
multi-point link encryption
End-to-end encryption





Above the TCP level
To secure conversations regardless of
number of hops
Or quality of links
Appropriate for centralized network
management applications
Key distribution/management greater
problem (more pairs involved)
End-to-end encryption


Encryption and decryption done before
initiation or after termination of TCP
processing, host level software must
handle translations resulting in extra
overhead for each conversation
Vulnerable to denial of service attacks
Trusted Systems



Hosted and routers rated B2 or higher
immune to attacks described here
C2 level systems are susceptible
B1 are vulnerable to some but not all
attacks
Conclusions
1. Relying on IP source address for Authentication
is dangerous
2. Second broad class of problems deals with
sequence number attacks (unpredictable and
unseen)
3. Hosts should not be giving away information
gratuitously (finger and netstat)
4. Intelligent use of default routes
5. Use verifiable point-to-point routing protocols
instead of broadcast-based routing
6. Network control mechanisms must be guarded