Version 1.1

-----BEGIN PGP SIGNED MESSAGE-----

Version 1.1
February 13, 1998

Problems With The FTP PORT Command

or

Why You Don't Want Just Any PORT in a Storm

1. Introduction

In the past few years, there have been ongoing discussions about problems
related to the PORT command in the FTP protocol. These problems are
based on the misuse of the PORT command in the FTP protocol.

2. The FTP Protocol

To understand these attacks, it is necessary to have a basic
understanding of the FTP protocol [1].

A client opens a connection to the FTP control port (port 21) of an
FTP server. So that the server will be later able to send data back to
the client machine, a second (data) connection must be opened between
the server and the client.

To make this second connection, the client sends a PORT command to the
server machine. This command includes parameters that tell the server
which IP address to connect to and which port to open at that address
- in most cases this is intended to be a high numbered port on the
client machine.

The server then opens that connection, with the source of the connection
being port 20 on the server and the destination being the port identified
in the PORT command parameters.

The PORT command is usually used only in the "active mode" of FTP, which
is the default. It is not usually used in passive (also known as PASV
[2]) mode. Note that FTP servers usually implement both modes, and the
client specifies which method to use [3].

3. The FTP Bounce Attack

To conform with the FTP protocol, the PORT command has the originating
machine specify an arbitrary destination machine and port for the data
connection. However, this behavior also means that an attacker can open a
connection to a port of the attacker's choosing on a machine that may not
be the originating client.

Making this connection to an arbitrary machine for unauthorized purposes
is the FTP bounce attack.

For illustrative purposes only, several examples of how attackers can
use FTP bounce follow.

3.1 Port scanning

An attacker wishing to carry out a port scan against a site can do so
from a third-party FTP server acting as a stage for the scan. The
victim site sees the scan as coming from the FTP server rather than
the true source (the FTP client).

Under some circumstances, this technique offers the attacker more
benefits that just hiding the true source of the probe. When the intended
victim site is on the same subnet as the FTP server, or when it does not
filter traffic from the FTP server, the attacker can use the server
machine as the source of the port scan rather than the client machine,
thus managing to bypass access controls that might otherwise apply.

3.2 Bypassing basic packet filtering devices

An attacker may bypass a firewall (or other boundary protection
measures) in certain network configurations.

For instance, assume that a site has its anonymous FTP server behind
the firewall. Using the port scan technique above, an attacker
determines that an internal web server at that site is available on
port 8080, a port normally blocked by a firewall.

By connecting to the public FTP server at the site, the attacker
initiates a further connection between the FTP server and an arbitrary
port on a non-public machine at that site (for instance the internal
web server at port 8080). As a result, the attacker establishes a
connection to a machine that would otherwise be protected by the
firewall.

3.3 Bypassing export restrictions

An example of how to bypass export restrictions was described by
Hobbit in a posting to the bugtraq mailing list in 1995 [4]. This
description is available from

ftp://avian.org/random/ftp-attack

4. Bypassing Dynamic Packet Filtering Devices

Another problem involves client sites that have implemented firewalls
that use dynamic packet filters to protect themselves. The sites are
open to attack because the firewall trusts the information it receives.

In this example, the victim site houses all of its systems behind a
firewall that uses dynamic packet filters. A person at the victim site
browses web pages and downloads a Java applet constructed by the
attacker. Without that person's knowledge, the Java applet then opens an
outbound FTP connection to the attacker's machine. The applet then issues
an FTP PORT command, instructing the server machine to open a connection
to, say, the telnet port at some otherwise protected system behind the
victim firewall.

Because the dynamic packet filtering firewall examines outbound packets
to determine if any action is required on its part, it notes the PORT
command and allows an incoming connection from the remote web server to
the telnet port on the victim machine. This connection normally is not
allowed by the firewall; it was allowed in this case because the PORT
command was issued by the client.

Martin et al [5] discuss this particular attack, variations of it, and
specific defense strategies.

5. Solutions

The example attacks in this tech tip demonstrate the core component of
the vulnerability: the contents of the FTP PORT command are not
trustworthy as they are under the control of a potential attacker. The
FTP bounce example demonstrates what happens when a server trusts the
information. The dynamic filter example demonstrates what happens when a
firewall trusts the information.

Because the core element of the FTP bounce attack is required for RFC
compliance, there is no clear-cut solution. An important point to
remember, though, is that the RFC states that the feature must be present
in the server software and usable to be RFC compliant. It does not state
that the end user must actually be under constraint of using this
feature.

5.1 FTP Server Software

The best solution to the FTP bounce problem from a security perspective
is to ensure that your FTP server software cannot establish connections
to arbitrary machines. However, sites that rely on the RFC-compliant
behavior may find that implementing this solution will affect
applications that they use. (We have not received any first-hand reports
of such cases.) Consequently, many vendors offer solutions that allow the
site offering the FTP service to make the choice that best suits
them. Vendor implementations fall into three groups:

