From ciac@tholia.llnl.gov Fri Jan  9 09:56:48 1998
From: CIAC Mail User <ciac@tholia.llnl.gov>
To: ciac-bulletin@tholia.llnl.gov
Date: Wed, 7 Jan 1998 13:50:58 -0800 (PST)
Subject: CIAC Bulletin I-021: "smurf" IP Denial-of-Service Attacks

[ For Public Release ]
-----BEGIN PGP SIGNED MESSAGE-----

             __________________________________________________________

                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___
             __________________________________________________________

                             INFORMATION BULLETIN

                      "smurf" IP Denial-of-Service Attacks

January 6, 1998 23:00 GMT                                         Number I-021
______________________________________________________________________________
PROBLEM:       Reports have been received on continuing denial-of-service
               attacks involving forged ICMP echo request packets.
PLATFORM:      Any platform using the TCP/IP protocol may be vulnerable. Check
               the vendor list included in this bulletin.
DAMAGE:        Both the intermediary and victim of this attack may suffer
               degraded network performance to the point that the network
               cannot be used.
SOLUTION:      Apply the workarounds listed in Section III of this advisory.
______________________________________________________________________________
VULNERABILITY  Sites are urged to take the steps descibed in Section III to
ASSESSMENT:    reduce the potential of your site being used as an intermediary
               or becoming a victim to this type of attack.
______________________________________________________________________________

[ Start CERT Advisory ]

=============================================================================
CERT* Advisory CA-98.01.smurf
Original issue date: Jan. 05, 1998
Last revised: --

Topic: "smurf" IP Denial-of-Service Attacks
- ------------------------------------------------------------------------------

This advisory is intended primarily for network administrators responsible for
router configuration and maintenance.

The attack described in this advisory is different from the denial-of-service
attacks described in CERT advisory CA-97.28.

The CERT Coordination Center has received reports from network service
providers (NSPs), Internet service providers (ISPs), and other sites of
continuing denial-of-service attacks involving forged ICMP echo request
packets (commonly known as "ping" packets) sent to IP broadcast
addresses. These attacks can result in large amounts of ICMP echo reply
packets being sent from an intermediary site to a victim, which can cause
network congestion or outages. These attacks have been referred to as "smurf"
attacks because the name of one of the exploit programs attackers use to
execute this attack is called "smurf."

The CERT/CC urges you to take the steps described in Section III to reduce the
potential that your site can be used as the origination site (Sec. III.C) or
an intermediary (Sec. III.A.) in this attack. Although there is no easy
solution for victim sites, we provide some recommendations in Sec. III.B.

We will update this advisory as we receive additional information. Please
check our advisory files regularly for updates that relate to your site.

- ------------------------------------------------------------------------------

I.   Description

The two main components to the smurf denial-of-service attack are the use of
forged ICMP echo request packets and the direction of packets to IP broadcast
addresses.

The Internet Control Message Protocol (ICMP) is used to handle errors and
exchange control messages. ICMP can be used to determine if a machine on the
Internet is responding. To do this, an ICMP echo request packet is sent to a
machine. If a machine receives that packet, that machine will return an ICMP
echo reply packet. A common implementation of this process is the "ping"
command, which is included with many operating systems and network software
packages. ICMP is used to convey status and error information including
notification of network congestion and of other network transport
problems. ICMP can also be a valuable tool in diagnosing host or network
problems.

On IP networks, a packet can be directed to an individual machine or broadcast
to an entire network. When a packet is sent to an IP broadcast address from a
machine on the local network, that packet is delivered to all machines on that
network. When a packet is sent to that IP broadcast address from a machine
outside of the local network, it is broadcast to all machines on the target
network (as long as routers are configured to pass along that traffic).

IP broadcast addresses are usually network addresses with the host portion of
the address having all one bits. For example, the IP broadcast address for the
network 10.0.0.0 is 10.255.255.255. If you have subnetted your class A network
into 256 subnets, the IP broadcast address for the 10.50 subnet would be
10.50.255.255. Network addresses with all zeros in the host portion, such as
10.50.0.0, can also produce a broadcast response.

