what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

d-19.anon-ftp-server-attack

d-19.anon-ftp-server-attack
Posted Sep 23, 1999

d-19.anon-ftp-server-attack

SHA-256 | d9e1efcc4428174f8cf1ccd00ff0b69191c1ad21667822b671feaf8f02366d69

d-19.anon-ftp-server-attack

Change Mirror Download
            _____________________________________________________
The Computer Incident Advisory Capability
___ __ __ _ ___
/ | / \ /
\___ __|__ /___\ \___
_____________________________________________________

INFORMATION BULLETIN

Wide-spread Attacks on Anonymous FTP Servers

July 15, 1993 1100 PDT Number D-19
__________________________________________________________________________
PROBLEM: Wide-spread abuse of anonymous FTP servers.
PLATFORM: All systems supporting TCP/IP networking and anonymous FTP.
DAMAGE: Unauthorized access to data, denial of service.
SOLUTION: Verify that anonymous FTP has been properly configured.
__________________________________________________________________________

Critical Information about Attacks on Anonymous FTP Servers

The CERT Coordination Center has released the enclosed advisory
describing a large number of attacks on improperly configured
anonymous FTP servers. The attacks described can result in compromise
of the system, excessive use of disk space resulting in denial of
service, or the transfer of sensitive or copyrighted information.
CIAC recommends that sites examine local systems to ensure that any
operating FTP servers are configured in a secure fashion.

Please note that while the CERT Advisory primarily addresses the
configuration of anonymous FTP on UNIX systems, a number of other
operating systems also support FTP servers, including OpenVMS using
packages such as MultiNet, and MS-DOS and Macintosh systems using
communications software such as NCSA Telnet or FTPd. The
configuration of FTP servers on these machines also requires careful
attention in order to avoid unauthorized or undesired use.

CIAC recommends the following guidelines for the configuration of
FTP servers:

1. If a system has no need to provide FTP service for other
machines on the network, the server should be disabled. This
will prevent unauthorized access to the system using FTP.

For example, to disable NCSA Telnet's FTP server, place the
statement "ftp=no" in the configuration file config.tel. On
most UNIX systems, removing the line for ftpd from the file
/etc/inetd.conf and then restarting inetd will disable the FTP
server.

2. If an FTP server is necessary, the need for anonymous service
should be evaluated. Anonymous FTP allows access to some of
the system's file space without requiring a password for
authentication, and unless carefully controlled can lead to
abuse of the system. If an anonymous FTP server is not
required on a particular host, that feature should be disabled.

Both MultiNet on OpenVMS systems and the FTP software on most
UNIX systems disable anonymous service by default. An account
with username "ftp" ("ANONYMOUS" in MultiNet) must be created
before anonymous logins will be accepted. The converse is true
of NCSA Telnet; unauthenticated logins are accepted by default
when the FTP server is enabled. A file containing authorized
usernames and passwords must be created using the telpass
utility in order to disable anonymous connections.

3. If an anonymous FTP server is necessary, the access of
anonymous connections should be restricted to a carefully
controlled number of files and the ability of a remote user to
store files on the server should be disabled or limited.

For example, the Macintosh program FTPd allows access controls
to be specified for each user, including anonymous users. The
set of accessible drives, folders, and files that a user is
permitted to work with, as well as the operations that they
may perform, can be carefully controlled, thus avoiding
unwanted or unauthorized access.

For additional information or assistance with the configuration of a
specific FTP server, please contact CIAC at (510) 422-8193 or send
E-mail to ciac@llnl.gov. FAX messages to (510) 423-8002.

[Beginning of CERT Advisory]
===========================================================================
CA-93:10 CERT Advisory
July 14, 1993
Anonymous FTP Activity

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

The CERT Coordination Center has been receiving a continuous stream of
reports from sites that are experiencing unwanted activities within their
anonymous FTP areas. We recognize that this is not a new problem, and we
have been striving to handle requests for assistance on a one-to-one basis
with the reporting administrator. However, since this activity does not seem
to be diminishing, CERT believes that a broad distribution of information
concerning this problem and corresponding solution suggestions should help
to address the widespread nature of this activity.

We are seeing three types of activity regarding anonymous FTP areas.

