CERT
 
US-CERT Vulnerability Notes Database CERT Statistics Vulnerability Disclosure Policy CERT Knowledgebase Courses Link to US-CERT cylab
 

CERT® Coordination Center

Anonymous FTP Abuses


I. Description

II. Technical issues

III. What you can do

  1. Detection
  2. Reaction
  3. Prevention

IV. Additional measures that you can take


I. Description

This document provides a general overview of problems associated with abuses of anonymous FTP (File Transfer Protocol) areas. It includes information that will help you respond to and recover from such activity.

This document addresses two issues relating to anonymous FTP abuse:

  • Software piracy (the distribution of stolen software, copyrighted or proprietary materials, or similar information)
  • Misconfigured/compromised FTP servers

Anonymous archives may be provided in a number of ways, most commonly through anonymous FTP (although similar services can be provided via other protocols and tools). Some sites configure their anonymous FTP servers to allow writable areas (for example, to make available incoming or "drop-off" directories for files being sent to the site). If these files can be *read* by anonymous FTP users, then the potential for abuse exists.

Abusers often gather and distribute lists describing the locations of vulnerable sites and the information these sites contain. The lists commonly include the names of writable directories and the locations of pirated software; they may also include password files and/or other sensitive information.

Unfortunately, there have been many cases in which system administrators are unaware that this abuse is taking place on their archive. They may be unfamiliar with this type of abuse (and so haven't taken steps to prevent it), or they may think that they have configured the archive to prevent abuse when, in fact, they have not. System administrators at the sites being used to place/pick up items from the drop-off area may also not be aware that their users are participating in this activity.

Finally, an anonymous archive server actually may be misconfigured or compromised. Vulnerabilities in the FTP server software itself could, in addition to the abuses mentioned above, allow intruders to execute code with the privileges of the running FTP server (often root on UNIX systems). This can result in a complete compromise of security on the affected systems.

II. Technical issues

  • A file can be placed in the writable area of the anonymous FTP server. If this area is also readable, anyone who can connect to the anonymous FTP server can obtain a copy of the file.
  • Specifically, abusers often do the following:

    • Store and retrieve information. This information is often placed in unusual or hidden files (e.g., files that start with a period or space and normally not shown by "ls") that may be placed in hidden directories, possibly nested within several layers and not readily apparent.
    • Gather information about the availability of sites where the anonymous FTP areas are abused, then compile a comprehensive listing (known as "warez" lists) of the locations. The lists typically include the names of writable directories and the locations of pirated software; they may also include entries for accounts and passwords.

    • Disseminate information about the location of such materials via email, Internet Relay Chat (IRC), Instant Messaging (IM) systems, posting to newsgroups or bulletin-board services, or other means.
    • Use this information for personal, commercial or political gain, or to carry out attacks against other individuals or organizations.
    • Abuse a vulnerable archive site for a short span of time and then move on to other sites.
    • Leverage this access and/or exploit system configuration weaknesses to gain other privileged access.

  • Some sites have reported many hundreds of connections in a very short span of time that have been identified as "puts" and "gets", e.g., to store and retrieve pirated software, on their anonymous archive server. This may cause a denial of service, crash the system, or consume disk space on the system.

III. What you can do

  1. Detection
    • Develop in-house tools to parse the logs generated from accesses to your server for puts/gets (e.g., "STOR" and "RETR" sessions). Review this information for unusual or unexpected activity.
    • Regularly review the contents of your archive's incoming or "drop-off" area to identify abuse, then follow-up in accordance with relevant policies and procedures in your organization.
    • Review the contents of your FTP directories on a regular basis for inappropriate files. Check also for hidden directories (directories with spaces or special/control characters).
    • Ensure there has been no unauthorized modification to ANY existing files (or addition of new files) on your archive (including the FTP daemon).
    • We have had reports where abusers have replaced an original file with a Trojan horse version of a file (or daemon).

    • We encourage you to check for signs of compromise using our "Intruder Detection Checklist" available from

      http://www.cert.org/tech_tips/intruder_detection_checklist.html

  2. Reaction
    • If you believe that your anonymous archive is being used for distributing pirated software, we encourage you to review the directories/files created as a result of this abuse in accordance with policies and procedures that may be in place within your organization.
    • If you discover that your anonymous FTP server has been misused or compromised and you find any lists containing references to other sites, we encourage you to do the following:

      • Determine where the unauthorized access(es) originated. These hosts may themselves be compromised.
      • Review the contents of any files or directories for references to other sites or account/password combinations.
      • Notify any sites you identified, alerting them to the activity and asking them to check for potential misuse or compromise. We would appreciate it if you sent a copy of your message to cert@cert.org; this facilitates our work on incidents and helps us relate ongoing intruder activities.

        If you have a CERT reference number (e.g., CERT#XXXXX) for this incident, please include it in the subject line of all messages related to this incident. (NOTE: The CERT/CC assigns this reference number, so if you do not have one, one will be assigned once we receive the incident report.)

        To find site contact information, please refer to

        http://www.cert.org/tech_tips/finding_site_contacts.html

        Feel free to include a copy of this document in your message to the sites, especially those sites that include a password file or host/account/password combination. These sites will want to check for further compromise.

    • If you believe a system under your administrative control may have been compromised, please refer to

      http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

  3. Prevention

IV. Additional measures that you can take


This document is available from: http://www.cert.org/tech_tips/anonymous_ftp_abuses.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/CC personnel answer the hotline 08:00-17: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

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

* "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.


Conditions for use, disclaimers, and sponsorship information

Copyright 2001, 2002 Carnegie Mellon University

Disclaimers and copyright information

CERT and CERT Coordination Center are registered in the U.S. Patent & Trademark Office

Revision history:
May 4, 2001: converted to HTML; modified formatting; updated URLs
August 27, 2002: URL cleanup; minor content updates