In the "smurf" attack, attackers are using ICMP echo request packets directed
to IP broadcast addresses from remote locations to generate denial-of-service
attacks. There are three parties in these attacks: the attacker, the
intermediary, and the victim (note that the intermediary can also be a
victim).

The intermediary receives an ICMP echo request packet directed to the IP
broadcast address of their network. If the intermediary does not filter ICMP
traffic directed to IP broadcast addresses, many of the machines on the
network will receive this ICMP echo request packet and send an ICMP echo reply
packet back. When (potentially) all the machines on a network respond to this
ICMP echo request, the result can be severe network congestion or outages.

When the attackers create these packets, they do not use the IP address of
their own machine as the source address. Instead, they create forged packets
that contain the spoofed source address of the attacker's intended victim. The
result is that when all the machines at the intermediary's site respond to the
ICMP echo requests, they send replies to the victim's machine. The victim is
subjected to network congestion that could potentially make the network
unusable. Even though we have not labeled the intermediary as a "victim," the
intermediary can be victimized by suffering the same types of problem that the
"victim" does in these attacks.

Attackers have developed automated tools that enable them to send these
attacks to multiple intermediaries at the same time, causing all of the
intermediaries to direct their responses to the same victim. Attackers have
also developed tools to look for network routers that do not filter broadcast
traffic and networks where multiple hosts respond. These networks can the
subsequently be used as intermediaries in attacks.

For a more detailed description of the "smurf" attack, please consult
this document:

    "The Latest in Denial of Service Attacks: 'Smurfing':
        Description and Information to Minimize Effects"
    Author: Craig Huegen <chuegen@quadrunner.com>
    URL: http://www.quadrunner.com/~chuegen/smurf.txt


II.  Impact

Both the intermediary and victim of this attack may suffer degraded network
performance both on their internal networks or on their connection to the
Internet. Performance may be degraded to the point that the network cannot be
used.

A significant enough stream of traffic can cause serious performance
degradation for small and mid-level ISPs that supply service to the
intermediaries or victims. Larger ISPs may see backbone degradation and
peering saturation.


III. Solution

A. Solutions for the Intermediary

1. Disable IP-directed broadcasts at your router.

One solution to prevent your site from being used as an intermediary in this
attack is to disable IP-directed broadcasts at your router. By disabling these
broadcasts, you configure your router to deny IP broadcast traffic onto your
network from other networks. In almost all cases, IP-directed broadcast
functionality is not needed.

Appendix A contains details on how to disable IP-directed broadcasts for some
router vendors. If your vendor is not listed, contact that vendor for
instructions.

You should disable IP-directed broadcasts on all of your routers. It is not
sufficient to disable IP-directed broadcasts only on the router(s) used for
your external network connectivity. For example, if you have five routers
connecting ten LANs at your site, you should turn off IP-directed broadcasts
on all five routers.

2. Configure your operating system to prevent the machine from responding to
   ICMP packets sent to IP broadcast addresses.

If an intruder compromises a machine on your network, the intruder may try to
launch a smurf attack from your network using you as an intermediary. In this
case, the intruder would use the compromised machine to send the ICMP echo
request packet to the IP broadcast address of the local network. Since this
traffic does not travel through a router to reach the machines on the local
network, disabling IP-directed broadcasts on your routers is not sufficient to
prevent this attack.

Some operating systems can be configured to prevent the machine from
responding to ICMP packets sent to IP broadcast addresses. Configuring
machines so that they do not respond to these packets can prevent your
machines from being used as intermediaries in this type of attack.

Appendix A also contains details on how to disable responding to ICMP packets
sent to IP broadcast addresses on some operating systems. If your operating
system is not listed, contact your vendor for instructions.


B. Solutions for the Victim

Unfortunately, there is no easy solution for victims receiving the
potentially large number of ICMP echo reply packets. ICMP echo reply traffic
(the traffic from the intermediary) could be blocked at the victim's router;
however, that will not necessarily prevent congestion that occurs between the
victim's router and the victim's Internet service provider. Victims receiving
this traffic may need to consult with their Internet service provider to
temporarily block this type of traffic in the ISP's network.

