Last revised: September 19, 1997
Attached Copyright Statement
August 30, 1996 - Information previously in the README was inserted into the advisory.
A complete revision history is at the end of this file.
The CERT Coordination Center has received information concerning software that allows automated scanning of TCP/IP networked computers for security vulnerabilities. This software was posted to the comp.sources.misc Usenet newsgroup. The software package, known as ISS or Internet Security Scanner, will interrogate all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. The software was designed as a security tool for system and network administrators. ISS does not attempt to gain access to a system being tested. However, given its wide distribution and ability to scan remote networks, the CERT/CC believes that it is likely ISS will also be used to locate vulnerable hosts for malicious reasons.
While none of the vulnerabilities ISS checks for are new, their aggregation into a widely available automated tool represents a higher level of threat to networked machines. The CERT/CC staff has analyzed the operation of the program and strongly recommends that administrators take this opportunity to re-examine systems for the vulnerabilities described below. Detailed below are available security tools that may assist in the detection and prevention of malicious use of ISS. Finally, common symptoms of an ISS attack are outlined to allow detection of malicious use.
Vulnerabilities probed by ISS
The following vulnerabilities are currently tested for by the ISS tool. Administrators should verify the state of their systems and perform corrective actions as indicated.
|Default Accounts||The accounts "guest" and "bbs", if they exist, should
have non-trivial passwords. If login access to these
accounts is not needed, they should be removed, or
disabled by placing a "*" in the password field and the
string "/bin/false" in the shell field in /etc/passwd.
See the system manual entry for "passwd(1)" for more
information on changing passwords and disabling
For example, the /etc/passwd entry for a disabled guest account should resemble the following:
|lp Account||The account "lp", if it exists, should not allow logins. It should be disabled by placing a "*" in the password field and the string "/bin/false" in the shell field in /etc/passwd.|
Mail aliases for decode and uudecode should be disabled
on UNIX systems. If the file /etc/aliases contains
entries for these programs, they should be removed, or
disabled by placing a "#" at the beginning of the line
and then executing the command "newaliases". Consult
the manual page for "aliases(1)" for more information on
UNIX mail aliases.
A disabled decode alias should appear as follows:
# decode: "|/usr/bin/uudecode"
The sendmail commands "wiz" and "debug" should be
disabled. This may be verified by executing the
% telnet <hostname> 25 220 host Sendmail 5.65 ready at Wed, 29 Sep 93 20:28:46 EDT wiz You wascal wabbit! Wandering wizards won't win! (or 500 Command unrecognized) quit % telnet <hostname> 25 220 host Sendmail 5.65 ready at Wed, 29 Sep 93 20:28:46 EDT debug 500 Command unrecognized quit
If the "wiz" command returns "Please pass, oh mighty wizard", your system is vulnerable to attack. The command should be disabled by adding the following line to the sendmail.cf configuration file containing the string:
For this change to take effect, kill the sendmail process, refreeze the sendmail.cf file, and restart the sendmail process.
If the "debug" command responds with the string "200 Debug set", you should immediately obtain a newer version of sendmail software from your vendor.
Anonymous FTP allows users without accounts to have
restricted access to certain directories on the system.
The availability of anonymous FTP on a given system may
be determined by executing the following commands:
% ftp hostname Connected to hostname. 220 host FTP server ready. Name (localhost:jdoe): anonymous 530 User anonymous unknown. Login failed.
ISS attempts to guess the NIS domainname. The program
will try to grab the password file from ypserv.
See CERT Advisory CA-92.13 for more information regarding SunOS 4.x machines using NIS.
See CERT Advisory CA-93.01 for more information regarding HP machines using NIS.
File systems exported under NFS should be mountable only
by a restricted set of hosts. The UNIX "showmount"
command will display the file systems currently exported
by a given host:
% /usr/etc/showmount -e hostname export list for hostname: /usr hosta:hostb:hostc /usr/local (everyone)
The above output indicates that this NFS server is exporting two partitions: /usr, which can be mounted by hosta, hostb, and hostc; and /usr/local which can be mounted by anyone. In this case, access to the /usr/local partition should be restricted. Consult the system manual entry for "exports(5)" or "NFS(4P)" for more information.
The UNIX rusers command displays information about
accounts currently active on a remote system. This may
provide an attacker with account names or other
information useful in mounting an attack. To check for
the availability of rusers information on a particular
machine, execute the following command:
% rusers -l hostname hostname: RPC: Program not registered
If the above example had instead generated a list of user names and login information, a rusers server is running on the host. The server may be disabled by placing a "#" at the beginning of the appropriate line in the file /etc/inetd.conf and then sending the SIGHUP signal to the inetd process. For example, a disabled rusers entry might appear as follows:
#rusersd/2 dgram rpc/udp wait root /usr/etc/rusersd rusersd
The UNIX remote execution server rexd provides only
minimal authentication and is easily subverted. It
should be disabled by placing a "#" at the beginning of
the rexd line in the file /etc/inetd.conf and then
sending the SIGHUP signal to the inetd process. The
disabled entry should resemble the following:
#rexd/1 stream rpc/tcp wait root /usr/etc/rexd rexd
See CERT Advisory CA-92.05 for more information regarding IBM AIX machines using rexd.
There are several available security tools that may be used to prevent or detect malicious use of ISS. They include the following:
|COPS||The COPS security tool will also detect the vulnerabilities described above. It is available from ftp://info.cert.org/pub/tools/cops/1.04|
Running ISS on your systems will provide you with the
same information an attacker would obtain, allowing you
to correct vulnerabilities before they can be exploited.
Note that the current version of the software is known
to function poorly on some operating systems.
MD5 checksum for the files:
MD5 (iss13.tar.gz) = 1caa02756876d41a659a828dae561a92
|TCP Wrappers||Access to most UNIX network services can be more closely controlled using software known as a TCP wrapper. The wrapper provides additional access control and flexible logging features that may assist in both the prevention and detection of network attacks. This software is available via anonymous FTP from cert.org in the directory pub/tools/tcp_wrappers.|
Detecting an ISS Attack
Given the wide distribution of the ISS tool, CERT feels that remote attacks are likely to occur. Such attacks can cause system warnings to be generated that may prove useful in tracking down the source of the attack. The most probable indicator of an ISS attack is a mail message sent to "postmaster" on a scanned system similar to the following:
From: Mailer-Daemon@hostname (Mail Delivery Subsystem) Subject: Returned mail: Unable to deliver mail Message-Id: <9309291633.AB04591@> To: Postmaster@hostname ----- Transcript of session follows ----- <<< VRFY guest 550 guest... User unknown <<< VRFY decode 550 decode... User unknown <<< VRFY bbs 550 bbs... User unknown <<< VRFY lp 550 lp... User unknown <<< VRFY uudecode 550 uudecode... User unknown <<< wiz 500 Command unrecognized <<< debug 500 Command unrecognized 421 Lost input channel to remote.machine ----- No message was collected -----
According to Eric Allman, the author of sendmail, log information may be displayed differently depending on the particular configuration and version of sendmail being used.
Typically the most probable indicator of such an attack is a mail message sent to "postmaster" for the scanned system. Please note, however, that other possible indications of an ISS attack for other sendmail configurations may appear as shown below.
For sendmail 8.x, you might see output similar to the following:
Apr 8 03:19:17 HOSTNAME sendmail: wwww.xxx.yyy.zzz [123.456.789.0]: VRFY decode Apr 8 03:19:18 HOSTNAME sendmail: wwww.xxx.yyy.zzz [123.456.789.0]: VRFY bbs Apr 8 03:19:18 HOSTNAME sendmail: wwww.xxx.yyy.zzz [123.456.789.0]: VRFY lp Apr 8 03:19:18 HOSTNAME sendmail: wwww.xxx.yyy.zzz [123.456.789.0]: VRFY uudecode Apr 8 03:19:18 HOSTNAME sendmail: "wiz" command from wwww.xxx.yyy.zzz [123.456.789.0] Apr 8 03:19:18 HOSTNAME sendmail: "debug" command from wwww.xxx.yyy.zzz [123.456.789.0]
Other versions may display different messages, for example:
Apr 8 03:19:19 HOSTNAME ftpd: FTP LOGIN REFUSED (ftp not in /etc/passwd) FROM wwww.xxx.yyy.zzz [123.456.789.0], anonymous Apr 8 03:19:19 HOSTNAME ftpd: USER anonymous Apr 8 03:19:19 HOSTNAME ftpd: PASS password Apr 8 03:19:19 HOSTNAME ftpd: reply: 503-Login with USER first. Apr 8 03:19:19 HOSTNAME ftpd: cmd failure - not logged in Apr 8 03:19:19 HOSTNAME ftpd: reply: 530-Please login with USER and PASS. Apr 8 03:19:19 HOSTNAME ftpd: PWD Apr 8 03:19:19 HOSTNAME ftpd: cmd failure - not logged in Apr 8 03:19:19 HOSTNAME ftpd: reply: 530-Please login with USER and PASS. Apr 8 03:19:19 HOSTNAME ftpd: MKD test Apr 8 03:19:19 HOSTNAME ftpd: cmd failure - not logged in Apr 8 03:19:19 HOSTNAME ftpd: reply: 530-Please login with USER and PASS. Apr 8 03:19:19 HOSTNAME ftpd: RMD test Apr 8 03:19:19 HOSTNAME ftpd: QUIT Apr 8 03:19:19 HOSTNAME ftpd: reply: 221-Goodbye.
The CERT Coordination Center would like to thank Steve Weeber from the Department of Energy's CIAC Team for his contribution to this advisory.
Copyright 1993, 1995, 1996 Carnegie Mellon University.
Sep. 19, 1997 Updated Copyright Statement Aug. 30, 1996 Information previously in the README was inserted into the advisory. June 09, 1995 "Available Tools" section - gave pointers to ISS version 3.1 Feb. 02, 1995 "Detecting an ISS Attack" section - added details from the sendmail author about logs