(1) strict conformance with RFC functionality: The PORT command
may be used to connect directly to a third-party machine, and
this is the only functionality allowed. Some vendors who
choose to maintain strict conformance have addressed this
problem by modifying all other network services to reject
connections originating from the FTP data port (port 20).

(2) strict suppression of the PORT command: The PORT command may
be used to connect to the originating client, and this is the
only functionality allowed.

(3) variable PORT command behavior: The PORT command may be used
in either of the above two ways, with one way being the
default. Switching between them is usually achieved with a
command line parameter. You should be careful to verify which
is the default.

You should be aware which category your server software falls into.
Our recommendation is to use option 2, or option 3 with suppression
enabled.

5.2 FTP Server Configuration

Some of the FTP bounce attacks described earlier rely on one or more
server machines (depending on the attack) allowing uploaded files via
FTP (usually anonymous FTP).

Your site should offer anonymous upload facilities only if it is
absolutely necessary. Even then, you must carefully configure the
incoming area. For more details, see "Anonymous FTP Configuration
Guidelines" at

ftp://ftp.cert.org/pub/tech_tips/anonymous_ftp_config

Note that these steps only repel attacks that rely on intermediate
uploads. The steps are not effective against other attacks (such as a
port scan).

5.3 Network Configuration

There are a few things to keep in mind when configuring your network
boundaries (e.g., packet filtering routers and firewalls).

Sites should ensure that they carefully design their network topology so
that effective traffic boundaries exist between systems that offer
distinct levels of service. For instance, a site typically has an
anonymous FTP service, web service, and an incoming electronic mail
hub. The site uses good security practice by separating the machines that
provide these external services from those that perform internal
services. It is important to have strong network boundaries (preferably
using firewalls) between these two sets of machines. In this way, even if
an FTP server is vulnerable internal machines can be protected at the
intervening network boundary.

For example, sites that have an FTP server that allows the PORT
command to establish connections to third-party machines should block
traffic between the FTP server and machines that offer services
relying on hostname or IP address for authentication. Examples of
such services are rlogin, rsh and NFS. While a firewall or filtering
router should always prevent direct external access to such services,
it should also filter traffic from an internal FTP server that behaves
in this way. This prevents the FTP server being used as a relay
machine to attack protocols with weak authentication mechanisms based
on hostname or IP address.

There are several references which can assist you in configuring your
network boundaries. For example, the CERT Coordination Center includes
the following in their recommended reading list at
http://www.cert.org/pub/other_sources/books.html

Chapman, D. B., and Zwicky. E. D. _Building Internet
Firewalls._ Sebastopol, CA: O'Reilly & Associates, Inc., 1995.

Cheswick, William R., and Bellovin, Steven M. _Firewalls and Internet
Security: Repelling the Wily Hacker._ New York: Addison-Wesley
Publishing Company, 1994.

Sites using dynamic packet filtering firewalls may need to take
additional steps to ensure that third-party PORT commands are blocked
by the firewall. If you need to address this problem, we encourage you to
check with your vendor to determine the steps you should take.

References

[1] Postel, J., and J. Reynolds, "File Transfer Protocol," STD 1, RFC
959, USC/Information Sciences Institute, October 1985.

Available electronically from ftp://ftp.isi.edu/in-notes/rfc959

[2] Bellovin, S., "Firewall-Friendly FTP," RFC 1579, AT&T Bell
Laboratories, February 1994.

Available electronically from ftp://ftp.isi.edu/in-notes/rfc1579.txt

[3] Cheswick, William R., and Bellovin, Steven M. _Firewalls and Internet
Security: Repelling the Wily Hacker._ New York: Addison-Wesley
Publishing Company, 1994.

[4] Hobbit, "The FTP Bounce Attack," July 1995.

Available electronically from ftp://avian.org/random/ftp-attack

[5] Martin, David M., Rajagopalan, Sivaramakrishnan, and Rubin, Aviel D.,
"Blocking Java Applets at the Firewall," The Proceedings of the
1997 Symposium on Network and Distributed Systems Security.

Available electronically from

http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z

Acknowledgments

Thanks to Steve Bellovin for the technical sanity check. Thanks to Jeff
Schiller for guidance on interpreting RFCs. Thanks also to Don Stokes for
his technical input.

- ----------------------------------------------------------------------------
Copyright 1997, 1998 Carnegie Mellon University. Conditions for use,
disclaimers, and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to [email protected] with
"copyright" in the subject line.

CERT is registered in the U.S. Patent and Trademark Office.

- ----------------------------------------------------------------------------
Revision History

Apr. 28, 1998 Corrected URLs for obtaining RFCs.

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

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNUY8snVP+x0t4w7BAQG51wQAxMlVJvDtHj2NzdAxkNLq6g2od8ogGnIo
bJLlzK9oTk2xSHfWbr0BEn2euof7/P34J3tIWk/Jtmr8cRh9wvvAxWh2W1sHtDD0
GVj9GjhNvzHzncjJXdURfiJDWmiL1r/pN7vpHlX7S8q6Wa1LsWjFj1X6hn/X436a
NyuzDEkxU/U=
=Bhxk
-----END PGP SIGNATURE-----