A. Improper configurations leading to system compromise.

B. Excessive transfer of data causing deliberate over-filling of
disk space thus leading to denial of service.

C. Use of writable areas to transfer copyrighted software and other
sensitive information.

This advisory provides an updated version of the anonymous FTP configuration
guidelines that is available from CERT. The purpose of these guidelines is
to assist system administrators at sites that offer anonymous FTP services.
These guidelines are intended to aid a system administrator in configuring
anonymous FTP capabilities so as to minimize unintended use of services or
resources. Systems administrators should be aware that anonymous FTP
capabilities should be configured and managed according to the policies
established for their site.

You may obtain future copies of these guidelines through anonymous FTP from
cert.org in /pub/tech_tips/anonymous_ftp.

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


ANONYMOUS FTP CONFIGURATION GUIDELINES

Anonymous FTP can be a valuable service if correctly configured and
administered. The first section of this document provides general guidance in
initial configuration of an anonymous FTP area. The second section addresses
the issues and challenges involved when a site wants to provide writable
directories within their anonymous FTP areas. The third section provides
information about previous CERT advisories related to FTP services.

The following guidelines are a set of suggested recommendations that have been
beneficial to many sites. CERT recognizes that there will be sites that have
unique requirements and needs, and that these sites may choose to implement
different configurations.

I. Configuring anonymous FTP

A. FTP daemon

Sites should ensure that they are using the most recent version
of their FTP daemon.

B. Setting up the anonymous FTP directories

The anonymous FTP root directory (~ftp) and its subdirectories
should not be owned by the ftp account or be in the same group as
the ftp account. This is a common configuration problem. If any of
these directories are owned by ftp or are in the same group as the
ftp account and are not write protected, an intruder will be able to
add files (such as a .rhosts file) or modify other files. Many sites
find it acceptable to use the root account. Making the ftp root
directory and its subdirectories owned by root, part of the system
group, and protected so that only root has write permission will help
to keep your anonymous FTP service secure.

Here is an example of an anonymous FTP directory setup:

drwxr-xr-x 7 root system 512 Mar 1 15:17 ./
drwxr-xr-x 25 root system 512 Jan 4 11:30 ../
drwxr-xr-x 2 root system 512 Dec 20 15:43 bin/
drwxr-xr-x 2 root system 512 Mar 12 16:23 etc/
drwxr-xr-x 10 root system 512 Jun 5 10:54 pub/

Files and libraries, especially those used by the FTP daemon and
those in ~ftp/bin and ~ftp/etc, should have the same protections
as these directories. They should not be owned by ftp or be in the
same group as the ftp account; and they should be write protected.

C. Using proper password and group files

We strongly advise that sites not use the system's /etc/passwd file as
the password file or the system's /etc/group as the group file in the
~ftp/etc directory. Placing these system files in the ~ftp/etc
directory will permit intruders to get a copy of these files.
These files are optional and are not used for access control.

We recommend that you use a dummy version of both the ~ftp/etc/passwd
and ~ftp/etc/group files. These files should be owned by root. The
dir command uses these dummy versions to show owner and group
names of the files and directories instead of displaying arbitrary
numbers.

Sites should make sure that the ~/ftp/etc/passwd file contains no
account names that are the same as those in the system's /etc/passwd
file. These files should include only those entries that are relevant
to the FTP hierarchy or needed to show owner and group names. In
addition, ensure that the password field has been cleared. The
examples below show the use of asterisks (*) to clear the password
field.

Below is an example of a passwd file from the anonymous FTP area on
cert.org:

ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::
cops:*:3271:20:COPS Distribution::
cert:*:9920:20:CERT::
tools:*:9921:20:CERT Tools::
ftp:*:9922:90:Anonymous FTP::
nist:*:9923:90:NIST Files::

Here is an example group file from the anonymous FTP area on cert.org:

cert:*:20:
ftp:*:90:


II. Providing writable directories in your anonymous FTP configuration

There is a risk to operating an anonymous FTP service that permits
users to store files. CERT strongly recommends that sites do not
automatically create a "drop off" directory unless thought has been
given to the possible risks of having such a service. CERT has received
many reports where these directories have been used as "drop off"
directories to distribute bootlegged versions of copyrighted software or
to trade information on compromised accounts and password files. CERT
has also received numerous reports of files systems being maliciously
filled causing denial of service problems.