Additionally, victims in this position should contact the intermediaries and
inform them of the attack and of the steps described in the previous
section. (Please refer them to http://www.cert.org/pub/alerts.html or
ftp://ftp.cert.org/pub/cert_advisories/ for the most recent version of this
advisory.)

Victims can use the "whois" command to obtain contact information for
the sites. More information on using whois is available in

        ftp://ftp.cert.org/pub/whois_how_to


C. Solution for the Site Where Attacks Originate

We recommend filtering outgoing packets that contain a source address from a
different network.

Attacks like the smurf attack rely on the use of forged packets, that is,
packets for which the attacker deliberately falsifies the origin address. With
the current IP protocol technology, it is impossible to eliminate IP-spoofed
packets. However, you can use filtering to reduce the likelihood of your
site's networks being used to initiate forged packets.

As we mentioned in CERT advisory CA-97.28 on Teardrop and Land
denial-of-service attacks, the best current method to reduce the number of
IP-spoofed packets exiting your network is to install filtering on your
routers that requires packets leaving your network to have a source
address from your internal network. This type of filter prevents a source
IP-spoofing attack from your site by filtering all outgoing packets that
contain a source address from a different network.

A detailed description of this type of filtering is available in the
Internet Draft "Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing" by Paul Ferguson of
Cisco Systems, Inc. and Daniel Senie of Blazenet, Inc. We recommend it
to both Internet Service Providers and sites that manage their own
routers. The document is currently available at

http://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt

Note that although this document is labeled as an IETF "working draft," the
content is complete and it is being proposed as an Informational RFC. Because
this is an Internet Draft, it will only be available under the above URL for
several months. When the document is available as an RFC or otherwise, we will
update the URL in this advisory.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, the CERT/CC did not hear from that
vendor. Please contact the vendor directly.


Cray Research - A Silicon Graphics Company
==========================================
Current versions of Unicos and Unicos/mk do not have the ability to
reject ICMP requests send to broadcast addresses.  We are tracking
this problem through SPR 709733.


Cisco Systems
=============
Cisco recommends the following configuration settings as protection against
being used as an intermediary in smurf attacks:

1. Disabling IP directed broadcast for all interfaces on which it is
   not needed. This must be done on all routers in the network, not
   just on the border routers. The command "no ip directed-broadcast"
   should be applied to each interface on which directed broadcasts
   are to be disabled.

   Very few IP applications actually need to use directed broadcasts,
   and it's extremely rare for such an application to be in use in a network
   without the knowledge of the network administrator. Nonetheless,
   as when any functionality is disabled, you should be alert for
   possible problems.

   This is the preferred solution for most networks.

2. If your network configuration is simple enough for you to create
   and maintain a list of all the directed broadcast addresses in
   your network, and if you have a well-defined perimeter separating
   your own network from potentially hostile networks, consider
   using a filter at the perimeter to prevent directed broadcasts from
   entering the network. For example, if your network number is
   172.16.0.0, and you uniformly use a subnet mask of 255.255.255.0,
   then you might use a Cisco access list entry like

     access-list 101 deny ip 0.0.0.0 255.255.255.255 172.16.0.255 0.0.255.0

   Note that this is not a complete access list; it's simply a single
   entry. See the Cisco documentation for more information on configuring
   access lists. The best place to apply such a filter is usually on
   the incoming side of each router interface that connects to the
   potentially hostile network.

   This solution may be administratively infeasible for networks using
   variable-length subnet masks, or which have complex external
   connectivity. There is also some possibility that legitimate
   directed broadcasts may be being sent into your network from the
   outside, especially if you're working in a research environment.

In addition to these protections against being used as an intermediary in a
smurf attack, Cisco recommends that you take steps to prevent users within
your own network from launching such attacks. For "stub" networks which do
not provide transit connectivity (most corporate and institutional
networks, many smaller ISPs), this is usually best done by installing
filters at the network perimeter to prevent any packets from leaving
your network unless their IP source addresses actually lie within
your network's address space. For the example network above, you might
place the following entry in the incoming access lists on the interface(s)
facing your internal network:

   access-list 101 permit ip 172.16.0.0 0.0.255.255 0.0.0.0 255.255.255.255
   access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255


