4621893 1999-12-29 14:56 /293 rader/ Postmaster
Mottagare: Bugtraq (import) <9074>
Ärende: CERT Advisory CA-99-17 Denial-of-Service Tools
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <19991229000153.G14307@underground.org>
Date: Wed, 29 Dec 1999 00:01:53 -0800
Reply-To: Aleph One <aleph1@UNDERGROUND.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Aleph One <aleph1@UNDERGROUND.ORG>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
-----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: cert@cert.org
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-request@cert.org 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-----
(4621893) ------------------------------------------(Ombruten)