CERT Advisory - Ongoing Network Monitoring Attacks

[David Farber <farber () central cis upenn edu>]

The Computer Emergency Response Team has issued the attached advisory about
a dramatic increase this week in reports of intruders monitoring network
traffic.  CERT notes that tens of thousands of systems have had access
information (account IDs and passwords) captured.


CERT recommends that all users on sites that offer remote access change
passwords on any network-accessed account.  However, at the same time, they
note that until the network is known to be free of network monitoring
software, users run a risk of having their password compromised merely by
the act of changing it.


It would seem that the most prudent course would to be to hold off asking
users to change their account passwords on a wholesale basis, until it is
known with some certainty whether any sites on campus have had the
monitoring software installed.  The more users are subject to wholesale
requests to change  passwords, the less they will pay attention to the
requests.


That being said, it would seem to be wise for us to be as certain as
possible that the monitoring software has not been installed on any hosts
at Penn.  CERT notes that SunOS 4.x and Solbourne both support the nework
interface (/dev/nit) which was compromised, so it would seem that those are
the hosts we should concentrate on.  CERT notes that Solaris does not
support the /dev/nit interface, and suggests that customers on other UNIX
platforms contact their vendors to determine their vulnerability.


I suppose I would start by asking that any sysadmins of SunOS 4.x or
Solbourne systems contact me.  If you have the skills and the resources to
follow CERT's detailed instructions (attached) for determining if you have
had the software installed, great.  If you are willing to be available for
some questions from those who may not have the skills, please let me know.
And finally, if you don't have the skills or resources, let me know.  I
can't say now that I can do anything about it, but I'll try.


Meanwhile, I'm trying to find out from other vendors, whether they are
aware of any other platforms which may have been comromised.


As soon as we know whether we have had any sites compromised, we can decide
whether it makes sense to ask any users to change their passwords.


CERT suggests that the long-term solution is to not send re-usable,
unencrypted passwords over the network.  ISC will shortly kick off a task
force to work on this very problem.


One final note.  CERT doesn't say it, but if it was my system, I'd change
root passwords today.


Thanks,
Dave




> Posted-Date: Thu, 3 Feb 94 21:14:40 EST
> From: CERT Advisory <cert-advisory-request () cert org>
> Date: Thu, 3 Feb 94 21:14:40 EST
> To: cert-advisory () cert org
> Subject: CERT Advisory - Ongoing Network Monitoring Attacks
> Organization: Computer Emergency Response Team : 412-268-7090
>
> =============================================================================
> 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