Published:
16 July 1998
Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-98.114 -- CIAC Bulletin I-070
Distributed DoS Attack Against NIS/NIS+ Networks
17 July 1998
===========================================================================
U.S. Department of Energy Computer Incident Advisory Capability (CIAC)
has released the following advisory concerning a vulnerability in the
NIS/NIS+ system. This vulnerability may allow remote users to
perform a denial of service attack upon a host and its associated
local network, including all hosts on that network.
The following security bulletin is provided as a service to AusCERT's
members. As AusCERT did not write this document, AusCERT has had
no control over its content. As such, the decision to use any or
all of this information is the responsibility of each user or
organisation, and should be done so in accordance with site policies
and procedures.
NOTE: This is only the original release of the security bulletin.
It will not be updated when the original bulletin is. If downloading
at a later date, it is recommended that the bulletin is retrieved
from the original authors to ensure that the information is still
current.
Contact information for CIAC is included in the Security Bulletin
below. If you have any questions or need further information,
please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/Information/advisories.html
If you believe that your system has been compromised, contact
AusCERT or your representative in FIRST (Forum of Incident Response
and Security Teams).
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for emergencies.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_ /
\___ __|__ / \___
__________________________________________________________
INFORMATION BULLETIN
Distributed DoS Attack Against NIS/NIS+ Networks
July 15, 1998 20:00 GMT Number I-070
______________________________________________________________________________
PROBLEM: The finger service is being used in attacks on NIS servers.
PLATFORM: NIS servers
DAMAGE: If exploited, the attacker may cause a denial of service.
SOLUTION: Disable finger or apply workaround listed below under
"Recommended action".
______________________________________________________________________________
VULNERABILITY Avoid using finger if it is allowed to do ambiguous lookups. If
ASSESSMENT: the finger service is required for some specific purpose, limit
it to the minimum number of restricted hosts or to hosts which
are NOT participating in NIS.
______________________________________________________________________________
[ Start ISS Advisory ]
ISS Security Alert Advisory
June 29, 1998
Distributed DoS attack against NIS/NIS+ based networks.
For purposes of this report, NIS refers to both NIS and NIS+
as this problem has been observed and reproduced on both services.
Synopsis:
It is possible, through a well orchestrated attack using the finger
service against multiple NIS clients, to disrupt an entire NIS based
network and/or starve the NIS servers for resources. The problem is
in the finger service but the attack causes long duration, network-wide,
congestion and resource exhaustion on NIS servers.
Recommended action:
Disable finger service on any systems connected to any NIS based
network. Disable access to internal finger services at all perimeter
defenses (firewalls, gateways, filtering routers, etc.). If the finger
service is required for some specific purpose, limit it to the minimum
number of restricted hosts or to hosts which are NOT participating
in NIS.
For those who wish to continue to run the finger service on their
systems, there are other possible actions that could be taken, like using
a public domain fingerd that doesn't do ambiguous lookups. The finger
service can also be protected by even something as simple as wrapping
finger to not do ambiguous lookups like as follows:
# mv /usr/bin/finger /usr/bin/finger.exe
# cat > /usr/bin/finger
#!/bin/sh
exec /usr/bin/finger.exe -m $*
^D
# chmod +x /usr/bin/finger
These recommendations would permit the continued safe use of finger
(or as safe as finger ever gets).
Description:
A finger request results in multiple NIS requests as the responding
daemon attempts to locate all account records matching the finger request.
A request for finger foo@bar.com will result in one finger daemon searching
incrementally through all of the entries in the passwd map to locate any
accounts with foo in the name. As a consequence, a single finger request
can result in a significantly larger amount of traffic between the NIS
client and the NIS server than the originating traffic to and from the
finger service. The amount of NIS traffic is dependent on the size of
the NIS passwd map. With a passwd map of 10,000 entries, a single finger
request would result in roughly 10,000 NIS requests and 10,000 NIS responses.
This does NOT count retries from packet loss or other failures (a highly
significant factor in this attack).
By sending a large number of overlapping finger requests to a single
host, it is possible to load that host down with a very significant amount of
traffic just processing the NIS requests. If this is done to multiple hosts,
the network traffic rises dramatically.
Eventually, a condition arises in which congestion and/or resource
exhaustion on the NIS server begin to cause a significant rise in lost
packets and failed requests. This results in retry attempts from the
NIS clients, adding to the already overloaded network traffic. The
failure / retry / failure cycle becomes an NIS traffic "storm" in which the
retry traffic dominates and little other traffic can squeeze through.
Network congestion combined with NIS server resource exhaustion
work together to not only deny service to the requesting clients but also
to rapidly clog the network bandwidth and render the network unusable by
anything on the network.
Analysis and details:
In analyzing this attack, a perl script was used to generate finger
traffic attacking a dozen hosts with four finger requests for each of
approximately 100 names (~400 finger requests per host). A demonstration
NIS map of approximately 1000 accounts was used. At an issue rate of
approximately 4 finger requests every two seconds against a given host,
10's to 100's of lingering finger requests would build up even as some
finger requests would be fufilled. These lingering finger processes
would be attempting to paw their way through the entire NIS password map.
A typical test run attack lasted approximately 30-50 seconds in duration.
During analysis of this attack, network traffic from even a short
~30 seconds blast from the perl test script resulted in traffic levels that
caused network disruptions extending for as much as 45 minutes to an hour
after cessation of the attack. During this time, some systems were impacted
to the extent that screen savers froze and systems were unresponsive to the
keyboards. Many systems were left with seemingly hung finger processes.
These stayed on the system for a half an hour or more while the network
congestion cleared. Some systems ran out of swap space because of the
resource demands of the finger processes. On a few of the test runs the
network traffic was observed to have risen to a level which caused a
switched ethernet hub to disable ports due to excesive collisions.
Finger requests to perform this action have to be distributed and
timed properly. Too many requests, too quickly, seem to result in inetd
disabling the finger service. Too slowly, and the network traffic rises too
slowly and fails to reach the catastrophic level where packet loss and retries
become the dominant traffic input to the network.
Because the finger requests are TCP based and not dependent on
preauthentication, finger requests can still be delivered by the attacker
to the systems under attack even in the face of increasing network congestion.
By the time the attacking connections are significantly impacted by the
network congestion, the network has been rendered unusable by systems
requiring NIS or other services.
Timed correctly, an attack of only a few seconds, targeting as few
as a dozen NIS clients on a network with a moderate NIS passwd map can render
even a small network unusable for as long as a half an hour to an hour or
more. Increasing the size of the NIS passwd map, the number of attacked
clients, or the number of requests sent to any given client causes the
recovery time to extend out dramatically and disproportionately to any
particular increases in any particular factor.
If the NIS server is also one of the attacked systems, it can
rapidly run out of system resources, causing NIS request failures and
accelerating the resulting NIS traffic "storm". When the NIS server
was one of the systems attacked by finger requests, it was not unusual
to see warnings about unable to grow stack, exhausted virtual memory, or
other resource related errors.
MOST client systems seem to clean themselves up EVENTUALLY. This
can take anywhere from a few moments for some Linux boxes, to a significant
fraction of an hour for some SUN boxes. It was observed that some IRIX
boxes and AIX boxes would become unreachable from the network and
unresponsive to the keyboard, requiring a power cycle to recover.
These last systems may have recovered on their own eventually, but that
time frame appears to be geological. Recovery time seems to also be
dependent on the recovery time of the NIS server for those clients which
were observed to recover. Resetting the targeted systems permits the
network to recover. All tested systems were affected to some extent.
Because the resulting traffic and congestion is proportional to the
size of the NIS passwd map times the number of attacked hosts times the
number of requests in the attack, large networks are disproportionately
vulnerable to this attack. Even small networks of a few dozen systems
can be disabled by a determined attacker if they have a sufficiently
large NIS passwd map.
Conclusion:
The finger service permits a condition where a limited number
of requests can result in a vastly larger number of internal requests
against a central naming service such as NIS. This permits an attacker
to mount a distributed attack by launching smaller attacks against numerous
hosts. These combine to form a disasterous level of congestion on the
internal systems, disrupting an internal network for an extended period
of time.
Afterword:
It is unknown, at this time, if any other services exhibit similar
characteristics with regard to NIS traffic as does finger. Disabling finger
prevents it from being exploited against a network. It obviously does
not guarantee that some other service might be similarly exploitable.
Credits:
We would like to extend our appreciation to Sun Microsystems, Inc.
for their assistance and consultation with regard to the vulnerability.
Michael H. Warfield
Senior Researcher
ISS X-Force
Internet Security Systems, Inc.
________
Copyright (c) 1998 by Internet Security Systems, Inc.
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of X-Force. If you wish to reprint the whole or any part
of this alert in any other medium excluding electronic medium, please
email xforce@iss.net for permission.
Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in connection
with the use or spread of this information. Any use of this information is
at the user's own risk.
X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html
as well as on MIT's PGP key server and PGP.com's key server.
X-Force Vulnerability and Threat Database: http://www.iss.net/xforce
Please send suggestions, updates, and comments to:
X-Force <xforce@iss.net> of Internet Security Systems, Inc.
[ End ISS Advisory ]
______________________________________________________________________________
CIAC wishes to acknowledge the contributions of Internet Security Systems,
Inc. 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 925-422-8193
FAX: +1 925-423-8002
STU-III: +1 925-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 925-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 (925) 423-4753 (28.8K baud)
+1 (925) 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-060: SGI IRIX OSF/DCE Denial of Service Vulnerability
I-061: SGI IRIX mediad(1M) Vulnerability
I-062: SGI IRIX BIND DNS named(1M) Vulnerability
I-063: RSI BSDI rlogind Vulnerability
I-064: SGI IRIX mail(1), rmail(1M), sendmail(1M) Vulnerabilities
I-065: SunOS ufsrestore Buller Overflow Vulnerability
I-066: Vulnerability in Some Implementations of PKCS#1
I-067: AutoStart 9805 Macintosh Worm Virus
I-068: File Access Issue With Internet Information Server
I-069: Buffer overflows in some POP servers
- -----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
iQCVAwUBNa4qXbnzJzdsy3QZAQGZXQQAm1ACI7dkXjDvBmnRdLARc9wK0rrGP/cq
+n1UsHeMzuqWeV897AoZtH+sls/znsaPubbeUo71raBEFkRKiL87EAqtL6IDR9pm
ENn6TepZCEOJuk4iPMMhUwGx7tT3GBOWJkq2BhfZ07IfL1VnsD7RntxdxOvrOToX
dDVF6gSuP8o=
=8CPm
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
iQCVAwUBNbX2GSh9+71yA2DNAQF2HgP8DCclQkxUNY3OPOAJhpI+S3qZ5cPtkClW
ioDCiMgRxeyKPk1S82eNo0GJjTvUVoFtvrRroRKzHZ8BYDAGxjhbSNUsY00NV1xM
nYdW3LeGy3PBkeF21aOnwHKkurXKOk1G3lFwDkPZIsY73fdD9OaVeyvdYrI+XS4T
1hupctIITm8=
=OEMH
-----END PGP SIGNATURE-----