home *** CD-ROM | disk | FTP | other *** search
/ Chaos Computer Club 1997 February / cccd_beta_feb_97.iso / contrib / cert / ca9401 < prev    next >
PGP Signed Message  |  1997-02-28  |  28KB  |  691 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2.  
  3. =============================================================================
  4. CERT(sm) Advisory CA-94:01
  5. Original issue date:  February 3, 1994
  6. Last revised: September 9, 1996
  7.                    Revised sentence 1 regarding timing of the increase in
  8.                    reports. In Appendix A, added a pointer to our tech tip on
  9.                    recovering from a root compromise.
  10.  
  11.                     A complete revision history is at the end of this file.
  12.  
  13. Topic: Ongoing Network Monitoring Attacks
  14. - -----------------------------------------------------------------------------
  15.  
  16. In the week before we originally issued this advisory, the CERT/CC staff
  17. observed a dramatic increase in reports of intruders monitoring network
  18. traffic.  Systems of some service providers have been compromised, and all
  19. systems that offer remote access through rlogin, telnet, and FTP are at risk.
  20. Intruders have already captured access information for tens of thousands of
  21. systems across the Internet. 
  22.  
  23. The current attacks involve a network monitoring tool that uses the
  24. promiscuous mode of a specific network interface, /dev/nit, to capture
  25. host and user authentication information on all newly opened FTP,
  26. telnet, and rlogin sessions.
  27.  
  28. In the short-term, we recommend that all users on sites that offer
  29. remote access change passwords on any network-accessed account. In
  30. addition, all sites having systems that support the /dev/nit interface
  31. should disable this feature if it is not used and attempt to prevent
  32. unauthorized access if the feature is necessary. A procedure for
  33. accomplishing this is described in Section III.B.2 below.  Systems
  34. known to support the interface are SunOS 4.x (Sun3 and Sun4
  35. architectures) and Solbourne systems; there may be others. Sun Solaris
  36. systems do not support the /dev/nit interface. If you have a system
  37. other than Sun or Solbourne, contact your vendor to find if this
  38. interface is supported.
  39.  
  40. While the attack is specific to /dev/nit, the short-term workaround does not
  41. constitute a solution. The best long-term solution currently available for
  42. this attack is to reduce or eliminate the transmission of reusable passwords
  43. in clear-text over the network.
  44.  
  45.  
  46. - -----------------------------------------------------------------------------
  47.  
  48. I.   Description
  49.  
  50.      Root-compromised systems that support a promiscuous network
  51.      interface are being used by intruders to collect host and user
  52.      authentication information visible on the network.
  53.  
  54.      The intruders first penetrate a system and gain root access
  55.      through an unpatched vulnerability. Solutions and workarounds for
  56.      these vulnerabilities have been described in previous CERT
  57.      advisories, which are available from
  58.                   ftp://info.cert.org/pub/cert_advisories
  59.  
  60.      The intruders then run a network monitoring tool that captures up
  61.      to the first 128 keystrokes of all newly opened FTP, telnet, and
  62.      rlogin sessions visible within the compromised system's domain.
  63.      These keystrokes usually contain host, account, and password
  64.      information for user accounts on other systems; the intruders log
  65.      these for later retrieval.  The intruders typically install
  66.      Trojan horse programs to support subsequent access to the
  67.      compromised system and to hide their network monitoring process.
  68.  
  69. II.  Impact
  70.  
  71.      All connected network sites that use the network to access remote
  72.      systems are at risk from this attack.
  73.  
  74.      All user account and password information derived from FTP,
  75.      telnet, and rlogin sessions and passing through the same network
  76.      as the compromised host could be disclosed.
  77.  
  78.  
  79. III. Approach
  80.  
  81.      There are three steps in our recommended approach to the
  82.      problem:
  83.  
  84.      - Detect if the network monitoring tool is running on any of your
  85.        hosts that support a promiscuous network interface.
  86.  
  87.      - Protect against this attack either by disabling the network
  88.        interface for those systems that do not use this feature or by
  89.        attempting to prevent unauthorized use of the feature on systems
  90.        where this interface is necessary.
  91.  
  92.      - Scope the extent of the attack and recover in the event that
  93.        the network monitoring tool is discovered.
  94.  
  95.      A.  Detection
  96.  
  97.          The network monitoring tool can be run under a variety of
  98.          process names and log to a variety of filenames.  Thus, the
  99.          best method for detecting the tool is to look for 1) Trojan
  100.          horse programs commonly used in conjunction with this attack,
  101.          2) any suspect processes running on the system, 3) the
  102.          unauthorized use of /dev/nit, 4) unexpected ASCII files in the
  103.          /dev directory, and 5) modifications to /etc/rc* files and
  104.          /etc/shutdown.
  105.  
  106.          1) Trojan horse programs:
  107.  
  108.          The intruders have been found to replace one or more of the
  109.          following programs with a Trojan horse version in conjunction
  110.          with this attack:
  111.  
  112.            /usr/etc/in.telnetd
  113.            and /bin/login -  Used to provide back-door access for the
  114.                              intruders to retrieve information
  115.            /bin/ps  - Used to disguise the network monitoring process
  116.            netstat
  117.            ifconfig
  118.            su
  119.            ls
  120.            find
  121.            du
  122.            df
  123.            libc
  124.            sync
  125.            binaries referred in /etc/inetd.conf
  126.  
  127.          Because the intruders install Trojan horse variations of
  128.          standard UNIX commands, we recommend not using other
  129.          commands such as the standard UNIX sum(1) or cmp(1) commands
  130.          to locate the Trojan horse programs on the system until these
  131.          programs can be restored from distribution media, run from
  132.          read-only media (such as a mounted CD-ROM), or verified using
  133.          cryptographic checksum information.
  134.  
  135.          In addition to the possibility of having the checksum
  136.          programs replaced by the intruders, the Trojan horse programs
  137.          mentioned above may have been engineered to produce the same
  138.          standard checksum and timestamp as the legitimate version.
  139.          Because of this, the standard UNIX sum(1) command and the
  140.          timestamps associated with the programs are not sufficient to
  141.          determine whether the programs have been replaced.
  142.  
  143.          We recommend that you use both the /usr/5bin/sum and
  144.          /bin/sum commands to compare against the distribution media
  145.          and assure that the programs have not been replaced.  The use
  146.          of cmp(1), MD5, Tripwire (only if the baseline checksums were
  147.          created on a distribution system), and other cryptographic
  148.          checksum tools are also sufficient to detect these Trojan
  149.          horse programs, provided these programs were not available
  150.          for modification by the intruder.  If the distribution is
  151.          available on CD-ROM or other read-only device, it may be
  152.          possible to compare against these volumes or run programs off
  153.          these media.
  154.  
  155.          2) Suspect processes:
  156.  
  157.          Although the name of the network monitoring tool can vary from
  158.          attack to attack, it is possible to detect a suspect process
  159.          running as root using ps(1) or other process-listing commands.
  160.          Until the ps(1) command has been verified against distribution
  161.          media, it should not be relied upon--a Trojan horse version
  162.          is being used by the intruders to hide the monitoring process.
  163.          Some process names that have been observed are sendmail, es,
  164.          and in.netd.  The arguments to the process also provide an
  165.          indication of where the log file is located.  If the "-F" flag
  166.          is set on the process, the filename following indicates the
  167.          location of the log file used for the collection of
  168.          authentication information for later retrieval by the intruders.
  169.  
  170.          3) Unauthorized use of /dev/nit:
  171.  
  172.          If the network monitoring tool is currently running on your
  173.          system, it is possible to detect this by checking for
  174.          unauthorized use of the /dev/nit interface. We have created
  175.          a minimal tool, cpm, for this purpose.
  176.  
  177.          We urge you to use the cpm tool on every machine at your site (where
  178.          applicable). Some sites run this as a cron job at regular intervals,
  179.          such as every 15 minutes, to report any result that indicates a
  180.          possible compromise.
  181.  
  182.          cpm (version 1.2) can be obtained from
  183.  
  184.                 ftp://info.cert.org/pub/tools/cpm/
  185.                 ftp://ftp.uu.net/pub/security/cpm/
  186.  
  187.          Below are the MD5 checksums for the tarfiles and the contents of the
  188.          cpm.1.2 directory, when created.
  189.  
  190.                 MD5 (cpm.1.2.tar) = 5f0489e868fbf213c026343cca7ec6ff
  191.                 MD5 (cpm.1.2.tar.Z) = b76285923ad17d8dbfffd9dd0082ce5b
  192.                 MD5 (cpm.1.2.tar.gz) = e689ca1c663e4c643887245f41f13a84
  193.  
  194.                 MD5 (cpm.1.2/MANIFEST) = ed6ec1ca374113c074547eb0580d9240
  195.                 MD5 (cpm.1.2/README) = 34713d2be42b434a117165a5002f0a27
  196.                 MD5 (cpm.1.2/cpm.1) = 84df06d9c6687314599754f3515c461b
  197.                 MD5 (cpm.1.2/cpm.c) = 3da08fe657b96a75697a41e2700d456e
  198.                 MD5 (cpm.1.2/cpm.txt) = 5860bfb9c383f519e494a38c682c22fb
  199.  
  200.  
  201.          This archive contains a readme file, also included as
  202.          Appendix C of this advisory, containing instructions on
  203.          installing and using this detection tool.
  204.  
  205.          Note that some sites have reported intruders gaining root access then
  206.          reinstalling a kernel with /dev/nit functionality.
  207.  
  208.          4) Unexpected ASCII files in /dev
  209.  
  210.          Look for unexpected ASCII files in the /dev directory.
  211.          Some of the Trojan binaries listed above rely on configuration files,
  212.          which are often found in /dev.
  213.  
  214.          5) Modifications to /etc/rc* files and /etc/shutdown
  215.  
  216.          Check for modifications to /etc/rc* files and /etc/shutdown.
  217.          Some intruders have modified /etc/rc files to ensure that
  218.          the sniffer restarts after a shutdown or reboot. Others
  219.          have modified the shutdown sequence to remove all traces of
  220.          compromise.
  221.  
  222.  
  223.      B.  Prevention
  224.  
  225.          There are two actions that are effective in preventing this
  226.          attack.  A long-term solution requires eliminating
  227.          transmission of clear-text passwords on the network.  For
  228.          this specific attack, however, a short-term workaround
  229.          exists.  Both of these are described below.
  230.  
  231.          1) Long-term prevention:
  232.  
  233.          We recognize that the only effective long-term solution to
  234.          prevent these attacks is by not transmitting reusable
  235.          clear-text passwords on the network. We have collected some
  236.          information on relevant technologies.  This information is
  237.          included as Appendix B in this advisory.  Note: These
  238.          solutions will not protect against transient or remote access
  239.          transmission of clear-text passwords through the network.
  240.  
  241.          Until everyone connected to your network is using the above
  242.          technologies, your policy should allow only authorized users
  243.          and programs access to promiscuous network interfaces.  The
  244.          tool described in Section III.A.3 above may be helpful in
  245.          verifying this restricted access.
  246.  
  247.          2) Short-term workaround:
  248.  
  249.          Regardless of whether the network monitoring software is
  250.          detected on your system, we recommend that ALL SITES take
  251.          action to prevent unauthorized network monitoring on their
  252.          systems. You can do this either by removing the interface, if
  253.          it is not used on the system or by attempting to prevent the
  254.          misuse of this interface.
  255.  
  256.          For systems other than Sun and Solbourne, contact your vendor
  257.          to find out if promiscuous mode network access is supported
  258.          and, if so, what is the recommended method to disable or
  259.          monitor this feature.
  260.  
  261.          For SunOS 4.x and Solbourne systems, the promiscuous
  262.          interface to the network can be eliminated by removing the
  263.          /dev/nit capability from the kernel.  The procedure for doing
  264.          so is outlined below (see your system manuals for more
  265.          details).  Once the procedure is complete, you may remove the
  266.          device file /dev/nit since it is no longer functional.
  267.  
  268.          Procedure for removing /dev/nit from the kernel:
  269.  
  270.          1. Become root on the system.
  271.  
  272.          2. Apply "method 1" as outlined in the System and Network
  273.          Administration manual, in the section, "Sun System
  274.          Administration Procedures," Chapter 9, "Reconfiguring the
  275.          System Kernel."  Excerpts from the method are reproduced
  276.          below:
  277.  
  278.          # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
  279.          # cp CONFIG_FILE SYS_NAME
  280.  
  281.          [Note that at this step, you should replace the CONFIG_FILE
  282.          with your system specific configuration file if one exists.]
  283.  
  284.          # chmod +w SYS_NAME
  285.          # vi SYS_NAME
  286.  
  287.             #
  288.             # The following are for streams NIT support.  NIT is used by
  289.             # etherfind, traffic, rarpd, and ndbootd.  As a rule of thumb,
  290.             # NIT is almost always needed on a server and almost never
  291.             # needed on a diskless client.
  292.             #
  293.             pseudo-device   snit            # streams NIT
  294.             pseudo-device   pf              # packet filter
  295.             pseudo-device   nbuf            # NIT buffering module
  296.  
  297.          [Comment out the preceding three lines; save and exit the
  298.          editor before proceeding.]
  299.  
  300.          # config SYS_NAME
  301.          # cd ../SYS_NAME
  302.          # make
  303.  
  304.          # mv /vmunix /vmunix.old
  305.          # cp vmunix /vmunix
  306.  
  307.          # /etc/halt
  308.          > b
  309.  
  310.          [This step will reboot the system with the new kernel.]
  311.  
  312.          [NOTE that even after the new kernel is installed, you need
  313.          to take care to ensure that the previous vmunix.old , or
  314.          other kernel, is not used to reboot the system.]
  315.  
  316.  
  317.      C.  Scope and recovery
  318.  
  319.          If you detect the network monitoring software at your site,
  320.          we recommend following three steps to successfully
  321.          determine the scope of the problem and to recover from this
  322.          attack.
  323.  
  324.          1. Restore the system that was subjected to the network
  325.          monitoring software.
  326.  
  327.          The systems on which the network monitoring and/or Trojan
  328.          horse programs are found have been compromised at the root
  329.          level; your system configuration may have been altered.  See
  330.          Appendix A of this advisory for help with recovery.
  331.  
  332.          2. Consider changing router, server, and privileged account
  333.          passwords due to the wide-spread nature of these attacks.
  334.  
  335.          Since this threat involves monitoring remote connections,
  336.          take care to change these passwords using some mechanism
  337.          other than remote telnet, rlogin, or FTP access.
  338.  
  339.          3. Urge users to change passwords on local and remote
  340.          accounts.
  341.  
  342.          Users who access accounts using telnet, rlogin, or FTP either
  343.          to or from systems within the compromised domain should
  344.          change their passwords after the intruder's network monitor
  345.          has been disabled.
  346.  
  347.          4. Notify remote sites connected from or through the local
  348.          domain of the network compromise.
  349.  
  350.          Encourage the remote sites to check their systems for
  351.          unauthorized activity.  Be aware that if your site routes
  352.          network traffic between external domains, both of these
  353.          domains may have been compromised by the network monitoring
  354.          software.
  355.  
  356.  
  357. .............................................................................
  358.  
  359. Appendix A:
  360.                     RECOVERING FROM A UNIX ROOT COMPROMISE
  361.  
  362. A.   Immediate recovery technique
  363.  
  364.         1) Disconnect from the network or operate the system in
  365.            single- user mode during the recovery.  This will keep users
  366.            and intruders from accessing the system.
  367.  
  368.         2) Verify system binaries and configuration files against the
  369.            vendor's media (do not rely on timestamp information to
  370.            provide an indication of modification).  Do not trust any
  371.            verification tool such as cmp(1) located on the compromised
  372.            system as it, too, may have been modified by the intruder.
  373.            In addition, do not trust the results of the standard UNIX
  374.            sum(1) program as we have seen intruders modify system
  375.            files in such a way that the checksums remain the same.
  376.            Replace any modified files from the vendor's media, not
  377.            from backups.
  378.  
  379.                                 -- or --
  380.  
  381.            Reload your system from the vendor's media.
  382.  
  383.         3) Search the system for new or modified setuid root files.
  384.  
  385.                 find / -user root -perm -4000 -print
  386.  
  387.            If you are using NFS or AFS file systems, use ncheck to
  388.            search the local file systems.
  389.  
  390.                 ncheck -s /dev/sd0a
  391.  
  392.         4) Change the password on all accounts.
  393.  
  394.         5) Don't trust your backups for reloading any file used by
  395.            root.  You do not want to re-introduce files altered by an
  396.            intruder.
  397.  
  398.         More detailed advice can be found in
  399.            ftp://info.cert.org/pub/tech_tips/root_compromise
  400.  
  401. B.   Improving the security of your system
  402.  
  403.         1) CERT Security Technical Tips
  404.            The CERT/CC staff has developed technical tips and checklists based
  405.            on information gained from computer security incidents reported to
  406.            us. These tips are available from
  407.                ftp://info.cert.org/pub/tech_tips
  408.  
  409.         2) Security Tools
  410.            Use security tools such as COPS and Tripwire to check for
  411.            security configuration weaknesses and for modifications
  412.            made by intruders.  We suggest storing these security
  413.            tools, their configuration files, and databases offline or
  414.            encrypted.  TCP daemon wrapper programs provide additional
  415.            logging and access control.  These tools are available
  416.  
  417.                ftp://info.cert.org/pub/tools
  418.  
  419.         3) CERT Advisories
  420.            Review past CERT advisories (both vendor-specific and
  421.            generic) and install all appropriate patches or workarounds
  422.            as described in the advisories.  CERT advisories and other
  423.            security-related information are available from
  424.  
  425.                 http://www.cert.org/
  426.                 ftp://info.cert.org/pub/
  427.  
  428.  
  429.            To join the CERT Advisory mailing list, send a request to:
  430.  
  431.                         cert-advisory-request@cert.org
  432.  
  433.            Please include contact information, including a telephone number.
  434.  
  435.  
  436.  
  437. CERT Coordination Center
  438. Software Engineering Institute
  439. Carnegie Mellon University
  440. Pittsburgh, PA 15213-3890
  441.  
  442. Copyright (c) Carnegie Mellon University 1994
  443.  
  444.  
  445.  
  446.  
  447. ..............................................................................
  448.  
  449. Appendix B:
  450.                          ONE-TIME PASSWORDS
  451.  
  452. Given today's networked environments, CERT recommends that sites
  453. concerned about the security and integrity of their systems and
  454. networks consider moving away from standard, reusable passwords. CERT
  455. has seen many incidents involving Trojan network programs (e.g.,
  456. telnet and rlogin) and network packet sniffing programs.  These
  457. programs capture clear-text hostname, account name, password triplets.
  458. Intruders can use the captured information for subsequent access to
  459. those hosts and accounts.  This is possible because 1) the password is
  460. used over and over (hence the term "reusable"), and 2) the password
  461. passes across the network in clear text.
  462.  
  463. Several authentication techniques have been developed that address
  464. this problem. Among these techniques are challenge-response
  465. technologies that provide passwords that are only used once (commonly
  466. called one-time passwords). This document provides a list of sources
  467. for products that provide this capability. The decision to use a
  468. product is the responsibility of each organization, and each
  469. organization should perform its own evaluation and selection.
  470.  
  471. I.  Public Domain packages
  472.  
  473. S/KEY(TM)
  474.         The S/KEY package is publicly available (no fee) via
  475.         anonymous FTP from:
  476.  
  477.                 thumper.bellcore.com            /pub/nmh directory
  478.  
  479.         There are three subdirectories:
  480.  
  481.                 skey            UNIX code and documents on S/KEY.
  482.                                 Includes the change needed to login,
  483.                                 and stand-alone commands (such as "key"),
  484.                                 that computes the one-time password for
  485.                                 the user, given the secret password and
  486.                                 the S/KEY command.
  487.  
  488.                 dos             DOS or DOS/WINDOWS S/KEY programs.  Includes
  489.                                 DOS version of "key" and "termkey" which is
  490.                                 a TSR program.
  491.  
  492.                 mac             One-time password calculation utility for
  493.                                 the Mac.
  494.  
  495.  
  496. II.  Commercial Products
  497.  
  498. Secure Net Key (SNK)                            (Do-it-yourself project)
  499.         Digital Pathways, Inc.
  500.         201 Ravendale Dr.
  501.         Mountainview, Ca. 94043-5216
  502.         USA
  503.         Phone: 415-964-0707
  504.         Fax: (415) 961-7487
  505.  
  506.                 Products:
  507.                         handheld authentication calculators  (SNK004)
  508.                         serial line auth interruptors (guardian)
  509.  
  510.         Note: Secure Net Key (SNK) is des-based, and therefore restricted
  511.         from US export.
  512.  
  513. Secure ID                                       (complete turnkey systems)
  514.         Security Dynamics
  515.         One Alewife Center
  516.         Cambridge, MA   02140-2312
  517.         USA
  518.         Phone: 617-547-7820
  519.         Fax: (617) 354-8836
  520.  
  521.                  Products:
  522.                         SecurID changing number authentication card
  523.                         ACE server software
  524.  
  525.         SecureID is time-synchronized using a 'proprietary' number
  526.         generation algorithm
  527.  
  528. WatchWord and WatchWord II
  529.         Racal-Guardata
  530.         480 Spring Park Place
  531.         Herndon, VA 22070
  532.         703-471-0892
  533.         1-800-521-6261 ext 217
  534.  
  535.                  Products:
  536.                         Watchword authentication calculator
  537.                         Encrypting modems
  538.  
  539.         Alpha-numeric keypad, digital signature capability
  540.  
  541. SafeWord
  542.         Enigma Logic, Inc.
  543.         2151 Salvio #301
  544.         Concord, CA 94520
  545.         510-827-5707
  546.         Fax: (510)827-2593
  547.  
  548.                 Products:
  549.                         DES Silver card authentication calculator
  550.                         SafeWord Multisync card authentication calculator
  551.  
  552.         Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as
  553.         other OS versions.  Supports one-time passwords and super
  554.         smartcards from several vendors.
  555.  
  556.  
  557.  
  558.  
  559. ..............................................................................
  560.  
  561. Appendix C:
  562.                          cpm 1.0 README FILE
  563.  
  564.  
  565.        cpm -  check for network interfaces in promiscuous mode.
  566.  
  567. Copyright (c) Carnegie Mellon University 1994
  568. Thursday Feb 3 1994
  569.  
  570. CERT Coordination Center
  571. Software Engineering Institute
  572. Carnegie Mellon University
  573. Pittsburgh, PA 15213-3890
  574.  
  575.  
  576.    This program is free software; you can distribute it and/or modify
  577.    it as long as you retain the Carnegie Mellon copyright statement.
  578.  
  579.    It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z.
  580.  
  581.    This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED
  582.    WARRANTY of merchantability or fitness for a particular purpose.
  583.  
  584.    This package contains:
  585.        README
  586.        MANIFEST
  587.        cpm.1
  588.        cpm.c
  589.  
  590.    To create cpm under SunOS, type:
  591.    % cc -Bstatic -o cpm cpm.c
  592.  
  593.    On machines that support dynamic loading, such as Sun's, CERT recommends
  594.    that programs be statically linked so that this feature is disabled.
  595.  
  596.    CERT recommends that after you install cpm in your favorite directory,
  597.    you take measures to ensure the integrity of the program by noting
  598.    the size and checksums of the source code and resulting binary.
  599.  
  600.  
  601.    The following is an example of the output of cpm and its exit status.
  602.  
  603.    Running cpm on a machine where both the le0 and le2 interfaces are
  604.    in promiscuous mode, under csh(1):
  605.  
  606.    % cpm
  607.    le0
  608.    le2
  609.    % echo $status
  610.    2
  611.    %
  612.  
  613.    Running cpm on a machine where no interfaces are in promiscuous
  614.    mode, under csh(1):
  615.  
  616.    % cpm
  617.    % echo $status
  618.    0
  619.    %
  620.  
  621. - ---------------------------------------------------------------------------
  622. The CERT Coordination Center thanks the members of the FIRST community
  623. as well as the many technical experts around the Internet who
  624. participated in creating this advisory.  Special thanks to Eugene
  625. Spafford of Purdue University for his contributions.
  626. - ---------------------------------------------------------------------------
  627.  
  628.  If you believe that your system has been compromised, contact the CERT
  629.  Coordination Center or your representative in Forum of Incident
  630.  Response and Security Teams (FIRST).
  631.  
  632.  Internet E-mail: cert@cert.org
  633.  Telephone: 412-268-7090 (24-hour hotline)
  634.             CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
  635.             and are on call for emergencies during other hours.
  636.  
  637.  CERT Coordination Center
  638.  Software Engineering Institute
  639.  Carnegie Mellon University
  640.  Pittsburgh, PA 15213-3890
  641.  
  642.  Past advisories, information about FIRST representatives, and other
  643.  information related to computer security are available for anonymous
  644.  FTP from info.cert.org.
  645.  
  646. Copyright 1994, 1995, 1996 Carnegie Mellon University
  647. This material may be reproduced and distributed without permission provided
  648. it is used for noncommercial purposes and the copyright statement is
  649. included.
  650.  
  651. CERT is a service mark of Carnegie Mellon University.
  652.  
  653. =============================================================================
  654. UPDATES
  655.  
  656.       * We have seen sniffers for other platforms, i.e., Solaris.
  657.  
  658.       * Sites have reported intruders using sniffers to capture
  659.         authentication to routers. Using that data, they compromise
  660.         the routers and modify the configuration file.
  661.  
  662.  
  663. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  664. Revision history
  665.  
  666. Oct. 09, 1996  Sentence 1 - Clarified the time of the increase in the reports.
  667.                Appendix A - Added the URL for our tech tip on root compromises.
  668. Aug. 30, 1996  Information previously in the README was inserted
  669.                 into the advisory. Updated URLs.
  670. July 31, 1996  Appendix B - referred to new tech tips, which replace the single
  671.                             security checklist
  672. Mar. 20, 1996  Sec.III.A.3 - additional information concerning cpm (v. 1.2)
  673. Sept. 21, 1995 Sec. III.A.3 - suggestions regarding cpm
  674. Feb. 02, 1995  Sec. III - additional information on Trojan binaries (III.A),
  675.                           use of the /dev directory (III.A.3), and two more
  676.                           activities (III.A.4 & III.A.5)
  677. Feb. 02, 1995  Updates section - additional information about sniffer activity
  678.  
  679.  
  680.  
  681.  
  682. -----BEGIN PGP SIGNATURE-----
  683. Version: 2.6.2
  684.  
  685. iQCVAwUBMlutGHVP+x0t4w7BAQGRggQAo7ijdJSgt1beCi1zfajX2JPO2JNqFsgw
  686. Xod8Y7/xqtAkUd8sMK6mC36ViIQESfL7tcoxyPQ708PvTN/CxA+oF5ChS0XMs5U4
  687. iPNT1R22y46JYdEMd0u1FdykDZy/0D1x4/YFfUsjm+UD9gqysWr2V8e5PSCmDIYj
  688. BlGwftZhkfg=
  689. =jlQz
  690. -----END PGP SIGNATURE-----
  691.