Vulnerabilities of FTP protocol, FTP servers and clients

Date: Wednesday, 24-Mar-1999 23:32:07 EET

Anna-Kaisa Lindfors and Markus Peuhkuri
Department of Electical Engineering
Helsinki University of technology
{akl,puhuri}@tct.hut.fi

Abstract

The network services have vulnerabilities, mainly because of poor implementation but also by problems protocol design which can be utilized to attack on systems. In this study we go through ftp service. We have found problems both in ftp protocol and ftp client and server implementations. The consequences of these problems range from partial denial of service to full system compromise.


Contents

1 Introduction

The ftp is one of most important applications in Internet. Before world wide web and http protocol grow to the dominant application in Internet, most bytes transported in Internet belong to ftp connections. The ftp is the standard way to transfer files both authenticated and unauthenticated and nowadays holds second position in transfered bytes.

Because of this importance, nearly every server platform has ftp server and most Internet capable operating system has ftp client. As there are many implementations, also their security can be at different level.

In this presentation we first study ftp protocol and its historical background. Then we study attacks based on protocol features: are there some properties in the protocol that can be misuse? Then we focus on implementation problems: what errors there are in real implementations and in documentation or in setup scripts. Finally we evaluate problems and conclude our findings.

2 FTP protocol

2.1 Historical perspective

The File Transfer Protocol or the FTP has been under development since 1971 when the first proposed version of file transfer mechanisms was introduced. This first version was development for implementation on hosts at M.I.T. (RFC 114 and 141).

The whole history or chronological compilation of Request for Comments could be found on the Appendix III in RFC 959.

In RFC 354 the File Transfer Protocol was first time defined as a protocol for file transfer between hosts on the ARPANET. The next four FTP RFC:s deal with improvements of that version of FTP.

In 1973 considerable changes were made but general structure of the implementation remained the same and RFC 542 was published. The next six FTP RFC commented RFC 543 or made minor improvements.

In RFC 765 the underlying protocol was changed from the NCP to the TCP in 1980. This version is the foundation for the the current version of the FTP or RFC 959 [7], which only corrects some minor documentation errors and brings some new optional commands. The current version was introduced 1985. Only one RFC discussing the FTP has been released since then. It is RFC 2228 [8]which includes security extensions for the current version of the FTP.

2.2. Protocol itself

There can be named four objectives for the FTP. Those are

  1. promote sharing of files
  2. encourage indirect or implicit use of remote computers
  3. shield a user from variations in file storage systems among hosts
  4. transfer data reliably and efficiently.
The following figure represents the model how FTP service works.
                                            -------------
                                            |/---------\|
                                            ||   User  ||    --------
                                            ||Interface|<--->| User |
                                            |\----^----/|    --------
                  ----------                |     |     |
                  |/------\|  FTP Commands  |/----V----\|
                  ||Server|<---------------->|   User  ||
                  ||  PI  ||   FTP Replies  ||    PI   ||
                  |\--^---/|                |\----^----/|
                  |   |    |                |     |     |
      --------    |/--V---\|      Data      |/----V----\|    --------
      | File |<--->|Server|<---------------->|  User   |<--->| File |
      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
      --------    |\------/|                |\---------/|    --------
                  ----------                -------------

                  Server-FTP                   USER-FTP


PI  - protocol interpreter
DTP - data transfer process 
Data connection is bi-directional and need not exist all the time

Figure 1: FTP Protocol model

In this model user-protocol interpreter initiates the control connection via Telnet. The standard FTP commands are generated by the user-PI and transmitted via control connection to server process and server process sends standard replies to the commands over control connection. The parameters for the data connection and nature of file system are specified by the FTP commands.

The user-DTP "listen" on specific data post and server initiate the data connection. The data port need not be in the same host that initiates FTP commands, but the user or user FTP process must ensure listening of the specified data port. The data connection is also bi-directional i.e. it could be used for sending and receiving simultaneously.

There is another situation where a user transfers files between two hosts or FTP severs, neither of which is the user's host. The user sets up the control connection to both of the servers and initiates data connection between them. In this model control commands are transferred between the user and the servers and data is transferred between the servers. This model is cleared in Figure 2. in chapter 3.

The control connection should be open when transferring data. The data connection is opened just for the data transfer and closed thereafter. The user is responsible for requesting to close the control connection but the server takes the action.

The data could be transferred in many representation types and many transmission modes. The data representation types are ASCII, EBCDIC, Image and Local. The transmission modes are Stream, Block and Compressed. The FTP also allows the structure of a file be specified, which could be file-structure, record-structure and page-structure.

There are many commands for access control, transfer parameters and FTP service. The commands are listed here but the exact declarations (including parameters for commands) are found in RFC 959. The string which should be typed for each command is in parenthesis.

