The File Transfer Protocol (FTP) explained: An Internet fossil advanced to the Digital Age

With the advent of a universal digital network – the Internet – it became not only relevant to digitize user-to-user communication, such as email, but to also facilitate interaction between client and server. One of the oldest approaches to this task is the so-called “File Transfer Protocol” – FTP. After a short explanation of the functioning of FTP and its criticality, the paper outlines associated vulnerabilities and state-of-the-art mitigation practices in the protocol’s advancements.

FTP is an application layer protocol at level 7 of the OSI model (Russell, 2013). Together with protocols such as HTTP, SMTP or SSH, the application layer is closest to the user and responsible for presenting received information via the user interface to the client (Shaw, 2018). Essentially, file sharing with FTP allows clients to access information (in form of files) stored on a server connected to the Internet and configured appropriately for remote (i.e., non-physical) access. To do so, the client establishes a Transmission Control Protocol (TCP) control connection to the FTP server (port: 21). After successful login, the client or machine can apply command-line or interface-bound commands to the FTP server to add/delete files, retrieve information on files stored, and modify the server’s directory.

Introduced in 1971, the Internet Engineering Task Force (IETF) describes the principle objective of FTP as to standardize file transfer for direct and indirect usage, so that “user or his program […] have a simple and uniform interface to the file systems on the network and be shielded from the variations in file and storage systems of different host computers” (IETF, 1971, p. 1). Two decades later, IETF defined FTP to be “the primary Internet standard for file transfer” (IETF, 1989, p. 29). Today, FTP is still considered a critical technology because of its extensive distribution and its (still) high compatibility to many applications (Horan, 2020).

Yet, three major factors underline the disadvantages of native FTP and its substitution with more advanced protocols: First, FTP requires a dual link to the server to uphold (a) a stateful control connection to maintain the server’s working directory and (b) a connection to transfer the data. The round-trip delays via two links reduce the speed of FTP, making it a comparably slow internet standard. (IETF, 1971) Second, when FTP was implemented, security concerns in the not-yet-worldwide Internet were smaller and encryption not in the center of attention. Followingly, FTP is a fully unencrypted protocol that transmits content, usernames, password, commands etc. in clear text and can easily be sniffed (i.e. illegitimately read directly from the data package) (Kozierok, 2005). Third, in its basic outlay, FTP allows interaction with the use of proxy servers, i.e. connecting to a server via another, intermediary server. This configuration gives way to an malicious “FTP Bound Attack”, described in the following. (Mitra, 2017)

Amongst other vulnerabilities, such as password or username guessing (brute force attack), the Internet Engineering Taskforce (IETF) described in its Request for Comments 2577 the risk of suffering from a FTP Bounce attack when “ […] sending an FTP ‘PORT’ command to an FTP server containing the network address and the port number of the machine and service being attacked.” (IETF, 1999, p. 1) Misattributing the attacker’s action to the proxy server via “File eXchange Protocol” (FXP, a data transfer method using FTP) can circumvent network-address-based access restriction and exacerbates tracking the attacker. A FTP Bounce Attack is particularly threatening if paired with a more privileged proxy server which then serves as a “Confused deputy” in an “privilege escalation exploit” (Hardy, 1988). This means that the attacker can connect to an TCP port of the target machine without having access rights but by utilizing the more privileged FTP proxy to connect.

Accounting for the outlined problems of RFC 2577, as well as the general encryption problem of FTP, several security-improving measures have been undertaken. Among these are disabling FXP by default or (rather unsuccessfully) trying to tunnel FTP through a “Secure Shell” connection (Kundert, 2019). In addition, several FTP derivatives have formed – most of them focusing on solving the encryption problem in FTP. Most notably, “FTP secure” (FTPS) was recommended by IETF in their RFC 4217 and secures the original FTP by using the Transport Layer Security’s “AUTH TLS” command (IETF, 2005). Concurrently, the IETF enabled file transfer as part of the renewal of Secure Shell (SSH version 2.0) that relies on a secure channel between client and server (SSH FTP or SFTP) instead of identifying the client securely as with FTPS (IETF, 2006). Together, these advancements successfully mitigate common risks of the initial file transfer protocol, such as an FTP bound attack.

The File Transfer Protocol, widely know as FTP, serves a prime example of one of the oldest Internet protocols that have initially been designed for smaller-scale purposes, therefore posed major security risks, and have eventually been developed further to account for the unforeseeable scale that the Internet is nowadays working on.

This paper was submitted as tech-brief to the course "Basics of Cybersecurity" at Columbia University's School of International and Public Administration (SIPA), lectured by Prof Colin Ahern, Adjuct Professor at SIPA and Deputy Chief Information Security Officer for the City of New York, overseeing Security Sciences for NYC Cyber Command.

LITERATURE

• Hardy, N. (1988). Confused deputy (or why capabilities might have been invented). Operating Systems Review (ACM), 22(4), 36–38. https://doi.org/10.1145/54289.871709
• Horan, M. (2020). Why do people still use FTP? Retrieved October 8, 2020, from https://www.ftptoday.com/blog/why-do-people-still-use-ftp-sites
• IETF. (1971). RFC 114 - File Transfer Protocol. Retrieved October 8, 2020, from https://tools.ietf.org/html/rfc114
• IETF. (1989). RFC 1123: Requirements for Internet Hosts - Application and Support. Internet Engineering Task Force - Requests for Comments. Retrieved from https://tools.ietf.org/html/rfc1123
• IETF. (1999). RFC 2577 - FTP Security Considerations. Retrieved October 11, 2020, from https://tools.ietf.org/html/rfc2577
• IETF. (2005). RFC 4217: Securing FTP with TLS. IETF Network Working Group, 1–29. Retrieved from https://tools.ietf.org/html/rfc4217
• IETF. (2006). RFC 4251 - The Secure Shell (SSH) Protocol Architecture. Retrieved October 11, 2020, from https://tools.ietf.org/html/rfc4251
• Kozierok, C. M. (2005). The TCP/IP Guide - File Transfer Protocol (FTP). Retrieved October 11, 2020, from http://www.tcpipguide.com/free/t_FileTransferProtocolFTP.htm
• Kundert, K. (2019). Securing FTP using SSH — Nurdletech. Retrieved October 11, 2020, from https://nurdletech.com/linux-notes/ftp/ssh.html
• Mitra, A. (2017). What is FTP Bounce Attack? - The Security Buddy. Retrieved October 11, 2020, from https://www.thesecuritybuddy.com/vulnerabilities/what-is-ftp-bounce-attack/
• Russell, A. L. (2013). The internet that wasn’t. IEEE Spectrum, 50(8), 39–43. https://doi.org/10.1109/MSPEC.2013.6565559
• Shaw, K. (2018). The OSI model explained: How to understand (and remember) the 7 layer network model. Retrieved October 8, 2020, from https://www.networkworld.com/article/3239677/the-osi-model-explained-how-to-understand-and-remember-the-7-layer-network-model.html