Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note

Original Publication Date: April 28, 1998

HTML

<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>