This section discusses three ways to address these problems. The first is
to use a modified FTP daemon. The second method is to provide restricted
write capability through the use of special directories. The third method
involves the use of a separate directory.

A. Modified FTP daemon

If your site is planning to offer a "drop off" service, CERT suggests
using a modified FTP daemon that will control access to the "drop off"
directory. This is the best way to prevent unwanted use of writable
areas. Some suggested modifications are:

1. Implement a policy where any file dropped off cannot
be accessed until the system manager examines the file
and moves it to a public directory.
2. Limit the amount of data transferred in one session.
3. Limit the overall amount of data transferred based on
available disk space.
4. Increase logging to enable earlier detection of abuses.

For those interested in modifying the FTP daemon, source code is
usually available from your vendor. Public domain sources are
available from:

wuarchive.wustl.edu ~ftp/packages/wuarchive-ftpd
ftp.uu.net ~ftp/systems/unix/bsd-sources/libexec/ftpd
gatekeeper.dec.com ~ftp/pub/DEC/gwtools/ftpd.tar.Z

The CERT Coordination Center has not formally reviewed, evaluated,
or endorsed the FTP daemons described. The decision to use the FTP
daemons described is the responsibility of each user or organization,
and we encourage each organization to thoroughly evaluate these
programs before installation or use.

B. Using protected directories

If your site is planning to offer a "drop off" service and is unable
to modify the FTP daemon, it is possible to control access by using a
maze of protected directories. This method requires prior coordination
and cannot guarantee protection from unwanted use of the writable FTP
area, but has been used effectively by many sites.

Protect the top level directory (~ftp/incoming) giving only execute
permission to the anonymous user (chmod 751 ~ftp/incoming). This will
permit the anonymous user to change directory (cd), but will not allow
the user to view the contents of the directory.

drwxr-x--x 4 root system 512 Jun 11 13:29 incoming/

Create subdirectories in the ~ftp/incoming using names known only
between your local users and the anonymous users that you want to
have "drop off" permission. The same care used in selecting passwords
should be taken in selecting these subdirectory names because the
object is to choose names that cannot be easily guessed. Please do not
use our example directory names of jAjwUth2 and MhaLL-iF.

drwxr-x-wx 10 root system 512 Jun 11 13:54 jAjwUth2/
drwxr-x-wx 10 root system 512 Jun 11 13:54 MhaLL-iF/

This will prevent the casual anonymous FTP user from writing files in
your anonymous FTP file system. It is important to realize that this
method does not protect a site against the result of intentional or
accidental disclosure of the directory names. Once a directory name
becomes public knowledge, this method provides no protection at all
from unwanted use of the area. Should a name become public, a site
may choose to either remove or rename the writable directory.

C. Using a single disk drive

If your site is planning to offer a "drop off" service and is
unable to modify the FTP daemon, it may be desirable to limit
the amount of data transferred to a single file system mounted
as ~ftp/incoming.

If possible, dedicate a disk drive and mount it as ~ftp/incoming.
If this dedicated disk becomes full, it will not cause a denial
of service problem.

The system administrator should monitor this directory (~ftp/incoming)
on a continuing basis to ensure that it is not being misused.


III. Related CERT Advisories

The following CERT Advisories directly relate to FTP daemons or impact
on providing FTP service:

CA-93:06.wuarchive.ftpd.vulnerability
CA-92:09.AIX.anonymous.ftp.vulnerability
CA-88:01.ftpd.hole

Past advisories are available for anonymous FTP from cert.org.


Copyright (c) Carnegie Mellon University 1993



---------------------------------------------------------------------------
[End of CERT Advisory]

Previous CIAC Bulletins and other information are available via
anonymous FTP from irbis.llnl.gov (IP address 128.115.19.60).

PLEASE NOTE: Many users outside of the DOE and ESnet 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 by sending email to docserver@first.org
with an empty subject line and a message body containing the line:
send first-contacts.

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, expressed or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, 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 nor
the University of California, and shall not be used for advertising or
product endorsement purposes.

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close