Access Control Commands
CommandTaskCommandTask
USERUser Name PASSPassword
ACCTAccount CWDChange Working Directory
CDUPChange To Parent Directory SMNTStructure Mount
REINReinitialize
QUITLogout
Transfer Parameter Commands
PORTData Port PASVPassive
TYPERepresentation Type STRUFile Structure
MODETransfer Mode
FTP Service Commands
RETRRetrieve STORStore
STOUStore Unique APPEAppend (with create)
ALLOAllocate RESTRestart
RNFRRename RNTORename To
ABORAbort RMDDelete - Remove Directory
MKDMake Directory PWDPrint Working Directory
LISTList NLSTName List
SITESite Parameters SYSTSystem
STATStatus HELPHelp
NOOPNoop

Every command must generate at least one reply (there could be more than one) to ensure the synchronization of requests and actions in the process of file transfer. Thus the user process always knows the state of the Server.

3 Protocol attacks

There are some design decisions that can be exploited by malicious attacker. Some of those are commonly disabled in implementations by some of those still exists.

3.1 Resource waste / DoS by PORT command

In FTP it is possible to transfer files between two hosts commanded by third party as shown in Figure 2 below:
   
                    Control     ------------   Control
                    ---------->| User-FTP |<-----------
                    |          | User-PI  |           |
                    |          |   "C"    |           |
                    V          ------------           V
            --------------                        --------------
            | Server-FTP |   Data Connection      | Server-FTP |
            |    "A"     |<---------------------->|    "B"     |
            -------------- Port (A)      Port (B) --------------

Figure 2: Data transfer between two servers

One scenario is to connect FTP server to discard (9) for RETR request and to chargen (19) for STOR on some host with high bandwidth connection to use network and server resources. In latter case it is also possible to fill server disk.

The port command can be used also as third-party port scanning: if the host inside firewall (where ftp connections from outside are allowed) can access some other computers; this makes scanning possible even if direct scanning is disabled by router or firewall configuration. The intruder can even submit data (like HTTP transactions) to inside computers if upload to ftp server is allowed. [4]

This attack does not need network eavesdrop possibility.

Solaris 2.5 and 2.6 were found vulnerable to this attack; the 2.6 didn't allow ports on privileged area (< 1024). More information on attack is on http://www.iki.fi/puhuri/htyo/Tik-110.452/portdos.shtml.

3.2 Data corruption by scanning listening ports

The data transfer in FTP protocol is realized by creating new TCP connection for each file to be transported. To do this the client (or the server in passive mode) creates listening socket to wait for connections. The other end then connects to this socket. A malicious attacker can then search this socket and connect to if he makes it before the server (or client) does. [4]

This attack does not need network eavesdrop possibility. If we, however, can listen control connection, we can learn the ports. By listening connection we can also learn normal passwords but attacking on data connection works also on one-time passwords.

It is possible that implementations check where the connection originates (violates with third-party transfer described above) or that implementations react properly with refused connections and error codes by removing file.

3.2.1 Servers

The server is vulnerable in passive mode. One could check if the data ports are allocated from some (limited) range making port scan easier. If the connection is established, one could wait for some period (few seconds) if some data arrives: if it does then one could get (possibly confidential) data; if not, one could assume that it is upload socket and supply e.g. some trojaned software or document. (Note that if the attacker does not eavesdrop control connection, it is not generally possible to know file name).

The servers were tested on experimental networks and all servers were vulnerable to this attack as described in http://www.iki.fi/puhuri/htyo/Tik-110.452/stealconn.shtml. What made the servers more vulnerable was that all servers allocated listening ports sequently: if one can log on to the ftp server and issues PASV command, he can learn the range where the ports are currently allocated.

3.2.2 Clients

In normal mode the clients are vulnerable. If we guess that some client is prepared to transfer files, we can try a port scan (OS and client software) dependent port are to find out listening ports. Using same methodology as above we can steal information or replace with malicious.

As the latency in experiment network was too low (compared to the Internet) the "real" hijacks of connections were made on real Internet - only for the client end. Some of clients were not vulnerable but acted properly on error codes from the server.

For details see http://www.iki.fi/puhuri/htyo/Tik-110.452/stealconn.shtml.

4 Implementation problems

4.1 Buffer overflows

Many server programs are badly coded and do not always check for correct bounds in argument: thus it is possible to have computer to perform arbitrary code or at least to crash the server process. [1,2]

These tests we run with custom program which sent very long commands to the server. The server process was monitored whether it failed or not.

4.1.1 Pre-authenticated

Super user rights can be acquired at pre-authenticated state.

The Solaris 2.5 ftp server was found vulnerable in this pre-authenticated state: it failed with segment violation so there is possibility for executing arbitrary code. This was not verified, however.

4.1.2 Authenticated

Normally at authenticated state the server process usually has dropped extra privileges and has only user privileges. However, acquiring shell process can be useful if user has ftp-only accounts (or anonymous account).

