This system gives the hacker no information at all, other than SVR4 as a system type. This came from an SGI IRIX system, but there is no way to tell that for sure from this prompt.

% ftp m4.notreal.com
Connected to m4.notreal.com.
220 m4 FTP server (SunOS 4.1) ready.

This is a Sun OS 4.1 system. The hacker does not need to use the system command. (It actually does not allow a system command.)

% ftp mail.notreal.com
220 mail FTP server (Version wu-2.4(10) Mon Nov 21 17:34:06 PST 1994) ready.

This one is interesting. It is running the wu-ftpd, the leading ftpd implementation. This popular ftpd offers extensive functionality. An older version of wu-ftpd had a security hole with the SITE EXEC protocol statements, discussed later in this chapter, that is checked for by SATAN. Unfortunately, wu-ftpd gives no information on the system type.

% ftp sys3.notreal.com
220 sys3 FTP server (Version 4.1 Sat Aug 27 17:18:21 CDT 1994) ready.
ftp> system
215 UNIX Type: L8 Version: BSD-44

The Version 4.1 is an IBM AIX version number; however, the BSD-44 does not guarantee that the system is an IBM AIX source, because others could give this same answer.

% ftp sys4.notreal.com
Connected to sys4.notreal.com.
220 sys4 FTP server (Version 1.7.193.3 Thu Jul 22 18:32:22 GMT 1993) ready.
ftp> system
215 UNIX Type: L8

This system gives no information at all; it came from an HP-UX 9.x workstation. The only thing that might give it away is the version number, but this is no certainty, because other versions of Unix might put a similar RCS type number in the Version banner.

sendmail Information

By talking directly to the SMTP port, TCP port number 25, a hacker can ask the SMTP daemon, almost always sendmail, to provide information on the remote system and on itself. sendmail is a great source of security holes, because it wasn’t designed with security in mind, typically runs set-uid to root, consists of tens of thousands of lines of C code, has a large and complex configuration file that is customized by every user, and is run on almost every host that acts as a transport agent for e-mail on the Internet. Non-Unix systems such as Macs or PCs that want to send Internet e-mail will typically make a direct connection to a Unix system running sendmail. The Macs or PCs do not typically act as mail transport agents on the Internet.

The hacker would like to get information on the host OS and the version of sendmail. He could also use EXPN (expand), HELP, and VRFY to identify information such as the identity of the postmaster (a requirement for all mail hosts), root, guest, webmaster, ftp, UUCP, lp, and www. The hacker is quite interested in finding mail expansions that indicate programs, files, or mailing lists.

If sendmail is configured to permit EXPN, the sendmail aliases file is read and the expansion corresponding to the entry is returned. If only VRFY is permitted, the hacker can still verify the existence of accounts in the /etc/passwd file. A utility program, expand_alias, is available that can automate expansion searches.

For an example, here is what the hacker sees when interrogating sendmail on the systems in notreal.com:

% telnet dns1.notreal.com 25
220 dns1.notreal.com. Sendmail 5.0/SMI-SVR4 ready at Sat, 11 Nov 95 19:47:37 PST

---

Note:  sendmail typically reports back the version of the binary as the first field after the name sendmail in the initial banner, followed by a / and the version of the configuration file. This is configurable via the sendmail.cf file and may differ on some machines.

---

The sendmail binary appears to have a 5.0 version, and the config file has an SMI-SVR4 version. The SMI stands for Sun Microsystems Inc., and 5.0 stands for the Sun OS 5.0 or Solaris 2.0 system.

% telnet m2.notreal.com 25
Connected to m2.notreal.com.
220 m2 Sendmail 5.65v3.2 (1.1.3.6) Sat, 11 Nov 1995 20:04:27

The binary says 5.65v3.2, which indicates that it is version 5.65 of sendmail. The 3.2 appears to hint that this is an IBM AIX system, but this is really not the case. Recall from the ftpd banner that this system is a DEC OSF/1 box. Notice that the config file version information is separated by a space and surrounded by parentheses. It appears to be an RCS version number. This could be useful when reverse-engineering patches that included security fixes.

% telnet m3.notreal.com 25
220 m3.notreal.com Sendmail 931110.SGI/930416.SGI ready at Sat, 11 Nov 95
19:54:12 -0800

This is clearly the SGI system. Notice the dates of the sendmail binary (931110.SGI) and sendmail config file (930416.SGI). This is useful if a hacker finds that a sendmail security hole occurred after the given date in the header string. Luckily for this intruder, there have been several sendmail holes since November 93. A hacker can find details on that by studying the CHANGES file for the latest sendmail available from UCB.

% telnet m5.notreal.com 25
220 m5. Sendmail 4.1/SMI-4.1 ready at Sat, 11 Nov 95 19:53:48 PST

SMI tells you that this is a Sun OS, and 4.1 indicates the version of the Sun OS. There is no information on the version of sendmail, although you can make assumptions based on the OS version.

% telnet sys3.notreal.com 25
220 sys3.notreal.com Sendmail AIX 4.1/UCB 5.64/4.03 ready at Sat, 11 Nov 1995
20:22:55 -0800

This banner is quite clear about the OS version (IBM AIX 4.1) and the sendmail version (5.64). This is quite useful.

% telnet mail.notreal.com 25
220 mail.notreal.com ESMTP Sendmail 8.7/8.7; Sat, 11 Nov 1995 20:05:52 -0800 (PST)

This system is running the latest version of sendmail from the UCB distribution.

% telnet sys4.notreal.com 25
220 sys4.notreal.com HP Sendmail (1.37.109.8/15.6) ready at Sat, 11 Nov 1995
21:36:36 -0800

This system clearly announces that it is an HP (HP-UX) system. Although the ftpd on HP-UX did not announce the OS type, the sendmail daemon does. No real information on the version of the daemon, though.

---

Note:  The amount of information gained by interrogating each network daemon on the target systems can easily overwhelm an intruder. A nice report and summary tool could be quite useful, and SATAN provides this. In the absence of such a tool, perhaps a spreadsheet or custom database could help maintain the information.

---

The list of sendmail holes is quite lengthy; however, the latest sendmail from ftp://ftp.cs.berkeley.edu/pub/sendmail/ currently 8.8.5 nearly always has patches for all known holes. Running that sendmail, or making sure your vendor has all patches that this version contains, can make your system as safe as it can be. Using smrsh and a small list of permissible programs can also improve your sendmail security, as can disabling VRFY and EXPN, although this does remove some of the usefulness of the e-mail infrastructure.