The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 15 Issue 45

Tuesday 8 February 1994

Contents

o A Rise in Internet Break-ins Sets off a Security Alarm
NYT excerpt
o CERT Advisory - Ongoing Network Monitoring Attacks
CERT
o "Misunderstanding" a CERT advisory
Klaus Brunnstein
o Info on RISKS (comp.risks)

A RISE IN INTERNET BREAK-INS SETS OFF A SECURITY ALARM [Excerpt]

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 8 Feb 94 11:03:33 PST
         By PETER H. LEWIS, c.1994 N.Y. Times News Service

   NEW YORK Citing computer-security violations of unprecedented scope,
security experts have issued a warning that unknown assailants have been
breaking into scores of government, corporate and university computers
connected to the global Internet communications network.  Saying that it had
been ``flooded'' with reports of computer break-ins in the last week, the
federally supported Computer Emergency Response Team broadcast its warning
late Thursday night over the Internet, a web of computer networks used by an
estimated 15 million people in the United States and abroad.
   Sophisticated software, secretly planted on various computers throughout
the Internet, has allowed unknown intruders to steal passwords and electronic
addresses from legitimate users, computer security experts said Friday.

   [The full article summarizes a situation that by now should be familiar
   to RISKS readers.  See the following CERT Advisory, and a comment
   from Klaus Brunnstein.  See also articles the same day in the
   Washington Post and elsewhere.  PGN]


CERT Advisory - Ongoing Network Monitoring Attacks

CERT Advisory <cert-advisory-request@cert.org>
Thu, 3 Feb 94 21:14:40 EST
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.
        Mountain View, Ca. 94043-5216
        USA
        Phone: 415-964-0707
        Fax: (415) 961-7487

                Products:
                        handheld authentication calculators  (SNK004)
                        serial line auth interrupters (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
   %


"Misunderstanding" a CERT advisory

Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Mon, 7 Feb 1994 16:37:14 +0100
Waves went high in some German media on Friday, Feb.5 1994, when news from
Philadelphia (via CMU-SEI's press release) and Washington's Post was mediated
by some European news agencies. Germany's 2nd TV channel (ZDF) informed the
surprised public that *hackers had succeeded to invade a secure network which
had been installed in times of Cold War to protect US Armed  Forces even in
the case of a Nuclear War*. As several 10,000 passwords had been hacked, now
more than 20 million users have to change their password. Regional and private
TV and radio stations followed on Saturday, though only few newspapers took
this up on Monday.

Nothing of this (mis)information was in the CERT advisory distributed on
Febrary 3, where users of some UNIX systems (esp. SunOS with  /dev/nit) were
informed that it might be wise to take precautionary action against a potential
sniffer attack. Now, 3 days later, responsible journalists inform us that
there were *2 agency reports*, one delivered by German press agency (dpa)
which was rather serious and non-speculative, and another one from Agency
France Press (AFP) which ZDF based it's report upon (as it was the more
"interesting one :-). Here is this in-famous text (translation by messenger):

    "Washington, February 5 (AFP) - Computer pirates have cracked the largest
     computer network in the world. Totally 20 million users on 'Internet'
     should receive new passwords, told the emergency committee installed by
     US ministry of defence. Internet is used by universities, government
     agencies, enterprises and private persons. The network was established
     in times of the Cold War to serve US Armed Forces also in case of Atomic
     War as 'invulnerable' information network. The hackers, so far unidenti-
     fied, succeeded according to the emergency committee to read data from
     ten thousands of systems on 'Internet'. They succeeded by using a program
     named 'Trojan Horse' which allows legal access to Internet central com-
     puter but then does not go any further."

Apart from the many wrong or misunderstood facts in this news, the reaction of
some experts was interesting. German Information Agency (GISA) said: "Old
stuff, no reason panic!" Another expert said: "CERT is in actual fight for
money from US administration, they needed some public attention!" General
comments were: "Blind actionism of US' CERT!"

Somehow, the media uproar reminds of the Michelangelo case where cautious
warnings of experts (infection at most small percentage of PCs) were publicly
raised *up to 50 mio infected PC systems* by badly informed journalists.
No expert can ever exclude that her/his warnings are always correctly under-
stood, but in this case, the serious question is: With so many unknown
parameters (how many different sniffer trojans existed? How many nodes were
affected? For what purposes were the sniffers used? etc): why issued CERT/CC
a press release (which it very rarely did so far), in addition to its advisory?

Unfortunately, this unjustified media hysteria will fall back, as in previous
cases, on those who work hard for improving security and safety of systems
and networks:-) This is why the background must be carefully analysed.

Klaus Brunnstein (Feb.7,1994)

Please report problems with the web pages to the maintainer

Top