<P>
<OL TYPE="1">
<LI><A HREF="#1">Introduction</A></LI>
<LI><A HREF="#2">The FTP Protocol</A></LI>
<LI><A HREF="#3">The FTP Bounce Attack</A>
<OL TYPE="1">
<LI><A HREF="#3.1">Port Scanning</A></LI>
<LI><A HREF="#3.2">Bypassing basic packet filtering services</A></LI>
<LI><A HREF="#3.3">Bypassing export restrictions</A></LI>
</OL>
</LI>
<LI><A HREF="#4">Bypassing Dynamic Packet Filtering Devices</A></LI>
<LI><A HREF="#5">Solutions</A>
<OL TYPE="1">
<LI><A HREF="#5.1">FTP Server Software</A></LI>
<LI><A HREF="#5.2">FTP Server Configuration</A></LI>
<LI><A HREF="#5.3">Network Configuration</A></LI>
</OL>
</LI>
</OL>
<A HREF="#refs">References</A><BR>
<A HREF="#ack">Acknowlegements</A><BR>
<A HREF="#history">Revision History</A>
</P>
<HR SIZE=2 NOSHADE ALIGN=LEFT>
<P>
<OL TYPE="1">
<LI><A NAME="1">Introduction</A>
<P>
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.
</P>
</LI>
<LI><A NAME="2">The FTP Protocol</A>
<P>
To understand these attacks, it is necessary to have a basic
understanding of the FTP protocol [1].
</P>
<P>
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.
</P>
<P>
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.
</P>
<P>
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.
</P>
<P>
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].
</P>
</LI>
<LI><A NAME="3">The FTP Bounce Attack</A>
<P>
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.
</P>
<P>
Making this connection to an arbitrary machine for unauthorized
purposes is the FTP bounce attack.
</P>
<P>
For illustrative purposes only, several examples of how attackers can
use FTP bounce follow.
</P>
<P>
<OL TYPE="1">
<LI><A NAME="3.1">Port scanning</A>
<P>
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).
</P>
<P>
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.
</P>
</LI>
<LI><A NAME="3.2">Bypassing basic packet filtering devices</A>
<P>
An attacker may bypass a firewall (or other boundary protection
measures) in certain network configurations.
</P>
<P>
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.
</P>
<P>
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.
</P>
</LI>
<LI><A NAME="3.3">Bypassing export restrictions</A>
<P>
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
<BLOCKQUOTE>
<A HREF="ftp://avian.org/random/ftp-attack">
ftp://avian.org/random/ftp-attack</A>
</BLOCKQUOTE>
</P>
</LI>
</OL>
</LI>
<LI><A NAME="4">Bypassing Dynamic Packet Filtering Devices</A>
<P>
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.
</P>
<P>
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.
</P>
<P>
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.
</P>
<P>
Martin et al [5] discuss this particular attack, variations of it, and
specific defense strategies.
</P>
</LI>
<LI><A NAME="5">Solutions</A>
<P>
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.
</P>
<P>
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.
</P>
<OL TYPE="1">
<LI><A NAME="5.1">FTP Server Software</A>
<P>
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:
<OL TYPE="1">
<LI>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).
</LI>
<LI>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.
</LI>
<LI>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.
</LI>
</OL>
You should be aware which category your server software falls into. Our recommendation is to use option 2, or option 3 with suppression
enabled.
</P>
</LI>
<LI><A NAME="5.2">FTP Server Configuration</A>
<P>
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).
</P>
<P>
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
<BLOCKQUOTE>
<A HREF="http://www.cert.org/tech_tips/anonymous_ftp_config.html">
http://www.cert.org/tech_tips/anonymous_ftp_config.html</A>
</BLOCKQUOTE>
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).
</P>
</LI>
<LI><A NAME="5.3">Network Configuration</A>
<P>
There are a few things to keep in mind when configuring your
network boundaries (e.g., packet filtering routers and firewalls).
</P>
<P>
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.
</P>
<P>
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.
</P>
<P>
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
</P>
<P>
<UL>
<LI><A HREF="http://www.cert.org/pub/other_sources/books.html">
http://www.cert.org/pub/other_sources/books.html</A></LI>
<LI>Chapman, D. B., and Zwicky. E. D. <I>Building Internet
Firewalls.</I> Sebastopol, CA: O'Reilly & Associates, Inc.,
1995.</LI>
<LI>Cheswick, William R., and Bellovin, Steven M. <I>Firewalls
and Internet Security: Repelling the Wily Hacker.</I> New
York: Addison-Wesley Publishing Company, 1994.</LI>
</UL>
</P>
<P>
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.
</P>
</LI>
</OL>
</LI>
</OL>
<A NAME="refs"><B>References</B></A>
<P>
<OL TYPE="1">
<LI>Postel, J., and J. Reynolds, "File Transfer Protocol," <I>STD 1, RFC
959,</I> USC/Information Sciences Institute, October 1985.<BR>
Available electronically from
<A NAME="ftp://ftp.isi.edu/in-notes/rfc959">
ftp://ftp.isi.edu/in-notes/rfc959</A><BR><BR>
</LI>
<LI>Bellovin, S., "Firewall-Friendly FTP," <I>RFC 1579,</I> AT&T Bell
Laboratories, February 1994.<BR>
Available electronically from
<A HREF="ftp://ftp.isi.edu/in-notes/rfc1579.txt">
ftp://ftp.isi.edu/in-notes/rfc1579.txt</A><BR><BR>
</LI>
<LI>Cheswick, William R., and Bellovin, Steven M. <I>Firewalls and Internet
Security: Repelling the Wily Hacker.</I> New York: Addison-Wesley
Publishing Company, 1994.<BR><BR>
</LI>
<LI>Hobbit, "The FTP Bounce Attack," July 1995.<BR>
Available electronically from
<A NAME="ftp://avian.org/random/ftp-attack">
ftp://avian.org/random/ftp-attack</A><BR><BR>
</LI>
<LI>Martin, David M., Rajagopalan, Sivaramakrishnan, and Rubin, Aviel D.,
"Blocking Java Applets at the Firewall," <I>The Proceedings of the
1997 Symposium on Network and Distributed Systems Security.</I><BR>
Available electronically from
<A HREF="http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z">
http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z</A><BR><BR>
</LI>
</OL>
</P>
<A NAME="ack"><B>Acknowledgments</B></A>
<P>
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.
</P>
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 1998, 1999 Carnegie Mellon University.</p>
<HR SIZE=2 NOSHADE ALIGN=LEFT>
<TABLE>
<A NAME="history">
<TR>
<TD>
<FONT SIZE=3 FACE="Verdana">
Revision History
</TD>
</TR>
<TR>
<TD VALIGN=TOP WIDTH=30%>
<FONT SIZE=2 FACE="Verdana">
Apr 28, 1998<BR>
Feb 13, 1998<BR>
Feb 12, 1999<BR>
</TD>
<TD VALIGN=TOP WIDTH=70%>
<FONT SIZE=2 FACE="Verdana">
Corrected URLs for obtaining RFCs<BR>
Updates<BR>
Converted to new web format<BR>
</TD>
</TR>
</SMALL>
</TABLE>
|