|
|
| Previous | Table of Contents | Next |
Phase one network attacks attempt to gain unauthorized access from a remote system. SATAN searches for phase one vulnerabilities that permit unauthorized access. One way of improving authorization over a network is using Kerberos. By using Kerberos, a system is no longer vulnerable to .rhosts attacks or password sniffers. SATAN is still useful against Kerberized environments, however, by helping remote hackers to identify the Key Distribution Center (KDC). If the hacker can succeed in breaking into a KDC system, all the hosts that use that KDC will be vulnerable.
The primary problem with Internet security today is that the passwords of users go across the network in the clear, and authentication is based solely on the IP address and password. Therefore, a hacker can, by using packet sniffing, capture the password and then impersonate the IP address, gaining access to a remote system.
MIT developed a system called Kerberos that uses the DES algorithm to encrypt network connections and provide for authentication. Described in RFC 1510, the Kerberos environment depends on the presence of a key server (KDC) that keeps a database of all the keys of each client. Each network service is modified to use authentication based on tickets that are handed out by the KDC in response to requests by network clients.
For example, each morning, a user logs in to a workstation by running a kinit program and typing a password. This generates a request from the workstation to the KDC for a ticket-granting ticket (TGT) that is good for the rest of the day. Now, when the user wants to telnet to a remote system, the telnet client uses the TGT to request a ticket from the KDC to gain access to the remote system. The ticket contains a session key that is then used by both the telnet client and server to encrypt the connection.
A network packet sniffer is unable to hijack the connection or impersonate either the client or the server. Kerberos uses the 56-bit DES algorithm to encrypt packets. This code cannot be exported outside the United States, but versions of it are widely available internationally.
Although Kerberos solves the problem of connection hijack and impersonation, it adds complexity to the administration of the environment. The system admin must now maintain KDCs to support the network. If the KDCs go down or become unreachable, the users are unable to use the network. If the KDCs are violated, the security of the entire network has been destroyed. Finally, the maintenance of the Kerberos configuration files is somewhat complex and frequently time-consuming. Some Kerberos implementations are unsecure on multiuser systems. From a SATAN standpoint, one might want to identify remote hosts that offer KDC servers and focus attacks on these systems. Imagine if the KDC ran NFS; the hacker could use NFS-based attacks to gain access to that system, permitting the hacker to gain access to all systems that trusted that KDC.
Kerberos is available to U.S. sites from MIT. Other vendors, such as Cybersafe, offer commercial Kerberos implementations.
Note: For detailed information on Kerberos, see Chapter 9, “Kerberos.”
SATAN searches for phase one vulnerabilities. Another way of dealing with such vulnerabilities is the recently introduced Secure Shell, or ssh, program. A replacement for rlogin, remsh, and rcp, ssh doesn’t require the overhead of Kerberos (users don’t have to kinit, and the system administrators do not need to maintain KDCs) and offers higher levels of cryptographic security. In addition, it can be used to improve X Windows security.
Secure Shell protects against IP spoofing, IP source routing, DNS spoofing, corruption of data in a connection, and X authentication attacks.
The latest version of the ssh FAQ is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/. The program itself is available from ftp://ftp.cs.hut.fi/pub/ssh/.
Yet another way of dealing with phase one vulnerabilities, the vulnerabilities that SATAN is designed to locate, is SSL. Introduced originally to provide security for web browsers by encrypting http connections, SSL, or the Secure Socket Library, has gained quite a following over the past year as a vehicle to provide security for general Internet services. A draft RFC describes version 3 of the protocol, enabling anyone to implement daemons, although licensing for the public key technology is still required.
SSL uses public key technology to negotiate a session key and cryptographic algorithm between a client and server. The public key is stored in an X.509 certificate that bears a digital signature from a trusted third party, such as RSA Data Security, Inc.
SSL moves the details of encryption and authentication into the socket library calls, making implementation of Internet programs much easier. The SSL calls directly parallel standard socket library calls. Compared to making a Kerberos server, making an SSL server is vastly simpler.
From a user standpoint, SSL no longer requires the active participation of a KDC, because the digital signature takes place offline. So the network connection is a two-party transaction, rather than a three-party transaction. Both the client and server can be authenticated, although current Netscape client browsers are using only server authentication. The SSL protocol negotiates a crypto algorithm at the beginning of a connection; DES, triple-DES, IDEA, RC4, and RC2, along with md5 hashes, are advertised in common implementations. To meet U.S. export restrictions, SSL implementations shipped out of the United States can advertise only RC4-40, which uses 40-bit keys.
Two publicly available implementations of SSL libraries are popular: SSLref and SSLeay. SSLref, a product of Netscape Corporation, is free for non-profit uses and can be licensed for commercial purposes. It requires the RSAREF library from RSA Corporation. SSLeay is a public domain version of SSL that includes implementations of the RSA algorithms over which RSA Data Security, Inc. claims legal ownership in the U.S.
Multiple versions of Telnet, FTP, http, Mosaic, and rdist have been implemented using SSL and are available from the SSLeay archives. The addresses follow:
| Previous | Table of Contents | Next |