FreeBSD, Inc.
=============
In FreeBSD 2.2.5 and up, the tcp/ip stack does not respond to icmp
echo requests destined to broadcast and multicast addresses by default. This
behaviour can be changed via the sysctl command via
mib net.inet.icmp.bmcastecho.


IBM Corporation
===============
AIX 4
- ------
There is a network attribute called "bcastping" that controls whether
or not responses to ICMP echo packets to the broadcast address are
allowed.  A value of zero turns off responses and a value of one
turns them on.  The default is zero (i.e., by default AIX version 4
is not vulnerable to the described denial-of-service attack).

Use the following command to check the value of the bcastping
attribute:

   $ no -o bcastping

Use the following command to turn off responses to ICMP broadcast
packets (as root):

   # no -o bcastping=0


AIX 3
- ------
The "bcastping" attribute does not exist in version 3.

IBM and AIX are registered trademarks of International Business Machines
Corporation.


Livingston Enterprises, Inc.
============================
Livingston Enterprises products discard any ICMP packets directed to
broadcast addresses, so we protect against this form of attack.  No
special configuration is required.


The NetBSD Project
==================
Under NetBSD you can disable directed broadcast with this command,
as root:

        # sysctl -w net.inet.ip.directed-broadcast=0

- ------------------------------------------------------------------------------
The CERT Coordination Center thanks Craig A. Huegen. Much of the content in
this advisory has been derived from his document on "smurf" attacks. The CERT
Coordination Center also thanks Paul Ferguson and Daniel Senie for providing
information on network ingress filtering, and John Bashinski of Cisco for his
contributions.
- ------------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).

[ End CERT Advisory ]

______________________________________________________________________________

CIAC wishes to acknowledge the contributions of CERT for the
information contained in this bulletin.
______________________________________________________________________________


CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 510-422-8193
    FAX:      +1 510-423-8002
    STU-III:  +1 510-423-2604
    E-mail:   ciac@llnl.gov

For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 510-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:      http://www.ciac.org/
                        (or http://ciac.llnl.gov -- they're the same machine)
   Anonymous FTP:       ftp.ciac.org
                        (or ciac.llnl.gov -- they're the same machine)
   Modem access:        +1 (510) 423-4753 (28.8K baud)
                        +1 (510) 423-3331 (28.8K baud)

CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
   information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
   (SPI) software updates, new features, distribution and
   availability;
3. SPI-NOTES, for discussion of problems and solutions regarding the
   use of SPI products.

Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:

E-mail to       ciac-listproc@llnl.gov or majordomo@tholia.llnl.gov:
        subscribe list-name
  e.g., subscribe ciac-bulletin

You will receive an acknowledgment email immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the email.  This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.

If you include the word 'help' in the body of an email to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via email, etc.

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

I-011: IBM AIX portmir command Vulnerability
I-012: IBM AIX ftp client Vulnerability
I-013: Count.cgi Buffer Overrun Vulnerabiliity
I-014: Vulnerability in GlimpseHTTP and WebGlimpse cgi-bin Packages
I-015: SGI IRIX Vulnerabilities (syserr and permissions programs)
I-016: SCO  /usr/bin/X11/scoterm Vulnerability
I-017: statd Buffer Overrun Vulnerability
I-018: FTP Bounce Vulnerability
I-019: Tools Generating IP Denial-of-Service Attacks
I-020: Cisco 7xx password buffer overflow - DOS



-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition

iQCVAwUBNLLA+rnzJzdsy3QZAQEvnQQA5cPY9JobKhB8tZ9CY4WkXlfkmozNRa7Y
eKhDjBboKX8M9y5bxd2UqTUqX4Jpc78+R3jNvDeD0/2xBDqD7wsWKzOVCF2hJ47Z
R9qyg9iNVSu4mSwZq2HJT3MFBo072/Q2KB7VNJtVe1TsnqLjKwgrleUcokBrbjk5
XrMpmCzDOoA=
=NPB9
-----END PGP SIGNATURE-----