The Solaris 2.5 ftp server was found vulnerable in this authenticated state: it failed with segment violation so there is possibility for executing arbitrary code. This was not verified, however.

There exists an exploit [3] for wu-ftpd on Linux and it works. Even anonymous account has a root access. It requires that the account can write on some directory.

4.2 Resource starvation / DoS

Using PASV command it is possible to use free ports available on FTP server hosts and thus disable further connections. [5,6]

This exploit was not successful. The system was mainly loaded with many open connections, not by many listening connections. This may, however have effect on some more loaded system.

5 Configuration problems

Configuration of servers taken out-of-box may not be correct and secure. Also it is possible that configuration is somewhat unclear which may lead to misconfiguration.

5.1 Anonymous service

Only Windows NT had anonymous account enabled, the account had read-only access to one (empty) directory. One problem with NT was that using IIS control panel it was not possible to have write-only directories as drop-in boxes.

For other systems setting up anonymous account required creating user ftp with invalid shell and copying essential libraries and ls command to ftp home directory. On Solaris 2.5 system there was a script provided on manual page which set up anonymous ftp area. The only problem with a script was that the pub directory was owned by ftp user and had full rights to everyone! Even the anonymous account could download the data - thus making system very nice for third party attacks.

5.2 FTP-only accounts

With buffer overflow exploit it is possible to ftp-only account (even anonymous) to have shell access (even root).

6 Evaluating and counter measuring problems

We can divide problems into two classes: protocol problems and implementation problems.

6.1 Protocol problems

The problems in ftp protocol are an example about some nice features or design decisions that can misused. The third party file transfer is very useful if the controlling computer is on low speed connectivity but the both servers are on high speed connectivity with each other; the data can be transfered through high speed connection and not twice over low speed connection.

This feature is not much used and in most cases disabling this possibility does not break anything. One can require that the host specified in PORT command is the same as the control connection peer address. Disabling ports on privileged port area is a step to a right direction, but in some cases not enough.

The other problem, stoled connections is not a difficult to fix either. The only thing the client and the server should check is that the data connection peer is the same as control connection peer. The client may further secure itself against stoled connections by checking return codes from the server.

6.2 Implementation problems

For the implementation problems there is one clear solution: better implementations. The basic property is that every input (came it from the client or from file system) must be considered as a hostile one and nothing about it form, length or content should not be assumed.

As the servers are made more secure and fault-free, also supporting documentation, help utilities and default installation should be checked that the setup they provide is a correct one.

7 Other possible attacks

As the FTP protocol uses unencrypted and unauthenticated TCP connections, eavesdrop to catch passwords or other sensitive information is possible. Also it is possible to hijack connections. Those attacks are not covered here as they are general TCP attacks.

8 Conclusions

The ftp protocol has features which can be exploited or misused. Those features can be disabled in implementations without having any real effect on usability of ftp services. The features are used only in some specific cases.

The implementations are not fault-free: even if most problems are gradually cleared there may be some combinations which trigger unwanted actions. This can be addressed by applying software quality measures.

It is important that one reviews settings that they are consistent with wanted security level and not to trust automatic installations to put everything right.

References

[1] Jordan Ritter, "Remote buffer overflows in various FTP servers leads to potential root compromise", Netect, Inc, Feb 1999.
< http://www.netect.com/advisory_0209.html> [Referred 10-Feb-1999]
[2] Aleph One, "Smashing The Stack For Fun And Profit", Pharck, 49(7), File 14.
<http://www.2600.com/phrack/p49-14.html>
[3] Pieter Nieuwenhuijsen, "ftp exploit", The BUGTRAQ mailing list 22th March 1999.
< http://www.geek-girl.com/bugtraq/1999_1/1075.html>
[4] Fyodor, "The Art of Port Scanning", Pharck 51(7), Sept 1997
<http://www.2600.com/phrack/p51-11.html>
[5] "Denial-of-Service in IIS FTP Server", Security-Solutions.net
<http://www.security-solutions.net/news/1998072301.html>
[6] "Patch available for IIS 'Malformed FTP list Request' vulnerability", Microsoft Security Bulletin (MS99-003).
<http://www.microsoft.com/security/bulletins/ms99-003.asp>
[7] J. Postel, J. Reynolds. "File Transfer Protocol (FTP)", RFC 959, October 1985.
<ftp://ftp.isi.edu/in-notes/rfc/rfc959.txt>
[8] M. Horowitz, S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
<ftp://ftp.isi.edu/in-notes/rfc/rfc2228.txt>

Further Information

Denial of Service using PORT command
Experiments using ftp port command.
Stealing FTP data connections
Experiments how port scanning can be used to steal ftp connections.
Buffer overflows
Experiments to find buffer overflow errors.
Source code
Source code for programs used in experiments.