From htk@nwg.nectec.or.th Wed Feb 9 12:13:01 1994 Date: Fri, 5 Nov 1993 23:56:08 +0700 From: trin (Trin Tantsetthi) Received-Date: Fri, 5 Nov 1993 23:56:08 +0700 Message-Id: <9311051656.AA28239@nwg.nectec.or.th> To: thadmin Subject: (fwd) CERT ADVISORY - Sendmail Vulnerability Newsgroups: comp.security.announce Organization: Academic and research support host at NECTEC, Bangkok, THAILAND Path: senior.nectec.or.th!news.stolaf.edu!umn.edu!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!ucbvax!CERT.ORG!cert-advisory-request From: cert-advisory-request@CERT.ORG (CERT Advisory) Newsgroups: comp.security.announce Subject: CERT ADVISORY - Sendmail Vulnerability Message-ID: <9311050250.AA10945@tictac.cert.org> Date: 5 Nov 93 02:47:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: Computer Emergency Response Team : 412-268-7090 Lines: 269 Approved: cert@cert.org ============================================================================= CA-93:16 CERT Advisory November 4, 1993 Sendmail Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center is working on eliminating a vulnerability in sendmail(8). This vulnerability potentially affects all systems running sendmail. CERT is working with the vendor community to address this vulnerability. At this time, there are no known patches available for any vendor implementation that fully address this vulnerability. Until there is complete vendor information, CERT recommends that all implementations of sendmail be considered susceptible. This advisory supersedes the sendmail portion of the CERT advisory (CA-93:15) of October 21, 1993. CERT will continue to work with the vendors and will alert the community when patches become available. Included with this advisory is an appendix describing tips that can be used by system administrators who are concerned about the possible exploitation of this vulnerability at their site. ----------------------------------------------------------------------------- I. Description A vulnerability exists in most versions of sendmail that allows unauthorized remote or local users to execute programs as any system user other than root. This vulnerability affects the final destination sendmail host and can be exploited through an intermediate mail machine. Therefore, all sendmail recipient machines within a domain are potentially vulnerable. II. Impact Anyone (remote or local) can execute programs on the affected hosts as any userid other than root. III. Approaches CERT suggests three possible approaches to this problem. Although these approaches address all known aspects of this vulnerability, they are suggested only until vendor patches for this sendmail vulnerability are available. Familiarity with sendmail and its installation and configuration, is recommended before implementing these modifications. In order to protect your entire site it is necessary to apply the selected approach to *ALL* systems running sendmail at the site, and not just the mail hub. A. Approach 1 This approach involves modifying the sendmail configuration to restrict the sendmail program mailer facility. To restrict sendmail's program mailer facility, obtain and install the sendmail restricted shell program (smrsh 1.2) by Eric Allman (the original author of sendmail), following the directions included with the program. 1. Where to obtain the program Copies of this program may be obtained via anonymous FTP from info.cert.org, in the /pub/tools/smrsh directory, or via anonymous FTP from ftp.uu.net in the /pub/security/smrsh directory. Checksum information: BSD Sum 30114 5 README 25757 2 smrsh.8 46786 5 smrsh.c System V Sum 56478 10 README 42281 4 smrsh.8 65517 9 smrsh.c MD5 Checksum MD5 (README) = fc4cf266288511099e44b664806a5594 MD5 (smrsh.8) = 35aeefba9714f251a3610c7b1714e355 MD5 (smrsh.c) = d4822ce7c273fc8b93c68e39ec67739c 2. Impacts of this approach While this approach allows a site to specify which programs can be run by sendmail (e.g. vacation(1)), attempts to invoke programs that are not included in the allowed set, or attempts using shell meta-characters (see smrsh program listing for a complete set of disallowed characters), will fail, resulting in log output to the syslog(3) facility. Programs that are specified in a site's /etc/aliases file should be considered for inclusion in the allowable program list. Since .forward files allow user-specified programs to be run by sendmail, a survey of the contents of the system's .forward files may be required to prevent failure to deliver user mail. *** WARNING *************************************************** * It is very important that sites *NOT* include interpreter * * programs (e.g. /bin/sh, /bin/csh, /bin/perl, /bin/uudecode, * * /bin/sed, ...) in the list of allowed programs. * *************************************************************** B. Approach 2 Like approach 1, this approach involves modifying the sendmail configuration. However, this approach completely disables the sendmail program mailer facility. This is a drastic, but quick action that can be taken while a site installs one of the other suggestions. Before implementing this approach, save a copy of the current sendmail configuration file. To implement this approach edit the sendmail.cf file: change from: Mprog, P=/bin/sh, F=slFDM, S=10, R=20, A=sh -c $u to: Mprog, P=/bin/false, F=, S=10, R=20, A= Any changes to the sendmail.cf file will require that the sendmail process be restarted to ensure that the new configuration is used. See item 3 in Appendix A for more details. 1. Impacts of this approach Attempts to invoke programs through sendmail will not be successful. C. Approach 3 To the best of our knowledge, Eric Allman's public domain implementation of sendmail, sendmail 8.6.4, does not appear to be susceptible to this vulnerability. A working solution would then be to replace a site's sendmail, with sendmail 8.6.4. 1. Where to obtain the program Copies of this version of sendmail may be obtained via anonymous FTP from ftp.cs.berkeley.edu in the /ucb/sendmail directory. Checksum information: BSD Sum sendmail.8.6.4.base.tar.Z: 07718 428 sendmail.8.6.4.cf.tar.Z: 28004 179 sendmail.8.6.4.misc.tar.Z: 57299 102 sendmail.8.6.4.xdoc.tar.Z: 33954 251 System V Sum 64609 856 sendmail.8.6.4.base.tar.Z 42112 357 sendmail.8.6.4.cf.tar.Z 8101 203 sendmail.8.6.4.misc.tar.Z 50037 502 sendmail.8.6.4.xdoc.tar.Z MD5 Checksum MD5 (sendmail.8.6.4.base.tar.Z) = 59727f2f99b0e47a74d804f7ff654621 MD5 (sendmail.8.6.4.cf.tar.Z) = cb7ab7751fb8b45167758e9485878f6f MD5 (sendmail.8.6.4.misc.tar.Z) = 8eaa6fbe9e9226667f719af0c1bde755 MD5 (sendmail.8.6.4.xdoc.tar.Z) = a9da24e504832f21a3069dc2151870e6 2. Impacts of this workaround Depending upon the currently installed sendmail program, switching to a different sendmail may require significant effort for the system administrator to become familiar with the new program. The site's sendmail configuration file may require considerable modification in order to provide existing functionality. In some cases, the site's sendmail configuration file may be incompatible with the sendmail 8.6.4 configuration file. --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank the members of the following response teams for their assistance in analyzing and testing both the problem and the solutions: SERT, ASSIST, CIAC, and DFN-CERT. CERT would especially like to thank Eric Allman, Matt Blaze, Andy Sherman, Gene Spafford, Tim Seaver, and many others who have provided technical assistance with this effort. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available via anonymous FTP from info.cert.org. Appendix A This appendix describes tips that can be used by system administrators who are concerned about the possible exploitation of this vulnerability at their site. There are two actions that can be taken by system administrators to try to detect the exploitation of this vulnerability at their sites. - Examine all bounced mail to look for unusual occurrences. - Examine syslog files for unusual occurrences of "|" characters In order to do this, sendmail must be configured to direct bounced mail to the postmaster (or other designated person who will examine the bounced mail). Sendmail must also be configured to provide adequate logging. 1) To direct bounced mail to the postmaster, place the following entry in the options part of the general configuration information section of the sendmail.cf file. # Cc my postmaster on error replies I generate OPpostmaster 2) To set sendmail's logging level, place the following entry in the options part of the general configuration information section of the sendmail.cf file. Note that the logging level should be 9 or higher in order to provide adequate logging. # log level OL9 3) Once changes have been made in the sendmail configuration file, it will be necessary to kill all existing sendmail processes, refreeze the configuration file (if needed - see the note below), and restart the sendmail program. Here is an example from SunOS 4.1.2: As root: # /usr/bin/ps -aux | /usr/bin/grep sendmail root 130 0.0 0.0 168 0 ? IW Oct 2 0:10 /usr/lib/sendmail -bd -q # /bin/kill -9 130 (kill the current sendmail process) # /usr/lib/sendmail -bz (create the configuration freeze file) # /usr/lib/sendmail -bd -q30m (run the sendmail daemon) **Note: Some sites do not use frozen configuration files and some do. If your site is using frozen configuration files, there will be a file named sendmail.fc in the same directory as the sendmail configuration file (sendmail.cf). From htk@nwg.nectec.or.th Fri Feb 11 16:47:41 1994 Received-Date: Fri, 4 Feb 1994 11:33:36 +0700 Received: from horton.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AAwbta23536; Thu, 3 Feb 94 23:35:23 -0500 From: strat@uunet.uu.net (Bob Stratton) Received: by horton.UU.NET (5.61/UUNET-mail-leaf) id AAwbta00260; Thu, 3 Feb 94 23:35:21 -0500 Date: Thu, 3 Feb 94 23:35:21 -0500 Message-Id: <9402040435.AAwbta00260@horton.UU.NET> To: support@pipex.net, ops@ticsa.com, admin@chula.ac.th, htk@nwg.nectec.or.th Subject: Urgent - Ongoing network monitoring attacks In-Reply-To: <9402040221.AA18145@delphi.cert.org> References: <9402040221.AA18145@delphi.cert.org> Net Service Provider Correspondence writes: > Hello Guys: > > Because network service providers are the focal point for traffic from > many sites and have a high concentration of routers, they are the > targets of the network monitoring attacks described in the attached > advisory. Some sites have already reported that intruders are > targeting hosts on which router passwords and configuration > information are stored. The intruders have demonstrated familiarity > with router administration, and have been seen to modify router > configurations. > > You may have already received this advisory through another channel, > but we want to ensure that we alert as many network service > providers as possible. > > After you have followed the steps outlined in the advisory, we urge > you to send CERT a summary of your findings. This information will > help us establish the overall extent and impact of this activity. All > site-specific information will be kept for CERT internal use. > > Please complete the following template, and send it to > "netcontact@cert.org". > > > ========================================================================== > > Network service provider name: > > Contact person: > e-mail: > phone: > FAX: > > Have you found any indication of this attack at your site? [yes/no] > > On how many hosts at your site has the network monitoring tool been > found? > > Is the compromised host(s) part of the routing infrastructure? > [yes/no] > > How many host/account/password triplets have been captured? > > Please list hosts for which account information has been captured: > > ========================================================================== > > > Because the scope of this attack is potentially very broad and our > resources are limited, we would appreciate your notifying downstream > sites. > > Thanks for your assistance. > > > > ============================================================================= > CA-94:01 CERT Advisory > February 3, 1994 > Ongoing Network Monitoring Attacks > ----------------------------------------------------------------------------- > > In the past week, CERT has observed a dramatic increase in reports of > intruders monitoring network traffic. Systems of some service > providers have been compromised, and all systems that offer remote > access through rlogin, telnet, and FTP are at risk. Intruders have > already captured access information for tens of thousands of systems > across the Internet. > > The current attacks involve a network monitoring tool that uses the > promiscuous mode of a specific network interface, /dev/nit, to capture > host and user authentication information on all newly opened FTP, > telnet, and rlogin sessions. > > In the short-term, CERT recommends that all users on sites that offer > remote access change passwords on any network-accessed account. In > addition, all sites having systems that support the /dev/nit interface > should disable this feature if it is not used and attempt to prevent > unauthorized access if the feature is necessary. A procedure for > accomplishing this is described in Section III.B.2 below. Systems > known to support the interface are SunOS 4.x (Sun3 and Sun4 > architectures) and Solbourne systems; there may be others. Sun Solaris > systems do not support the /dev/nit interface. If you have a system > other than Sun or Solbourne, contact your vendor to find if this > interface is supported. > > While the current attack is specific to /dev/nit, the short-term > workaround does not constitute a solution. The best long-term > solution currently available for this attack is to reduce or eliminate > the transmission of reusable passwords in clear-text over the network. > > > ----------------------------------------------------------------------------- > > I. Description > > Root-compromised systems that support a promiscuous network > interface are being used by intruders to collect host and user > authentication information visible on the network. > > The intruders first penetrate a system and gain root access > through an unpatched vulnerability (solutions and workarounds for > these vulnerabilities have been described in previous CERT > advisories, which are available anonymous FTP from > info.cert.org). > > The intruders then run a network monitoring tool that captures up > to the first 128 keystrokes of all newly opened FTP, telnet, and > rlogin sessions visible within the compromised system's domain. > These keystrokes usually contain host, account, and password > information for user accounts on other systems; the intruders log > these for later retrieval. The intruders typically install > Trojan horse programs to support subsequent access to the > compromised system and to hide their network monitoring process. > > II. Impact > > All connected network sites that use the network to access remote > systems are at risk from this attack. > > All user account and password information derived from FTP, > telnet, and rlogin sessions and passing through the same network > as the compromised host could be disclosed. > > > III. Approach > > There are three steps in CERT's recommended approach to the > problem: > > - Detect if the network monitoring tool is running on any of your > hosts that support a promiscuous network interface. > > - Protect against this attack either by disabling the network > interface for those systems that do not use this feature or by > attempting to prevent unauthorized use of the feature on systems > where this interface is necessary. > > - Scope the extent of the attack and recover in the event that > the network monitoring tool is discovered. > > > A. Detection > > The network monitoring tool can be run under a variety of > process names and log to a variety of filenames. Thus, the > best method for detecting the tool is to look for 1) Trojan > horse programs commonly used in conjunction with this attack, > 2) any suspect processes running on the system, and 3) the > unauthorized use of /dev/nit. > > 1) Trojan horse programs: > > The intruders have been found to replace one or more of the > following programs with a Trojan horse version in conjunction > with this attack: > > /usr/etc/in.telnetd > and /bin/login - Used to provide back-door access for the > intruders to retrieve information > /bin/ps - Used to disguise the network monitoring process > > Because the intruders install Trojan horse variations of > standard UNIX commands, CERT recommends not using other > commands such as the standard UNIX sum(1) or cmp(1) commands > to locate the Trojan horse programs on the system until these > programs can be restored from distribution media, run from > read-only media (such as a mounted CD-ROM), or verified using > cryptographic checksum information. > > In addition to the possibility of having the checksum > programs replaced by the intruders, the Trojan horse programs > mentioned above may have been engineered to produce the same > standard checksum and timestamp as the legitimate version. > Because of this, the standard UNIX sum(1) command and the > timestamps associated with the programs are not sufficient to > determine whether the programs have been replaced. > > CERT recommends that you use both the /usr/5bin/sum and > /bin/sum commands to compare against the distribution media > and assure that the programs have not been replaced. The use > of cmp(1), MD5, Tripwire (only if the baseline checksums were > created on a distribution system), and other cryptographic > checksum tools are also sufficient to detect these Trojan > horse programs, provided these programs were not available > for modification by the intruder. If the distribution is > available on CD-ROM or other read-only device, it may be > possible to compare against these volumes or run programs off > these media. > > 2) Suspect processes: > > Although the name of the network monitoring tool can vary > from attack to attack, it is possible to detect a suspect > process running as root using ps(1) or other process-listing > commands. Until the ps(1) command has been verified against > distribution media, it should not be relied upon--a Trojan > horse version is being used by the intruders to hide the > monitoring process. Some process names that have been > observed are sendmail, es, and in.netd. The arguments to the > process also provide an indication of where the log file is > located. If the "-F" flag is set on the process, the > filename following indicates the location of the log file > used for the collection of authentication information for > later retrieval by the intruders. > > 3) Unauthorized use of /dev/nit: > > If the network monitoring tool is currently running on your > system, it is possible to detect this by checking for > unauthorized use of the /dev/nit interface. CERT has created > a minimal tool for this purpose. The source code for this > tool is available via anonymous FTP on info.cert.org in the > /pub/tools/cpm directory or on ftp.uu.net in the > /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum > information is: > > Filename Standard UNIX Sum System V Sum > -------------- ----------------- ------------ > cpm.1.0.tar.Z: 11097 6 24453 12 > > MD5 Checksum > MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 > > This archive contains a readme file, also included as > Appendix C of this advisory, containing instructions on > installing and using this detection tool. > > B. Prevention > > There are two actions that are effective in preventing this > attack. A long-term solution requires eliminating > transmission of clear-text passwords on the network. For > this specific attack, however, a short-term workaround > exists. Both of these are described below. > > 1) Long-term prevention: > > CERT recognizes that the only effective long-term solution to > prevent these attacks is by not transmitting reusable > clear-text passwords on the network. CERT has collected some > information on relevant technologies. This information is > included as Appendix B in this advisory. Note: These > solutions will not protect against transient or remote access > transmission of clear-text passwords through the network. > > Until everyone connected to your network is using the above > technologies, your policy should allow only authorized users > and programs access to promiscuous network interfaces. The > tool described in Section III.A.3 above may be helpful in > verifying this restricted access. > > 2) Short-term workaround: > > Regardless of whether the network monitoring software is > detected on your system, CERT recommends that ALL SITES take > action to prevent unauthorized network monitoring on their > systems. You can do this either by removing the interface, if > it is not used on the system or by attempting to prevent the > misuse of this interface. > > For systems other than Sun and Solbourne, contact your vendor > to find out if promiscuous mode network access is supported > and, if so, what is the recommended method to disable or > monitor this feature. > > For SunOS 4.x and Solbourne systems, the promiscuous > interface to the network can be eliminated by removing the > /dev/nit capability from the kernel. The procedure for doing > so is outlined below (see your system manuals for more > details). Once the procedure is complete, you may remove the > device file /dev/nit since it is no longer functional. > > Procedure for removing /dev/nit from the kernel: > > 1. Become root on the system. > > 2. Apply "method 1" as outlined in the System and Network > Administration manual, in the section, "Sun System > Administration Procedures," Chapter 9, "Reconfiguring the > System Kernel." Excerpts from the method are reproduced > below: > > # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf > # cp CONFIG_FILE SYS_NAME > > [Note that at this step, you should replace the CONFIG_FILE > with your system specific configuration file if one exists.] > > # chmod +w SYS_NAME > # vi SYS_NAME > > # > # The following are for streams NIT support. NIT is used by > # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, > # NIT is almost always needed on a server and almost never > # needed on a diskless client. > # > pseudo-device snit # streams NIT > pseudo-device pf # packet filter > pseudo-device nbuf # NIT buffering module > > [Comment out the preceding three lines; save and exit the > editor before proceeding.] > > # config SYS_NAME > # cd ../SYS_NAME > # make > > # mv /vmunix /vmunix.old > # cp vmunix /vmunix > > # /etc/halt > > b > > [This step will reboot the system with the new kernel.] > > [NOTE that even after the new kernel is installed, you need > to take care to ensure that the previous vmunix.old , or > other kernel, is not used to reboot the system.] > > > C. Scope and recovery > > If you detect the network monitoring software at your site, > CERT recommends following three steps to successfully > determine the scope of the problem and to recover from this > attack. > > 1. Restore the system that was subjected to the network > monitoring software. > > The systems on which the network monitoring and/or Trojan > horse programs are found have been compromised at the root > level; your system configuration may have been altered. See > Appendix A of this advisory for help with recovery. > > 2. Consider changing router, server, and privileged account > passwords due to the wide-spread nature of these attacks. > > Since this threat involves monitoring remote connections, > take care to change these passwords using some mechanism > other than remote telnet, rlogin, or FTP access. > > 3. Urge users to change passwords on local and remote > accounts. > > Users who access accounts using telnet, rlogin, or FTP either > to or from systems within the compromised domain should > change their passwords after the intruder's network monitor > has been disabled. > > 4. Notify remote sites connected from or through the local > domain of the network compromise. > > Encourage the remote sites to check their systems for > unauthorized activity. Be aware that if your site routes > network traffic between external domains, both of these > domains may have been compromised by the network monitoring > software. > > > --------------------------------------------------------------------------- > The CERT Coordination Center thanks the members of the FIRST community > as well as the many technical experts around the Internet who > participated in creating this advisory. Special thanks to Eugene > Spafford of Purdue University for his contributions. > --------------------------------------------------------------------------- > > If you believe that your system has been compromised, contact the CERT > Coordination Center or your representative in Forum of Incident > Response and Security Teams (FIRST). > > Internet E-mail: cert@cert.org > Telephone: 412-268-7090 (24-hour hotline) > CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), > and are on call for emergencies during other hours. > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > Past advisories, information about FIRST representatives, and other > information related to computer security are available for anonymous > FTP from info.cert.org. > > --------------------------------------------------------------------------- > Appendix A: > RECOVERING FROM A UNIX ROOT COMPROMISE > > A. Immediate recovery technique > > 1) Disconnect from the network or operate the system in > single- user mode during the recovery. This will keep users > and intruders from accessing the system. > > 2) Verify system binaries and configuration files against the > vendor's media (do not rely on timestamp information to > provide an indication of modification). Do not trust any > verification tool such as cmp(1) located on the compromised > system as it, too, may have been modified by the intruder. > In addition, do not trust the results of the standard UNIX > sum(1) program as we have seen intruders modify system > files in such a way that the checksums remain the same. > Replace any modified files from the vendor's media, not > from backups. > > -- or -- > > Reload your system from the vendor's media. > > 3) Search the system for new or modified setuid root files. > > find / -user root -perm -4000 -print > > If you are using NFS or AFS file systems, use ncheck to > search the local file systems. > > ncheck -s /dev/sd0a > > 4) Change the password on all accounts. > > 5) Don't trust your backups for reloading any file used by > root. You do not want to re-introduce files altered by an > intruder. > > > B. Improving the security of your system > > 1) CERT Security Checklist > Using the checklist will help you identify security > weaknesses or modifications to your systems. The CERT > Security Checklist is based on information gained from > computer security incidents reported to CERT. It is > available via anonymous FTP from info.cert.org in the file > pub/tech_tips/security_info. > > 2) Security Tools > Use security tools such as COPS and Tripwire to check for > security configuration weaknesses and for modifications > made by intruders. We suggest storing these security > tools, their configuration files, and databases offline or > encrypted. TCP daemon wrapper programs provide additional > logging and access control. These tools are available via > anonymous FTP from info.cert.org in the pub/tools > directory. > > 3) CERT Advisories > Review past CERT advisories (both vendor-specific and > generic) and install all appropriate patches or workarounds > as described in the advisories. CERT advisories and other > security-related information are available via anonymous > FTP from info.cert.org in the pub/cert_advisories > directory. > > To join the CERT Advisory mailing list, send a request to: > > cert-advisory-request@cert.org > > Please include contact information, including a telephone number. > > > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > Copyright (c) Carnegie Mellon University 1994 > > > > > --------------------------------------------------------------------------- > Appendix B: > ONE-TIME PASSWORDS > > Given today's networked environments, CERT recommends that sites > concerned about the security and integrity of their systems and > networks consider moving away from standard, reusable passwords. CERT > has seen many incidents involving Trojan network programs (e.g., > telnet and rlogin) and network packet sniffing programs. These > programs capture clear-text hostname, account name, password triplets. > Intruders can use the captured information for subsequent access to > those hosts and accounts. This is possible because 1) the password is > used over and over (hence the term "reusable"), and 2) the password > passes across the network in clear text. > > Several authentication techniques have been developed that address > this problem. Among these techniques are challenge-response > technologies that provide passwords that are only used once (commonly > called one-time passwords). This document provides a list of sources > for products that provide this capability. The decision to use a > product is the responsibility of each organization, and each > organization should perform its own evaluation and selection. > > I. Public Domain packages > > S/KEY(TM) > The S/KEY package is publicly available (no fee) via > anonymous FTP from: > > thumper.bellcore.com /pub/nmh directory > > There are three subdirectories: > > skey UNIX code and documents on S/KEY. > Includes the change needed to login, > and stand-alone commands (such as "key"), > that computes the one-time password for > the user, given the secret password and > the S/KEY command. > > dos DOS or DOS/WINDOWS S/KEY programs. Includes > DOS version of "key" and "termkey" which is > a TSR program. > > mac One-time password calculation utility for > the Mac. > > > II. Commercial Products > > Secure Net Key (SNK) (Do-it-yourself project) > Digital Pathways, Inc. > 201 Ravendale Dr. > Mountainview, Ca. 94043-5216 > USA > Phone: 415-964-0707 > Fax: (415) 961-7487 > > Products: > handheld authentication calculators (SNK004) > serial line auth interruptors (guardian) > > Note: Secure Net Key (SNK) is des-based, and therefore restricted > from US export. > > Secure ID (complete turnkey systems) > Security Dynamics > One Alewife Center > Cambridge, MA 02140-2312 > USA > Phone: 617-547-7820 > Fax: (617) 354-8836 > > Products: > SecurID changing number authentication card > ACE server software > > SecureID is time-synchronized using a 'proprietary' number > generation algorithm > > WatchWord and WatchWord II > Racal-Guardata > 480 Spring Park Place > Herndon, VA 22070 > 703-471-0892 > 1-800-521-6261 ext 217 > > Products: > Watchword authentication calculator > Encrypting modems > > Alpha-numeric keypad, digital signature capability > > SafeWord > Enigma Logic, Inc. > 2151 Salvio #301 > Concord, CA 94520 > 510-827-5707 > Fax: (510)827-2593 > > Products: > DES Silver card authentication calculator > SafeWord Multisync card authentication calculator > > Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as > other OS versions. Supports one-time passwords and super > smartcards from several vendors. > > > > > > --------------------------------------------------------------------------- > Appendix C: > cpm 1.0 README FILE > > > cpm - check for network interfaces in promiscuous mode. > > Copyright (c) Carnegie Mellon University 1994 > Thursday Feb 3 1994 > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > > This program is free software; you can distribute it and/or modify > it as long as you retain the Carnegie Mellon copyright statement. > > It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. > > This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED > WARRANTY of merchantability or fitness for a particular purpose. > > This package contains: > README > MANIFEST > cpm.1 > cpm.c > > To create cpm under SunOS, type: > % cc -Bstatic -o cpm cpm.c > > On machines that support dynamic loading, such as Sun's, CERT recommends > that programs be statically linked so that this feature is disabled. > > CERT recommends that after you install cpm in your favorite directory, > you take measures to ensure the integrity of the program by noting > the size and checksums of the source code and resulting binary. > > > The following is an example of the output of cpm and its exit status. > > Running cpm on a machine where both the le0 and le2 interfaces are > in promiscuous mode, under csh(1): > > % cpm > le0 > le2 > % echo $status > 2 > % > > Running cpm on a machine where no interfaces are in promiscuous > mode, under csh(1): > > % cpm > % echo $status > 0 > % > > > From htk@nwg.nectec.or.th Sat Feb 12 23:45:24 1994 Received-Date: Fri, 4 Feb 1994 11:33:36 +0700 Received: from horton.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AAwbta23536; Thu, 3 Feb 94 23:35:23 -0500 From: strat@uunet.uu.net (Bob Stratton) Received: by horton.UU.NET (5.61/UUNET-mail-leaf) id AAwbta00260; Thu, 3 Feb 94 23:35:21 -0500 Date: Thu, 3 Feb 94 23:35:21 -0500 Message-Id: <9402040435.AAwbta00260@horton.UU.NET> To: support@pipex.net, ops@ticsa.com, admin@chula.ac.th, htk@nwg.nectec.or.th Subject: Urgent - Ongoing network monitoring attacks In-Reply-To: <9402040221.AA18145@delphi.cert.org> References: <9402040221.AA18145@delphi.cert.org> Net Service Provider Correspondence writes: > Hello Guys: > > Because network service providers are the focal point for traffic from > many sites and have a high concentration of routers, they are the > targets of the network monitoring attacks described in the attached > advisory. Some sites have already reported that intruders are > targeting hosts on which router passwords and configuration > information are stored. The intruders have demonstrated familiarity > with router administration, and have been seen to modify router > configurations. > > You may have already received this advisory through another channel, > but we want to ensure that we alert as many network service > providers as possible. > > After you have followed the steps outlined in the advisory, we urge > you to send CERT a summary of your findings. This information will > help us establish the overall extent and impact of this activity. All > site-specific information will be kept for CERT internal use. > > Please complete the following template, and send it to > "netcontact@cert.org". > > > ========================================================================== > > Network service provider name: > > Contact person: > e-mail: > phone: > FAX: > > Have you found any indication of this attack at your site? [yes/no] > > On how many hosts at your site has the network monitoring tool been > found? > > Is the compromised host(s) part of the routing infrastructure? > [yes/no] > > How many host/account/password triplets have been captured? > > Please list hosts for which account information has been captured: > > ========================================================================== > > > Because the scope of this attack is potentially very broad and our > resources are limited, we would appreciate your notifying downstream > sites. > > Thanks for your assistance. > > > > ============================================================================= > CA-94:01 CERT Advisory > February 3, 1994 > Ongoing Network Monitoring Attacks > ----------------------------------------------------------------------------- > > In the past week, CERT has observed a dramatic increase in reports of > intruders monitoring network traffic. Systems of some service > providers have been compromised, and all systems that offer remote > access through rlogin, telnet, and FTP are at risk. Intruders have > already captured access information for tens of thousands of systems > across the Internet. > > The current attacks involve a network monitoring tool that uses the > promiscuous mode of a specific network interface, /dev/nit, to capture > host and user authentication information on all newly opened FTP, > telnet, and rlogin sessions. > > In the short-term, CERT recommends that all users on sites that offer > remote access change passwords on any network-accessed account. In > addition, all sites having systems that support the /dev/nit interface > should disable this feature if it is not used and attempt to prevent > unauthorized access if the feature is necessary. A procedure for > accomplishing this is described in Section III.B.2 below. Systems > known to support the interface are SunOS 4.x (Sun3 and Sun4 > architectures) and Solbourne systems; there may be others. Sun Solaris > systems do not support the /dev/nit interface. If you have a system > other than Sun or Solbourne, contact your vendor to find if this > interface is supported. > > While the current attack is specific to /dev/nit, the short-term > workaround does not constitute a solution. The best long-term > solution currently available for this attack is to reduce or eliminate > the transmission of reusable passwords in clear-text over the network. > > > ----------------------------------------------------------------------------- > > I. Description > > Root-compromised systems that support a promiscuous network > interface are being used by intruders to collect host and user > authentication information visible on the network. > > The intruders first penetrate a system and gain root access > through an unpatched vulnerability (solutions and workarounds for > these vulnerabilities have been described in previous CERT > advisories, which are available anonymous FTP from > info.cert.org). > > The intruders then run a network monitoring tool that captures up > to the first 128 keystrokes of all newly opened FTP, telnet, and > rlogin sessions visible within the compromised system's domain. > These keystrokes usually contain host, account, and password > information for user accounts on other systems; the intruders log > these for later retrieval. The intruders typically install > Trojan horse programs to support subsequent access to the > compromised system and to hide their network monitoring process. > > II. Impact > > All connected network sites that use the network to access remote > systems are at risk from this attack. > > All user account and password information derived from FTP, > telnet, and rlogin sessions and passing through the same network > as the compromised host could be disclosed. > > > III. Approach > > There are three steps in CERT's recommended approach to the > problem: > > - Detect if the network monitoring tool is running on any of your > hosts that support a promiscuous network interface. > > - Protect against this attack either by disabling the network > interface for those systems that do not use this feature or by > attempting to prevent unauthorized use of the feature on systems > where this interface is necessary. > > - Scope the extent of the attack and recover in the event that > the network monitoring tool is discovered. > > > A. Detection > > The network monitoring tool can be run under a variety of > process names and log to a variety of filenames. Thus, the > best method for detecting the tool is to look for 1) Trojan > horse programs commonly used in conjunction with this attack, > 2) any suspect processes running on the system, and 3) the > unauthorized use of /dev/nit. > > 1) Trojan horse programs: > > The intruders have been found to replace one or more of the > following programs with a Trojan horse version in conjunction > with this attack: > > /usr/etc/in.telnetd > and /bin/login - Used to provide back-door access for the > intruders to retrieve information > /bin/ps - Used to disguise the network monitoring process > > Because the intruders install Trojan horse variations of > standard UNIX commands, CERT recommends not using other > commands such as the standard UNIX sum(1) or cmp(1) commands > to locate the Trojan horse programs on the system until these > programs can be restored from distribution media, run from > read-only media (such as a mounted CD-ROM), or verified using > cryptographic checksum information. > > In addition to the possibility of having the checksum > programs replaced by the intruders, the Trojan horse programs > mentioned above may have been engineered to produce the same > standard checksum and timestamp as the legitimate version. > Because of this, the standard UNIX sum(1) command and the > timestamps associated with the programs are not sufficient to > determine whether the programs have been replaced. > > CERT recommends that you use both the /usr/5bin/sum and > /bin/sum commands to compare against the distribution media > and assure that the programs have not been replaced. The use > of cmp(1), MD5, Tripwire (only if the baseline checksums were > created on a distribution system), and other cryptographic > checksum tools are also sufficient to detect these Trojan > horse programs, provided these programs were not available > for modification by the intruder. If the distribution is > available on CD-ROM or other read-only device, it may be > possible to compare against these volumes or run programs off > these media. > > 2) Suspect processes: > > Although the name of the network monitoring tool can vary > from attack to attack, it is possible to detect a suspect > process running as root using ps(1) or other process-listing > commands. Until the ps(1) command has been verified against > distribution media, it should not be relied upon--a Trojan > horse version is being used by the intruders to hide the > monitoring process. Some process names that have been > observed are sendmail, es, and in.netd. The arguments to the > process also provide an indication of where the log file is > located. If the "-F" flag is set on the process, the > filename following indicates the location of the log file > used for the collection of authentication information for > later retrieval by the intruders. > > 3) Unauthorized use of /dev/nit: > > If the network monitoring tool is currently running on your > system, it is possible to detect this by checking for > unauthorized use of the /dev/nit interface. CERT has created > a minimal tool for this purpose. The source code for this > tool is available via anonymous FTP on info.cert.org in the > /pub/tools/cpm directory or on ftp.uu.net in the > /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum > information is: > > Filename Standard UNIX Sum System V Sum > -------------- ----------------- ------------ > cpm.1.0.tar.Z: 11097 6 24453 12 > > MD5 Checksum > MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 > > This archive contains a readme file, also included as > Appendix C of this advisory, containing instructions on > installing and using this detection tool. > > B. Prevention > > There are two actions that are effective in preventing this > attack. A long-term solution requires eliminating > transmission of clear-text passwords on the network. For > this specific attack, however, a short-term workaround > exists. Both of these are described below. > > 1) Long-term prevention: > > CERT recognizes that the only effective long-term solution to > prevent these attacks is by not transmitting reusable > clear-text passwords on the network. CERT has collected some > information on relevant technologies. This information is > included as Appendix B in this advisory. Note: These > solutions will not protect against transient or remote access > transmission of clear-text passwords through the network. > > Until everyone connected to your network is using the above > technologies, your policy should allow only authorized users > and programs access to promiscuous network interfaces. The > tool described in Section III.A.3 above may be helpful in > verifying this restricted access. > > 2) Short-term workaround: > > Regardless of whether the network monitoring software is > detected on your system, CERT recommends that ALL SITES take > action to prevent unauthorized network monitoring on their > systems. You can do this either by removing the interface, if > it is not used on the system or by attempting to prevent the > misuse of this interface. > > For systems other than Sun and Solbourne, contact your vendor > to find out if promiscuous mode network access is supported > and, if so, what is the recommended method to disable or > monitor this feature. > > For SunOS 4.x and Solbourne systems, the promiscuous > interface to the network can be eliminated by removing the > /dev/nit capability from the kernel. The procedure for doing > so is outlined below (see your system manuals for more > details). Once the procedure is complete, you may remove the > device file /dev/nit since it is no longer functional. > > Procedure for removing /dev/nit from the kernel: > > 1. Become root on the system. > > 2. Apply "method 1" as outlined in the System and Network > Administration manual, in the section, "Sun System > Administration Procedures," Chapter 9, "Reconfiguring the > System Kernel." Excerpts from the method are reproduced > below: > > # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf > # cp CONFIG_FILE SYS_NAME > > [Note that at this step, you should replace the CONFIG_FILE > with your system specific configuration file if one exists.] > > # chmod +w SYS_NAME > # vi SYS_NAME > > # > # The following are for streams NIT support. NIT is used by > # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, > # NIT is almost always needed on a server and almost never > # needed on a diskless client. > # > pseudo-device snit # streams NIT > pseudo-device pf # packet filter > pseudo-device nbuf # NIT buffering module > > [Comment out the preceding three lines; save and exit the > editor before proceeding.] > > # config SYS_NAME > # cd ../SYS_NAME > # make > > # mv /vmunix /vmunix.old > # cp vmunix /vmunix > > # /etc/halt > > b > > [This step will reboot the system with the new kernel.] > > [NOTE that even after the new kernel is installed, you need > to take care to ensure that the previous vmunix.old , or > other kernel, is not used to reboot the system.] > > > C. Scope and recovery > > If you detect the network monitoring software at your site, > CERT recommends following three steps to successfully > determine the scope of the problem and to recover from this > attack. > > 1. Restore the system that was subjected to the network > monitoring software. > > The systems on which the network monitoring and/or Trojan > horse programs are found have been compromised at the root > level; your system configuration may have been altered. See > Appendix A of this advisory for help with recovery. > > 2. Consider changing router, server, and privileged account > passwords due to the wide-spread nature of these attacks. > > Since this threat involves monitoring remote connections, > take care to change these passwords using some mechanism > other than remote telnet, rlogin, or FTP access. > > 3. Urge users to change passwords on local and remote > accounts. > > Users who access accounts using telnet, rlogin, or FTP either > to or from systems within the compromised domain should > change their passwords after the intruder's network monitor > has been disabled. > > 4. Notify remote sites connected from or through the local > domain of the network compromise. > > Encourage the remote sites to check their systems for > unauthorized activity. Be aware that if your site routes > network traffic between external domains, both of these > domains may have been compromised by the network monitoring > software. > > > --------------------------------------------------------------------------- > The CERT Coordination Center thanks the members of the FIRST community > as well as the many technical experts around the Internet who > participated in creating this advisory. Special thanks to Eugene > Spafford of Purdue University for his contributions. > --------------------------------------------------------------------------- > > If you believe that your system has been compromised, contact the CERT > Coordination Center or your representative in Forum of Incident > Response and Security Teams (FIRST). > > Internet E-mail: cert@cert.org > Telephone: 412-268-7090 (24-hour hotline) > CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), > and are on call for emergencies during other hours. > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > Past advisories, information about FIRST representatives, and other > information related to computer security are available for anonymous > FTP from info.cert.org. > > --------------------------------------------------------------------------- > Appendix A: > RECOVERING FROM A UNIX ROOT COMPROMISE > > A. Immediate recovery technique > > 1) Disconnect from the network or operate the system in > single- user mode during the recovery. This will keep users > and intruders from accessing the system. > > 2) Verify system binaries and configuration files against the > vendor's media (do not rely on timestamp information to > provide an indication of modification). Do not trust any > verification tool such as cmp(1) located on the compromised > system as it, too, may have been modified by the intruder. > In addition, do not trust the results of the standard UNIX > sum(1) program as we have seen intruders modify system > files in such a way that the checksums remain the same. > Replace any modified files from the vendor's media, not > from backups. > > -- or -- > > Reload your system from the vendor's media. > > 3) Search the system for new or modified setuid root files. > > find / -user root -perm -4000 -print > > If you are using NFS or AFS file systems, use ncheck to > search the local file systems. > > ncheck -s /dev/sd0a > > 4) Change the password on all accounts. > > 5) Don't trust your backups for reloading any file used by > root. You do not want to re-introduce files altered by an > intruder. > > > B. Improving the security of your system > > 1) CERT Security Checklist > Using the checklist will help you identify security > weaknesses or modifications to your systems. The CERT > Security Checklist is based on information gained from > computer security incidents reported to CERT. It is > available via anonymous FTP from info.cert.org in the file > pub/tech_tips/security_info. > > 2) Security Tools > Use security tools such as COPS and Tripwire to check for > security configuration weaknesses and for modifications > made by intruders. We suggest storing these security > tools, their configuration files, and databases offline or > encrypted. TCP daemon wrapper programs provide additional > logging and access control. These tools are available via > anonymous FTP from info.cert.org in the pub/tools > directory. > > 3) CERT Advisories > Review past CERT advisories (both vendor-specific and > generic) and install all appropriate patches or workarounds > as described in the advisories. CERT advisories and other > security-related information are available via anonymous > FTP from info.cert.org in the pub/cert_advisories > directory. > > To join the CERT Advisory mailing list, send a request to: > > cert-advisory-request@cert.org > > Please include contact information, including a telephone number. > > > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > Copyright (c) Carnegie Mellon University 1994 > > > > > --------------------------------------------------------------------------- > Appendix B: > ONE-TIME PASSWORDS > > Given today's networked environments, CERT recommends that sites > concerned about the security and integrity of their systems and > networks consider moving away from standard, reusable passwords. CERT > has seen many incidents involving Trojan network programs (e.g., > telnet and rlogin) and network packet sniffing programs. These > programs capture clear-text hostname, account name, password triplets. > Intruders can use the captured information for subsequent access to > those hosts and accounts. This is possible because 1) the password is > used over and over (hence the term "reusable"), and 2) the password > passes across the network in clear text. > > Several authentication techniques have been developed that address > this problem. Among these techniques are challenge-response > technologies that provide passwords that are only used once (commonly > called one-time passwords). This document provides a list of sources > for products that provide this capability. The decision to use a > product is the responsibility of each organization, and each > organization should perform its own evaluation and selection. > > I. Public Domain packages > > S/KEY(TM) > The S/KEY package is publicly available (no fee) via > anonymous FTP from: > > thumper.bellcore.com /pub/nmh directory > > There are three subdirectories: > > skey UNIX code and documents on S/KEY. > Includes the change needed to login, > and stand-alone commands (such as "key"), > that computes the one-time password for > the user, given the secret password and > the S/KEY command. > > dos DOS or DOS/WINDOWS S/KEY programs. Includes > DOS version of "key" and "termkey" which is > a TSR program. > > mac One-time password calculation utility for > the Mac. > > > II. Commercial Products > > Secure Net Key (SNK) (Do-it-yourself project) > Digital Pathways, Inc. > 201 Ravendale Dr. > Mountainview, Ca. 94043-5216 > USA > Phone: 415-964-0707 > Fax: (415) 961-7487 > > Products: > handheld authentication calculators (SNK004) > serial line auth interruptors (guardian) > > Note: Secure Net Key (SNK) is des-based, and therefore restricted > from US export. > > Secure ID (complete turnkey systems) > Security Dynamics > One Alewife Center > Cambridge, MA 02140-2312 > USA > Phone: 617-547-7820 > Fax: (617) 354-8836 > > Products: > SecurID changing number authentication card > ACE server software > > SecureID is time-synchronized using a 'proprietary' number > generation algorithm > > WatchWord and WatchWord II > Racal-Guardata > 480 Spring Park Place > Herndon, VA 22070 > 703-471-0892 > 1-800-521-6261 ext 217 > > Products: > Watchword authentication calculator > Encrypting modems > > Alpha-numeric keypad, digital signature capability > > SafeWord > Enigma Logic, Inc. > 2151 Salvio #301 > Concord, CA 94520 > 510-827-5707 > Fax: (510)827-2593 > > Products: > DES Silver card authentication calculator > SafeWord Multisync card authentication calculator > > Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as > other OS versions. Supports one-time passwords and super > smartcards from several vendors. > > > > > > --------------------------------------------------------------------------- > Appendix C: > cpm 1.0 README FILE > > > cpm - check for network interfaces in promiscuous mode. > > Copyright (c) Carnegie Mellon University 1994 > Thursday Feb 3 1994 > > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > > > This program is free software; you can distribute it and/or modify > it as long as you retain the Carnegie Mellon copyright statement. > > It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. > > This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED > WARRANTY of merchantability or fitness for a particular purpose. > > This package contains: > README > MANIFEST > cpm.1 > cpm.c > > To create cpm under SunOS, type: > % cc -Bstatic -o cpm cpm.c > > On machines that support dynamic loading, such as Sun's, CERT recommends > that programs be statically linked so that this feature is disabled. > > CERT recommends that after you install cpm in your favorite directory, > you take measures to ensure the integrity of the program by noting > the size and checksums of the source code and resulting binary. > > > The following is an example of the output of cpm and its exit status. > > Running cpm on a machine where both the le0 and le2 interfaces are > in promiscuous mode, under csh(1): > > % cpm > le0 > le2 > % echo $status > 2 > % > > Running cpm on a machine where no interfaces are in promiscuous > mode, under csh(1): > > % cpm > % echo $status > 0 > % > > > From htk@nwg.nectec.or.th Sat Feb 12 23:46:08 1994 Date: Fri, 4 Feb 1994 22:14:18 +0700 From: trin (Trin Tantsetthi) Received-Date: Fri, 4 Feb 1994 22:14:18 +0700 Message-Id: <9402041514.AA37198@nwg.nectec.or.th> To: thadmin Subject: (fwd) CERT Advisory - Ongoing Network Monitoring Attacks Newsgroups: comp.security.announce Organization: Academic and research support host at NECTEC, Bangkok, THAILAND Path: senior.nectec.or.th!news.stolaf.edu!msc.edu!apctrc!paperboy.amoco.com!howland.reston.ans.net!agate!ucbvax!CERT.ORG!cert-advisory-request From: cert-advisory-request@CERT.ORG (CERT Advisory) Newsgroups: comp.security.announce Subject: CERT Advisory - Ongoing Network Monitoring Attacks Message-ID: <9402040216.AA02516@tictac.cert.org> Date: 4 Feb 94 02:14:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: Computer Emergency Response Team : 412-268-7090 Lines: 592 Approved: cert@cert.org ============================================================================= CA-94:01 CERT Advisory February 3, 1994 Ongoing Network Monitoring Attacks ----------------------------------------------------------------------------- In the past week, CERT has observed a dramatic increase in reports of intruders monitoring network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through rlogin, telnet, and FTP are at risk. Intruders have already captured access information for tens of thousands of systems across the Internet. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, /dev/nit, to capture host and user authentication information on all newly opened FTP, telnet, and rlogin sessions. In the short-term, CERT recommends that all users on sites that offer remote access change passwords on any network-accessed account. In addition, all sites having systems that support the /dev/nit interface should disable this feature if it is not used and attempt to prevent unauthorized access if the feature is necessary. A procedure for accomplishing this is described in Section III.B.2 below. Systems known to support the interface are SunOS 4.x (Sun3 and Sun4 architectures) and Solbourne systems; there may be others. Sun Solaris systems do not support the /dev/nit interface. If you have a system other than Sun or Solbourne, contact your vendor to find if this interface is supported. While the current attack is specific to /dev/nit, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of reusable passwords in clear-text over the network. ----------------------------------------------------------------------------- I. Description Root-compromised systems that support a promiscuous network interface are being used by intruders to collect host and user authentication information visible on the network. The intruders first penetrate a system and gain root access through an unpatched vulnerability (solutions and workarounds for these vulnerabilities have been described in previous CERT advisories, which are available anonymous FTP from info.cert.org). The intruders then run a network monitoring tool that captures up to the first 128 keystrokes of all newly opened FTP, telnet, and rlogin sessions visible within the compromised system's domain. These keystrokes usually contain host, account, and password information for user accounts on other systems; the intruders log these for later retrieval. The intruders typically install Trojan horse programs to support subsequent access to the compromised system and to hide their network monitoring process. II. Impact All connected network sites that use the network to access remote systems are at risk from this attack. All user account and password information derived from FTP, telnet, and rlogin sessions and passing through the same network as the compromised host could be disclosed. III. Approach There are three steps in CERT's recommended approach to the problem: - Detect if the network monitoring tool is running on any of your hosts that support a promiscuous network interface. - Protect against this attack either by disabling the network interface for those systems that do not use this feature or by attempting to prevent unauthorized use of the feature on systems where this interface is necessary. - Scope the extent of the attack and recover in the event that the network monitoring tool is discovered. A. Detection The network monitoring tool can be run under a variety of process names and log to a variety of filenames. Thus, the best method for detecting the tool is to look for 1) Trojan horse programs commonly used in conjunction with this attack, 2) any suspect processes running on the system, and 3) the unauthorized use of /dev/nit. 1) Trojan horse programs: The intruders have been found to replace one or more of the following programs with a Trojan horse version in conjunction with this attack: /usr/etc/in.telnetd and /bin/login - Used to provide back-door access for the intruders to retrieve information /bin/ps - Used to disguise the network monitoring process Because the intruders install Trojan horse variations of standard UNIX commands, CERT recommends not using other commands such as the standard UNIX sum(1) or cmp(1) commands to locate the Trojan horse programs on the system until these programs can be restored from distribution media, run from read-only media (such as a mounted CD-ROM), or verified using cryptographic checksum information. In addition to the possibility of having the checksum programs replaced by the intruders, the Trojan horse programs mentioned above may have been engineered to produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. CERT recommends that you use both the /usr/5bin/sum and /bin/sum commands to compare against the distribution media and assure that the programs have not been replaced. The use of cmp(1), MD5, Tripwire (only if the baseline checksums were created on a distribution system), and other cryptographic checksum tools are also sufficient to detect these Trojan horse programs, provided these programs were not available for modification by the intruder. If the distribution is available on CD-ROM or other read-only device, it may be possible to compare against these volumes or run programs off these media. 2) Suspect processes: Although the name of the network monitoring tool can vary from attack to attack, it is possible to detect a suspect process running as root using ps(1) or other process-listing commands. Until the ps(1) command has been verified against distribution media, it should not be relied upon--a Trojan horse version is being used by the intruders to hide the monitoring process. Some process names that have been observed are sendmail, es, and in.netd. The arguments to the process also provide an indication of where the log file is located. If the "-F" flag is set on the process, the filename following indicates the location of the log file used for the collection of authentication information for later retrieval by the intruders. 3) Unauthorized use of /dev/nit: If the network monitoring tool is currently running on your system, it is possible to detect this by checking for unauthorized use of the /dev/nit interface. CERT has created a minimal tool for this purpose. The source code for this tool is available via anonymous FTP on info.cert.org in the /pub/tools/cpm directory or on ftp.uu.net in the /pub/security/cpm directory as cpm.1.0.tar.Z. The checksum information is: Filename Standard UNIX Sum System V Sum -------------- ----------------- ------------ cpm.1.0.tar.Z: 11097 6 24453 12 MD5 Checksum MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155 This archive contains a readme file, also included as Appendix C of this advisory, containing instructions on installing and using this detection tool. B. Prevention There are two actions that are effective in preventing this attack. A long-term solution requires eliminating transmission of clear-text passwords on the network. For this specific attack, however, a short-term workaround exists. Both of these are described below. 1) Long-term prevention: CERT recognizes that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network. CERT has collected some information on relevant technologies. This information is included as Appendix B in this advisory. Note: These solutions will not protect against transient or remote access transmission of clear-text passwords through the network. Until everyone connected to your network is using the above technologies, your policy should allow only authorized users and programs access to promiscuous network interfaces. The tool described in Section III.A.3 above may be helpful in verifying this restricted access. 2) Short-term workaround: Regardless of whether the network monitoring software is detected on your system, CERT recommends that ALL SITES take action to prevent unauthorized network monitoring on their systems. You can do this either by removing the interface, if it is not used on the system or by attempting to prevent the misuse of this interface. For systems other than Sun and Solbourne, contact your vendor to find out if promiscuous mode network access is supported and, if so, what is the recommended method to disable or monitor this feature. For SunOS 4.x and Solbourne systems, the promiscuous interface to the network can be eliminated by removing the /dev/nit capability from the kernel. The procedure for doing so is outlined below (see your system manuals for more details). Once the procedure is complete, you may remove the device file /dev/nit since it is no longer functional. Procedure for removing /dev/nit from the kernel: 1. Become root on the system. 2. Apply "method 1" as outlined in the System and Network Administration manual, in the section, "Sun System Administration Procedures," Chapter 9, "Reconfiguring the System Kernel." Excerpts from the method are reproduced below: # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf # cp CONFIG_FILE SYS_NAME [Note that at this step, you should replace the CONFIG_FILE with your system specific configuration file if one exists.] # chmod +w SYS_NAME # vi SYS_NAME # # The following are for streams NIT support. NIT is used by # etherfind, traffic, rarpd, and ndbootd. As a rule of thumb, # NIT is almost always needed on a server and almost never # needed on a diskless client. # pseudo-device snit # streams NIT pseudo-device pf # packet filter pseudo-device nbuf # NIT buffering module [Comment out the preceding three lines; save and exit the editor before proceeding.] # config SYS_NAME # cd ../SYS_NAME # make # mv /vmunix /vmunix.old # cp vmunix /vmunix # /etc/halt > b [This step will reboot the system with the new kernel.] [NOTE that even after the new kernel is installed, you need to take care to ensure that the previous vmunix.old , or other kernel, is not used to reboot the system.] C. Scope and recovery If you detect the network monitoring software at your site, CERT recommends following three steps to successfully determine the scope of the problem and to recover from this attack. 1. Restore the system that was subjected to the network monitoring software. The systems on which the network monitoring and/or Trojan horse programs are found have been compromised at the root level; your system configuration may have been altered. See Appendix A of this advisory for help with recovery. 2. Consider changing router, server, and privileged account passwords due to the wide-spread nature of these attacks. Since this threat involves monitoring remote connections, take care to change these passwords using some mechanism other than remote telnet, rlogin, or FTP access. 3. Urge users to change passwords on local and remote accounts. Users who access accounts using telnet, rlogin, or FTP either to or from systems within the compromised domain should change their passwords after the intruder's network monitor has been disabled. 4. Notify remote sites connected from or through the local domain of the network compromise. Encourage the remote sites to check their systems for unauthorized activity. Be aware that if your site routes network traffic between external domains, both of these domains may have been compromised by the network monitoring software. --------------------------------------------------------------------------- The CERT Coordination Center thanks the members of the FIRST community as well as the many technical experts around the Internet who participated in creating this advisory. Special thanks to Eugene Spafford of Purdue University for his contributions. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Appendix A: RECOVERING FROM A UNIX ROOT COMPROMISE A. Immediate recovery technique 1) Disconnect from the network or operate the system in single- user mode during the recovery. This will keep users and intruders from accessing the system. 2) Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3) Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4) Change the password on all accounts. 5) Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. B. Improving the security of your system 1) CERT Security Checklist Using the checklist will help you identify security weaknesses or modifications to your systems. The CERT Security Checklist is based on information gained from computer security incidents reported to CERT. It is available via anonymous FTP from info.cert.org in the file pub/tech_tips/security_info. 2) Security Tools Use security tools such as COPS and Tripwire to check for security configuration weaknesses and for modifications made by intruders. We suggest storing these security tools, their configuration files, and databases offline or encrypted. TCP daemon wrapper programs provide additional logging and access control. These tools are available via anonymous FTP from info.cert.org in the pub/tools directory. 3) CERT Advisories Review past CERT advisories (both vendor-specific and generic) and install all appropriate patches or workarounds as described in the advisories. CERT advisories and other security-related information are available via anonymous FTP from info.cert.org in the pub/cert_advisories directory. To join the CERT Advisory mailing list, send a request to: cert-advisory-request@cert.org Please include contact information, including a telephone number. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Copyright (c) Carnegie Mellon University 1994 --------------------------------------------------------------------------- Appendix B: ONE-TIME PASSWORDS Given today's networked environments, CERT recommends that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. CERT has seen many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. These programs capture clear-text hostname, account name, password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password passes across the network in clear text. Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). This document provides a list of sources for products that provide this capability. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection. I. Public Domain packages S/KEY(TM) The S/KEY package is publicly available (no fee) via anonymous FTP from: thumper.bellcore.com /pub/nmh directory There are three subdirectories: skey UNIX code and documents on S/KEY. Includes the change needed to login, and stand-alone commands (such as "key"), that computes the one-time password for the user, given the secret password and the S/KEY command. dos DOS or DOS/WINDOWS S/KEY programs. Includes DOS version of "key" and "termkey" which is a TSR program. mac One-time password calculation utility for the Mac. II. Commercial Products Secure Net Key (SNK) (Do-it-yourself project) Digital Pathways, Inc. 201 Ravendale Dr. Mountainview, Ca. 94043-5216 USA Phone: 415-964-0707 Fax: (415) 961-7487 Products: handheld authentication calculators (SNK004) serial line auth interruptors (guardian) Note: Secure Net Key (SNK) is des-based, and therefore restricted from US export. Secure ID (complete turnkey systems) Security Dynamics One Alewife Center Cambridge, MA 02140-2312 USA Phone: 617-547-7820 Fax: (617) 354-8836 Products: SecurID changing number authentication card ACE server software SecureID is time-synchronized using a 'proprietary' number generation algorithm WatchWord and WatchWord II Racal-Guardata 480 Spring Park Place Herndon, VA 22070 703-471-0892 1-800-521-6261 ext 217 Products: Watchword authentication calculator Encrypting modems Alpha-numeric keypad, digital signature capability SafeWord Enigma Logic, Inc. 2151 Salvio #301 Concord, CA 94520 510-827-5707 Fax: (510)827-2593 Products: DES Silver card authentication calculator SafeWord Multisync card authentication calculator Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as other OS versions. Supports one-time passwords and super smartcards from several vendors. --------------------------------------------------------------------------- Appendix C: cpm 1.0 README FILE cpm - check for network interfaces in promiscuous mode. Copyright (c) Carnegie Mellon University 1994 Thursday Feb 3 1994 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 This program is free software; you can distribute it and/or modify it as long as you retain the Carnegie Mellon copyright statement. It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z. This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED WARRANTY of merchantability or fitness for a particular purpose. This package contains: README MANIFEST cpm.1 cpm.c To create cpm under SunOS, type: % cc -Bstatic -o cpm cpm.c On machines that support dynamic loading, such as Sun's, CERT recommends that programs be statically linked so that this feature is disabled. CERT recommends that after you install cpm in your favorite directory, you take measures to ensure the integrity of the program by noting the size and checksums of the source code and resulting binary. The following is an example of the output of cpm and its exit status. Running cpm on a machine where both the le0 and le2 interfaces are in promiscuous mode, under csh(1): % cpm le0 le2 % echo $status 2 % Running cpm on a machine where no interfaces are in promiscuous mode, under csh(1): % cpm % echo $status 0 %