CERT Advisory CA-99-17 Denial-of-Service Tools

From: Aleph One (aleph1at_private)
Date: Wed Dec 29 1999 - 00:01:53 PST

  • Next message: Christopher X. Candreva: "Re: majordomo local exploit"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    Note -- On Tuesday, December 28, 1999, beginning at 6:00 PM Eastern
            Daylight Time (18:00 EST, GMT-5), the CERT Web and
            FTP sites will be unavailable for several hours
            while routine maintenance is done.
    
    
    CERT(R) Advisory CA-99-17 Denial-of-Service Tools
    
       Original release date: December 28, 1999
       Source: CERT/CC
    
       A complete revision history is at the end of this file.
    
    Systems Affected
    
         * All systems connected to the Internet can be affected by
           denial-of-service attacks. Tools that run on a variety of UNIX and
           UNIX-like systems and Windows NT systems have recently been
           released to facilitate denial-of-service attacks. Additionally,
           some MacOS systems can be used as traffic amplifiers to conduct a
           denial-of-service attack.
    
    I. Description
    
    New Distributed Denial-of-Service Tools
    
       Recently, new techniques for executing denial-of-service attacks have
       been made public. A tool similar to Tribe FloodNet (TFN), called Tribe
       FloodNet 2K (TFN2K) was released. Tribe FloodNet is described in
       http://www.cert.org/incident_notes/IN-99-07.html#tfn.
    
       Like TFN, TFN2K is designed to launch coordinated denial-of-service
       attacks from many sources against one or more targets simultaneously.
       It includes features designed specifically to make TFN2K traffic
       difficult to recognize and filter, to remotely execute commands, to
       obfuscate the true source of the traffic, to transport TFN2K traffic
       over multiple transport protocols including UDP, TCP, and ICMP, and
       features to confuse attempts to locate other nodes in a TFN2K network
       by sending "decoy" packets.
    
       TFN2K is designed to work on various UNIX and UNIX-like systems and
       Windows NT.
    
       TFN2K obfuscates the true source of attacks by spoofing IP addresses.
       In networks that employ ingress filtering as described in [1], TFN2K
       can forge packets that appear to come from neighboring machines.
    
       Like TFN, TFN2K can flood networks by sending large amounts of data to
       the victim machine. Unlike TFN, TFN2K includes attacks designed to
       crash or introduce instabilities in systems by sending malformed or
       invalid packets. Some attacks like this are described in
    
       http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html
              http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html
    
       Also like TFN, TFN2K uses a client-server architecture in which a
       single client, under the control of an attacker, issues commands
       simultaneously to a set of TFN2K servers. The servers then conduct the
       denial-of-service attacks against the victim(s). Installing the server
       requires that an intruder first compromise a machine by different
       means.
    
    Asymmetric traffic from MacOS 9
    
       MacOS 9 can be abused by an intruder to generate a large volume of
       traffic directed at a victim in response to a small amount of traffic
       produced by an intruder. This allows an intruder to use MacOS 9 as a
       "traffic amplifier," and flood victims with traffic. According to [3],
       an intruder can use this asymmetry to "amplify" traffic by a factor of
       approximately 37.5, thus enabling an intruder with limited bandwidth
       to flood a much larger connection. This is similar in effect and
       structure to a "smurf" attack, described in
    
       http://www.cert.org/advisories/CA-98.01.smurf.html
    
       Unlike a smurf attack, however, it is not necessary to use a directed
       broadcast to achieve traffic amplification.
    
    II. Impact
    
       Intruders can flood networks with overwhelming amounts of traffic or
       cause machines to crash or otherwise become unstable.
    
    III. Solution
    
       The problem of distributed denial-of-service attacks is discussed at
       length in [2], available at
    
       http://www.cert.org/reports/dsit_workshop.pdf
    
       Managers, system administrators, Internet Service Providers (ISPs) and
       Computer Security Incident Response Teams (CSIRTs) are encouraged to
       read this document to gain a broader understanding of the problem.
    
    For the ultimate victim of distributed denial-of-service attacks
    
       Preparation is crucial. The victim of a distributed denial-of-service
       attack has little recourse using currently available technology to
       respond to an attack in progress. According to [2]:
    
              The impact upon your site and operations is dictated by the
              (in)security of other sites and the ability of of a remote
              attackers to implant the tools and subsequently to control
              and direct multiple systems worldwide to launch an attack.
    
       Sites are strongly encouraged to develop the relationships and
       capabilities described in [2] before you are a victim of a distributed
       denial-of-service attack.
    
    For all Internet Sites
    
       System and network administrators are strongly encouraged to follow
       the guidelines listed in [2]. In addition, sites are encouraged to
       implement ingress filtering as described in [1]. CERT/CC recommends
       implementing such filtering on as many routers as practical. This
       method is not foolproof, as mentioned in [1]:
    
              While the filtering method discussed in this document does
              absolutely nothing to protect against flooding attacks which
              originate from valid prefixes (IP addresses), it will
              prohibit an attacker within the originating network from
              launching an attack of this nature using forged source
              addresses that do not conform to ingress filtering rules.
    
       Because TFN2K implements features designed specifically to take
       advantage of the granularity of ingress filtering rules, the method
       described in [1] means that sites may only be able to determine the
       network or subnet from which an attack originated.
    
       Sites using manageable hubs or switches that can track which IP
       addresses have been seen at a particular port or which can restrict
       which MAC addresses can be used on a particular port may be able to
       further identify which machine(s) is responsible for TFN2K traffic.
       For further information, consult the documentation for your particular
       hub or switch.
    
       The widespread use of this type of filtering can significantly reduce
       the ability of intruders to use spoofed packets to compromise or
       disrupt systems.
    
    Preventing your site from being used by intruders
    
       TFN2K and similar tools rely on the ability of intruders to install
       the client. Preventing your system from being used to install the
       client will help prevent intruders from using your systems to launch
       denial-of-service attacks (in addition to whatever damage they may
       cause to your systems).
    
       Popular recent attacks can be found at
    
       http://www.cert.org/current/current_activity.html
    
       Sites are encouraged to regularly visit this page and address any
       issues found there.
    
    For the "Mac Attack"
    
       Apple is developing a patch, as described in Appendix A. This advisory
       will be updated when the patch is available.
    
       Appendix A contains information provided by vendors for this advisory.
       We will update the appendix as we receive or develop more information.
       If you do not see your vendor's name in Appendix A, the CERT/CC did
       not hear from that vendor. Please contact your vendor directly.
    
    Appendix A. Vendor Information
    
    Apple Computer
    
       We've reproduced the problem in our lab and we are working now to
       create a fix that can be easily distributed to our customers. The
       problem only affects customers running our most recent release of
       networking software on machines that are continuously attached to the
       internet.
    
       While most Macintosh customers are not affected by this problem, we
       are moving quickly to put a solution in place.
    
    References
    
       [1] RFC2267, Network Ingress Filtering: Defeating Denial of Service
       Attacks which employ IP Source Address Spoofing , P. Ferguson, D.
       Senie, The Internet Society, January, 1998, available at
       http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2267.txt
    
       [2] Results of the Distributed-Systems Intruder Tools Workshop, The
       CERT Coordination Center, December, 1999, available at
       http://www.cert.org/reports/dsit_workshop.pdf
    
       [3] The "Mac Attack," a Scheme for Blocking Internet Connections, John
       A. Copeland, December, 1999, available at
       http://www.csc.gatech.edu/~copeland. Temporary alternate URL:
       http://people.atl.mediaone.net/jacopeland
         _________________________________________________________________
    
       The CERT Coordination Center thanks Jeff Schiller of the Massachusetts
       Institute of Technology, Professor John Copeland and Jim Hendricks of
       the Georgia Institute of Technology, Jim Ellis of Sun Microsystems,
       Wietse Venema of IBM, Rick Forno of Network Solutions, Inc., Dave
       Dittrich of the University of Washington, Steve Bellovin of AT&T, and
       Jim Duncan and John Bashinski of Cisco Systems for input and technical
       assistance used in the construction of this advisory.
       ______________________________________________________________________
    
       This document is available from:
       http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html
       ______________________________________________________________________
    
    CERT/CC Contact Information
    
       Email: certat_private
              Phone: +1 412-268-7090 (24-hour hotline)
              Fax: +1 412-268-6989
              Postal address:
              CERT Coordination Center
              Software Engineering Institute
              Carnegie Mellon University
              Pittsburgh PA 15213-3890
              U.S.A.
    
       CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
       Monday through Friday; they are on call for emergencies during other
       hours, on U.S. holidays, and on weekends.
    
    Using encryption
    
       We strongly urge you to encrypt sensitive information sent by email.
       Our public PGP key is available from
    
       http://www.cert.org/CERT_PGP.key
    
       If you prefer to use DES, please call the CERT hotline for more
       information.
    
    Getting security information
    
       CERT publications and other security information are available from
       our web site
    
       http://www.cert.org/
    
       To be added to our mailing list for advisories and bulletins, send
       email to cert-advisory-requestat_private and include SUBSCRIBE
       your-email-address in the subject of your message.
    
       Copyright 1999 Carnegie Mellon University.
       Conditions for use, disclaimers, and sponsorship information can be
       found in
    
       http://www.cert.org/legal_stuff.html
    
       * "CERT" and "CERT Coordination Center" are registered in the U.S.
       Patent and Trademark Office.
       ______________________________________________________________________
    
       NO WARRANTY
       Any material furnished by Carnegie Mellon University and the Software
       Engineering Institute is furnished on an "as is" basis. Carnegie
       Mellon University makes no warranties of any kind, either expressed or
       implied as to any matter including, but not limited to, warranty of
       fitness for a particular purpose or merchantability, exclusivity or
       results obtained from use of the material. Carnegie Mellon University
       does not make any warranty of any kind with respect to freedom from
       patent, trademark, or copyright infringement.
         _________________________________________________________________
    
       Revision History
    December 28, 1999:  Initial release
    
    -----BEGIN PGP SIGNATURE-----
    Version: PGP for Personal Privacy 5.0
    Charset: noconv
    
    iQA/AwUBOGkb5Fr9kb5qlZHQEQJ4UQCfe9K6I9Hbgwubj87S2nIIZx27HY8An2cH
    6SwJnAorE/nGwvx5D7BoaYhN
    =xIpR
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:24:09 PDT