Internet Security Professional Reference:SATAN and the Internet

-->

The weakness in this approach is that any packet sniffer that captures the network transmission of the magic cookie, which takes place without encryption, can use it to gain access. If the client’s .Xauthority file is readable by an intruder, the intruder can find the magic cookie. Note that the magic cookie approach now permits user authentication rather than xhost’s mere system authentication. (Each user has his or her own .Xauthority file containing magic cookies for accessible X servers.)

A new CIAC advisory indicates that the randomization scheme used to send the selection of the magic cookie may be too predictable, weakening this form of defense. An improved randomization algorithm is referenced in the advisory (Fisher, 1995).

Another weakness in X server systems involve xterms. If the xterm has an X resource definition of xterm*allowSendEvents: True, then the X server can request the xterm to send information about events such as keystrokes. This permits a remote intruder to capture the user’s typing. The xterm can dynamically set this option through the xterm’s main options menu.

Note: For complete details on X Windows security, see the paper by John Fisher at the CIAC web site (Fisher, 1995).

In general, if xhost access is permitted, the remote system names should be specified rather than +. The .Xauthority mechanism should be used if at all possible.

SATAN Itself

Although SATAN can be run from the command line, SATAN was primarily meant to be run interactively from a web browser. When run interactively, SATAN runs a simple HTML server, perl/html.pl, which processes URL requests sent from the web browser. The HTML server listens on a random port and requires a password to permit access to various URLs. This password is a 32-bit md5 hash that is meant to be somewhat random and difficult to guess.

The goal of this design is to prevent unauthorized users from sending requests to the HTML server. Because SATAN runs as root, compromising the HTML server could permit a hacker to execute SATAN commands.

Because the SATAN HTML server runs on the same system as the browser, the URL is never sent over a network. However, some web browsers disclose the SATAN URL when outside URLs are selected after running SATAN. With version 1.1 and up, SATAN prints a warning when a browser includes such behavior.

In general, exit the web browser after running SATAN and before trying to use the browser to connect to other web sites. An alternative is to use only a web browser that can be configured to prevent such behavior. Web browsers that permit remote web sites to gather information on previous URLs represent a security problem, because they contribute to information leakage. Recent versions of Mosaic (2.6) do not transmit URL information.

With version 1.1 and up, SATAN rejects requests that originate on hosts other than the one that SATAN is running on, based on source IP address. As usual, a hacker might use IP spoofing to circumvent this restriction.

A Modem on a TCP Port

SATAN sends a standard modem AT command to each TCP port. If the port replies with OK, it assumes that a modem is connected to that port.

An intruder who finds a modem directly connected to the TCP port of a remote system can use it to directly dial out. Modems should never be directly connected to a TCP port, and especially never to TCP ports that are directly connected to the Internet. If a modem is required on a TCP port, a tcp-wrapper and/or S/Key authentication should be considered.

Other Network Vulnerabilities

Even though SATAN does not specifically investigate the following issues, they do present some significant areas of concern for system security.

Passwords

Password selection is very important. The primary target of the first phase of a network attack, which is the primary goal of a SATAN scan, is the password file, so that the hacker can run Crack against it. Programs that force users to choose good passwords can help protect logins. These programs can require passwords that are not in a dictionary or that contain a strange assortment of numbers and non-alphabetic characters.

Tip: A paper by Walter Belgers (Belgers, 1991) on choosing passwords is very useful on this topic. It is available from ftp://ftp.win.tue.nl/pub/security/UNIX-password-security.txt.Z.
Several papers by Gene Spafford are available on this topic, from the COAST Web page or FTP archive.

It is dangerous for a user to invoke standard telnet, rlogin, or FTP over the Internet. The user types a password that is sent without encryption. One must assume that a hacker is packet sniffing and watching for the unencrypted transmission of passwords, as is typical in FTP, telnet, rlogin, and rexec. If a user does type the password over an Internet connection, it is important that the user change the password as soon as possible once the user returns to a connection within the organization’s firewall.

Users should change passwords often and consider using one-time passwords (S/Key, or Opie), ssh, SSL applications, Kerberos (tickets), or smart cards. Using shadow passwords protects user passwords from Crack attacks. Not putting them into ~ftp/etc also protects user passwords from Crack attacks.

Tip: Ftpd typically uses only the ~ftp/etc/passwd file for mapping uids to login names, so that the ls command prints an owner rather than a number. Some versions of ftpd, notably wu-ftpd, permit sublogins, where a user first logs in anonymously, gets placed into a chrooted environment of ~ftp, then does a sublogin as that user. In such situations, the ~ftp/etc/passwd password field is used to permit the login. The admin should require each user to choose a new password, clip the encrypted version of that from the /etc/passwd field, put that in the ~ftp/etc/passwd entry, and then require the user to select a new and different password for the regular account. If sublogins are not used, an * can be put into the password field of the ~ftp/etc/passwd file.

As an administrator, there is one way to deal with protecting the NIS passwd map: run NIS only behind a firewall. The NIS server sends a passwd map in response to any request with the appropriate domain name. Guessing the domain name can be done, and programs like ypx can help to send maps.

Secure RPC and NIS+ can help to hide the password map, but the encryption strength has been questioned. Export restrictions may prevent non-U.S. users from getting programs using DES encryption. Finally, the administration of a system using Secure RPC or NIS+ is frequently considered more difficult than regular NIS.

Table of Contents