CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
Project Team:
Sajid Sayed, Santvan Shah
Course:
CMPT585 – Computer and Data Security
Semester:
Fall 2004
Instructor:
Dr. Stefan Robila
Due Date:
Dec 10, 2004
Sajid Sayed
Santvan Shah
Final Project
Page 1 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
TABLE OF CONTENTS
1
INTRODUCTION ............................................................................................................................ 4
2
VARIOUS METHODS OF FILE TRANSFER ........................................................................ 5
3
MANUAL FILE TRANSFER ......................................................................................................... 6
3.1
3.2
3.3
3.4
4
FILE TRANSFER VIA EMAIL .................................................................................................... 8
4.1
4.2
4.3
4.4
5
HOW TO ......................................................................................................................................... 6
COMMON USES .............................................................................................................................. 6
TRANSFER MEDIA .......................................................................................................................... 6
SECURITY ANALYSIS ..................................................................................................................... 6
HOW TO ......................................................................................................................................... 8
COMMON USES .............................................................................................................................. 8
TRANSFER MEDIA .......................................................................................................................... 8
SECURITY ANALYSIS ..................................................................................................................... 8
REGULAR/ANONYMOUS FTP ................................................................................................10
5.1 HOW TO ........................................................................................................................................11
5.2 COMMON USES .............................................................................................................................12
5.3 METHOD OF TRANSPORT ..............................................................................................................12
5.4 SECURITY ANALYSIS AND RECOMMENDATIONS .........................................................................12
5.4.1
Setting up the anonymous FTP directories ............................................................................12
5.4.2
Using proper password and group files ................................................................................13
5.4.3
Providing writable directories in your anonymous FTP configuration .................................13
5.4.3.1 Modified FTP daemon .......................................................................................................14
5.4.3.2 Using protected directories ................................................................................................14
5.4.4
A Vulnerability Example ........................................................................................................15
5.4.5
Risks of using FTP transfers ..................................................................................................15
5.4.5.1 The Bounce Attack ............................................................................................................16
5.4.5.2 Restricted Access ...............................................................................................................16
5.4.5.3 Protecting Passwords .........................................................................................................16
5.4.5.4 Privacy ...............................................................................................................................17
5.4.5.5 Protecting Usernames ........................................................................................................17
5.4.5.6 Port Stealing ......................................................................................................................17
5.4.5.7 Software-Based Security Problems....................................................................................17
6
WUFTP ...............................................................................................................................................19
6.1
6.2
7
SAMPLE WUFTP CONFIGURATION ..............................................................................................19
A VULNERABILITY EXAMPLE .........................................................................................................19
FILE TRANSFER VIA SFTP ......................................................................................................22
7.1
7.2
7.3
7.4
HOW TO ........................................................................................................................................22
FINGERPRINTS ..............................................................................................................................22
OPENSSH .....................................................................................................................................22
NEED FOR SFTP ...........................................................................................................................23
7.4.1.1 Technology Background ....................................................................................................23
7.4.1.2 Problems with Standard FTP .............................................................................................23
7.5 SFTP FEATURES ...........................................................................................................................24
7.5.1
Strong Encryption ..................................................................................................................24
Sajid Sayed
Santvan Shah
Final Project
Page 2 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
7.5.2
X11 Forwarding ....................................................................................................................25
7.5.3
Port Forwarding ....................................................................................................................25
7.5.4
Strong Authentication ............................................................................................................25
7.5.5
Agent Forwarding..................................................................................................................25
7.5.6
Interoperability ......................................................................................................................26
7.5.7
Kerberos and AFS Ticket Passing .........................................................................................26
7.5.8
Data Compression .................................................................................................................26
7.6 SECURITY ANALYSIS ....................................................................................................................26
7.7 SFTP USAGE AND IMPLEMENTATIONS OVER TIME .....................................................................28
8
FTP SECURITY EXTENSIONS ................................................................................................29
8.1
8.2
8.3
8.4
9
GENERAL ISSUES ..........................................................................................................................29
SECURITY EXTENSIONS................................................................................................................30
LOGIN AUTHORIZATION ...............................................................................................................32
DATA CHANNEL ENCAPSULATION ................................................................................................32
SFTP RECOMMENDATIONS ....................................................................................................34
10
OTHER FTP IMPLEMENTATIONS .....................................................................................35
11
KEY CHALLENGES FOR NEW RESEARCH ....................................................................36
12
REFERENCES ..............................................................................................................................37
Sajid Sayed
Santvan Shah
Final Project
Page 3 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
1 Introduction
In this project, we will study and analyze various File Transfer Methods. As part of
this project, we will:




Analyze the methods in terms of how secure they are.
Try to find weaknesses and strengths of each method.
Try to make recommendations on which method to use in which situation.
Suggest improvements where possible.
Sajid Sayed
Santvan Shah
Final Project
Page 4 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
2 Various Methods of File Transfer
The following are various general methods of transferring files:







Manual File Transfers
File Transfer via e-Mail.
File Transfer via HTTP/HTTPS
File Transfer via Anonymous FTP
File Transfer via WU-FTP
File Transfer via SFTP/SCP
Other products of File Transfer Protocol.
Sajid Sayed
Santvan Shah
Final Project
Page 5 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
3 Manual File Transfer
This file transfer method is very primitive. This can be done through various
recording media.
3.1 How To
To transfer files through this method, a person needs to insert the media into the
drive of source system and copy the data to the media. After that, he/she should
take the media to the destination system and insert the media and copy to the
destination server or machine.
3.2 Common Uses
This is usually used between two systems, which are not connected to the network.
Very highly confidential data can be transferred through this way.
3.3 Transfer Media
This method of transferring files utilizes one or more of the following types of media:






Floppy Disk
CD/DVD
Tape
Zip Drive
USB Drives
Hard disk
3.4 Security Analysis
Weaknesses





Incompatibility of drives
Incompatibility of Media
Limited capacity of Media
If the media is lost, misplaced or damaged the data is gone. If the media is lost
or misplaced, then the data will be readily accessible to the finder.
Physical Access of source and destination systems is required.
Strengths

Even though it is an old method of file transfer it is very secure if done through
two trusted parties.
Sajid Sayed
Santvan Shah
Final Project
Page 6 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective


Since the data is not transferred through the wire there is no possibility of cyber
attack like (Packet sniffing, Man in the middle, hijacking, eavesdropping on the
network etc.)
This can be very useful for top-secret data transfer.
Sajid Sayed
Santvan Shah
Final Project
Page 7 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
4 File Transfer via Email
This is the most common method available since the advent of the Internet. This
method uses protocols like SMTP, POP, IMAP, etc.
4.1 How To
The user launches an e-mail client application, composes a new message, attaches
one or more files and sends the message with the attached files to a destination
email address. This process internally takes care of uploading the file to the server.
The recipient downloads his email from the mail server to the destination machine,
opens the email with another e-mail client application and saves the attachment to
the folder/directory of his choice.
4.2 Common Uses
This method is mostly used to transfer one or more files where security is not a
concern like simple documents, images, sound, music or AVI files. This method is
usually used at a personal or interoffice level.
4.3 Transfer Media
This method along with other methods uses the network to transfer data. Traffic can
be routed over wires, optical fibers or even satellite.
4.4 Security Analysis
Weaknesses







This method is mostly insecure unless the data is specifically encrypted.
It usually requires a third party mail server where a copy of information is always
stored.
There is a very high probability of the email being delivered to an unintended
recipient or of getting lost on the network.
There is no control over the destination folder or directory. To deliver the
document to the specific folder you require user intervention on the recipient
side.
It is highly vulnerable to man in the middle attack or session hijacking attack.
It is an extremely common and preferred method of spreading viruses.
There is a severe limitation on the size and number of file being transferred.
Sajid Sayed
Santvan Shah
Final Project
Page 8 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
Strengths




It is a very easy and economical way to transfer files. Even non-technical users
can easily transfer files.
Files can be sent in an encrypted manner if needed.
As compared to manual method of file transfer this method is extremely fast.
If the data is not confidential then this is the best way to transfer between
personal users.
Sajid Sayed
Santvan Shah
Final Project
Page 9 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5 Regular/Anonymous FTP
What is FTP?
FTP refers to the File Transfer Protocol, one of the protocols within the TCP/IP
protocol suite used on the Internet. The File Transfer Protocol makes it possible to
transfer files from one computer (or host) on the Internet to another. In addition,
the FTP protocol implements commands to execute operations on a remote system,
e.g. view directories, change directories, make directories or delete files.
There are many FTP implementations built on the specification of the FTP protocol. A
user of an FTP program must log in to both hosts in order to transfer a file from one
to the other.
It is common for a user with files on more than one host to use the FTP program to
transfer files from one host to another. In this case, the user has an account on
both hosts involved, so he has passwords for both hosts.
However, Internet users may also take advantage of a wealth of information
available from archive sites by using a general-purpose account called "anonymous
FTP".
What is Anonymous FTP?
Anonymous FTP is a means by which archive sites allow general access to their
archives of information. These sites create a special account called "anonymous".
User "anonymous" has limited access rights to the archive host, as well as some
operating restrictions. In fact, the only operations allowed are logging in using FTP,
listing the contents of a limited set of directories, and retrieving files. Some sites
limit the contents of a directory listing an anonymous user can see as well. Note
that "anonymous" users are not usually allowed to transfer files TO the archive site,
but can only retrieve files from such a site.
Traditionally, this special anonymous user account accepts any string as a password,
although it is common to use either the password "guest" or one's electronic mail (email) address. Some archive sites now explicitly ask for the user's e-mail address
and will not allow login with the "guest" password. Providing an e-mail address is a
courtesy that allows archive site operators to get some idea of who is using their
services.
The objectives of FTP are
1) To promote sharing of files (computer programs and/or data),
2) To encourage indirect or implicit (via programs) use of remote computers,
3) To shield a user from variations in file storage systems among hosts, and
4) To transfer data reliably and efficiently.
FTP, though usable directly by a user at a terminal, is designed mainly for use by
programs.
Sajid Sayed
Santvan Shah
Final Project
Page 10 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.1 How To
THE FTP MODEL
With the above definitions in mind, the following model (shown in Figure 1) may be
diagrammed for an FTP service.
------------|/---------\|
||
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
NOTES:
1. The data connection may be used in either direction.
2. The data connection need not exist all of the time.
Figure 1 Model for FTP Use
In the model described in Figure 1, the user-protocol interpreter initiates the control
connection. The control connection follows the Telnet protocol. At the initiation of
the user, standard FTP commands are generated by the user-PI and transmitted to
the server process via the control connection. (The user may establish a direct
control connection to the server-FTP and generate standard FTP commands
independently, bypassing the user-FTP process.) Standard replies are sent from the
server-PI to the user-PI over the control connection in response to the commands.
The FTP commands specify the parameters for the data connection (data port,
transfer mode, representation type, and structure) and the nature of file system
operation (store, retrieve, append, delete, etc.). The user-DTP or its designate
should "listen" on the specified data port, and the server initiates the data
connection and data transfer in accordance with the specified parameters. It should
be noted that the data port need not be in the same host that initiates the FTP
commands via the control connection, but the user or the user-FTP process must
ensure a "listen" on the specified data port. It ought to also be noted that the data
connection may be used for simultaneous sending and receiving.
Sajid Sayed
Santvan Shah
Final Project
Page 11 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.2 Common Uses
Generally used for software downloads, patches, trial versions or beta
versions. It is also used for information sharing and getting data from various
sources. It is one of the oldest methods using the ftp protocol.
5.3 Method of Transport
Files are transferred only via the data connection. The control connection is used for
the transfer of commands, which describe the functions to be performed, and the
replies to these commands. Several commands are concerned with the transfer of
data between hosts. These data transfer commands include the MODE command
which specify how the bits of the data are to be transmitted, and the STRUcture and
TYPE commands, which are used to define the way in which the data are to be
represented. The transmission and representation are basically independent but the
"Stream" transmission mode is dependent on the file structure attribute and if
"Compressed" transmission mode is used, the nature of the filler byte depends on
the representation type.
5.4 Security Analysis and Recommendations
Anonymous FTP can be a valuable service if correctly configured and administered.
Sites should ensure that they are using the most recent version of their FTP daemon.
5.4.1 Setting up the anonymous FTP directories
The anonymous FTP root directory (~ftp) and its subdirectories should not be owned
by the ftp account or be in the same group as the ftp account. This is a common
configuration problem. If any of these directories are owned by ftp or are in the
same group as the ftp account and are not write protected, an intruder will be able
to add files (such as a .rhosts file) or modify other files. Many sites find it acceptable
to use the root account. Making the ftp root directory and its subdirectories owned
by root, part of the system group, and protected so that only root has write
permission will help to keep your anonymous FTP service secure.
Here is an example of an anonymous FTP directory setup:
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
7 root
25 root
2 root
2 root
10 root
system
system
system
system
system
512 Mar 1
512 Jan 4
512 Dec 20
512 Mar 12
512 Jun 5
15:17 ./
11:30 ../
15:43 bin/
16:23 etc/
10:54 pub/
Files and libraries, especially those used by the FTP daemon and those in ~ftp/bin
and ~ftp/etc, should have the same protections as these directories. They should not
be owned by ftp or be in the same group as the ftp account; and they should be
write protected.
Sajid Sayed
Santvan Shah
Final Project
Page 12 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.4.2 Using proper password and group files
We strongly advise that sites not use the system's /etc/passwd file as the password
file or the system's /etc/group as the group file in the ~ftp/etc directory. Placing
these system files in the ~ftp/etc directory will permit intruders to get a copy of
these files. These files are optional and are not used for access control.
We recommend that you use a dummy version of both the ~ftp/etc/passwd and
~ftp/etc/group files. These files should be owned by root. The dir command uses
these dummy versions to show owner and group names of the files and directories
instead of displaying arbitrary numbers.
Sites should make sure that the ~/ftp/etc/passwd file contains no account names
that are the same as those in the system's /etc/passwd file. These files should
include only those entries that are relevant to the FTP hierarchy or needed to show
owner and group names. In addition, ensure that the password field has been
cleared. The examples below show the use of asterisks (*) to clear the password
field.
Below is an example of a passwd file from the anonymous FTP area on cert.org:
ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::
cops:*:3271:20:COPS Distribution::
cert:*:9920:20:CERT::
tools:*:9921:20:CERT Tools::
ftp:*:9922:90:Anonymous FTP::
nist:*:9923:90:NIST Files::
Here is an example group file from the anonymous FTP area on cert.org:
cert:*:20:
ftp:*:90:
5.4.3 Providing writable directories in your anonymous FTP
configuration
There is a risk to operating an anonymous FTP service that permits users to store
files. We strongly recommend that sites do not automatically create a "drop off"
directory unless thought has been given to the possible risks of having such a
service. There are many incidences where these directories have been used as "drop
off" directories to distribute bootlegged versions of copyrighted software or to trade
information on compromised accounts and password files. There have also been
incidents of file systems being maliciously filled causing denial of service problems.
This section discusses two ways to address these problems. The first is to use a
modified FTP daemon. The second method is to provide restricted write capability
through the use of special directories.
Sajid Sayed
Santvan Shah
Final Project
Page 13 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.4.3.1 Modified FTP daemon
If a site is planning to offer a "drop off" service, we suggest using a modified FTP
daemon that will control access to the "drop off" directory. This is the best way to
prevent unwanted use of writable areas. Some suggested modifications are:




Implement a policy where any file dropped off cannot be accessed until the
system manager examines the file and moves it to a public directory.
Limit the amount of data transferred in one session.
Limit the overall amount of data transferred based on available disk space.
Increase logging to enable earlier detection of abuses.
5.4.3.2 Using protected directories
If a site is planning to offer a "drop off" service and is unable to modify the FTP
daemon, it is possible to control access by using a maze of protected directories. This
method requires prior coordination and cannot guarantee protection from unwanted
use of the writable FTP area, but has been used effectively by many sites.
Protect the top level directory (~ftp/incoming) giving only execute permission to the
anonymous user (chmod 751 ~ftp/incoming). This will permit the anonymous user to
change directory (cd), but will not allow the user to view the contents of the
directory.
drwxr-x--x 4
root
system 512 Jun 11
13:29 incoming/
Create subdirectories in the ~ftp/incoming using names known only between your
local users and the anonymous users that you want to have "drop off" permission.
The same care used in selecting passwords should be taken in selecting these
subdirectory names because the object is to choose names that cannot be easily
guessed.
drwxr-x-wx 10
drwxr-x-wx 10
root
root
system 512 Jun 11
system 512 Jun 11
13:54 jAjwUth2/
13:54 MhaLL-iF/
This will prevent the casual anonymous FTP user from writing files in the anonymous
FTP file system. It is important to realize that this method does not protect a site
against the result of intentional or accidental disclosure of the directory names. Once
a directory name becomes public knowledge, this method provides no protection at
all from unwanted use of the area. Should a name become public, a site may choose
to either remove or rename the writable directory.
Sajid Sayed
Santvan Shah
Final Project
Page 14 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.4.4 A Vulnerability Example
Vulnerability has been detected in the anonymous FTP configuration in all versions of
IBM’s AIX.
IBM is aware of this problem and a fix is available as apar number "ix23944". This
patch is available for all AIX releases from "GOLD".
Description
Previous
versions
of
the
anonymous
FTP
installation
script,
/usr/lpp/tcpip/samples/anon.ftp, incorrectly configured various files and directories.
Impact
Remote users can execute unauthorized commands and gain access to the system if
anonymous FTP has been installed.
Solution
Obtain the fix from IBM Support.
5.4.5 Risks of using FTP transfers
Using the file transfer protocol is considered to be less secure, as a password is
required for transfers, which is transmitted without encryption via the web. FTP is
one of the oldest and most frequently used protocols on the web, however, there are
some considerations concerning security:

When logging into the server, the user name and password are transmitted in
plain text and can be detected easily.

When connecting to the FTP server the sent data can be ’kidnapped’ to a foreign
computer with the result that they will never arrive at the specified target
computer. From the foreign computer data can be transferred to the actual
computer as well as existing data can be viewed and edited. This can be a great
danger for companies transferring in-house information!

FTP can also be used to find out the passwords of the users, as the password is
transferred in plain text when logging in, so that a person having authorized
access to the web can find out the password.
Sajid Sayed
Santvan Shah
Final Project
Page 15 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.4.5.1 The Bounce Attack
The version of FTP specified in the standard [PR85] provides a method for attacking
well-known network servers, while making the perpetrators difficult to track down.
The attack involves sending an FTP "PORT" command to an FTP server containing the
network address and the port number of the machine and service being attacked. At
this point, the original client can instruct the FTP server to send a file to the service
being attacked. Such a file would contain commands relevant to the service being
attacked (SMTP, NNTP, etc.). Instructing a third party to connect to the service,
rather than connecting directly, makes tracking down the perpetrator difficult and
can circumvent network-address-based access restrictions.
5.4.5.2 Restricted Access
For some FTP servers, it is desirable to restrict access based on network address.
Note that restricting access based on network address leaves the FTP server
vulnerable to "spoof" attacks. In a spoof attack, for example, an attacking machine
could assume the host address of another machine inside an organization and
download files that are not accessible from outside the organization. Secure
authentication mechanisms should be used whenever possible.
5.4.5.3 Protecting Passwords
To minimize the risk of brute force password guessing through the FTP server, it is
suggested that servers limit the number of attempts that can be made at sending a
correct password. After a small number of attempts (3-5), the server should close
the control connection with the client. In addition, it is suggested that the server
impose a 5 second delay before replying to an invalid "PASS" command to diminish
the efficiency of a brute force attack.
An intruder can subvert the above mechanisms by establishing multiple, parallel
control connections to a server.
To combat the use of multiple concurrent
connections, the server could either limit the total number of control connections
possible or attempt to detect suspicious activity across sessions and refuse further
connections from the site. However, both of these mechanisms open the door to
"denial of service" attacks, in which an attacker purposely initiates the attack to
disable access by a valid user.
Standard FTP sends passwords in clear text using the "PASS" command. It is
suggested that FTP clients and servers use alternate authentication mechanisms that
are not subject to eavesdropping.
Sajid Sayed
Santvan Shah
Final Project
Page 16 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
5.4.5.4 Privacy
All data and control information (including passwords) is sent across the network in
unencrypted form by standard FTP. To guarantee the privacy of the information FTP
transmits, a strong encryption scheme should be used whenever possible.
5.4.5.5 Protecting Usernames
Standard FTP specifies a 530 response to the USER command when the username is
rejected. If the username is valid and a password is required FTP returns a 331
response instead. In order to prevent a malicious client from determining valid
usernames on a server, it is suggested that a server always return 331 to the USER
command and then reject the combination of username and password for an invalid
username.
5.4.5.6 Port Stealing
Many operating systems assign dynamic port numbers in increasing order. By
making a legitimate transfer, an attacker can observe the current port number
allocated by the server and "guess" the next one that will be used. The attacker can
make a connection to this port, thus denying another legitimate client the ability to
make a transfer. Alternatively, the attacker can steal a file meant for a legitimate
user. In addition, an attacker can insert a forged file into a data stream thought to
come from an authenticated client.
This problem can be mitigated by making FTP clients and servers use random local
port numbers for data connections, either by requesting random ports from the
operating system or using system dependent mechanisms.
5.4.5.7 Software-Based Security Problems
The emphasis in this document is on protocol-related security issues. There are a
number of documented FTP security-related problems that are due to poor
implementation as well. The following FTP features has been abused in the past and
should be treated with great care by future implementers:

Anonymous FTP
As discussed above, Anonymous FTP refers to the ability of a client to connect to
an FTP server with minimal authentication and gain access to public files.
Security problems arise when such a user can read all files on the system or can
create files.

Remote Command Execution
Sajid Sayed
Santvan Shah
Final Project
Page 17 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
An optional FTP extension, "SITE EXEC", allows clients to execute arbitrary
commands on the server. This feature should obviously be implemented with
great care.

Debug Code
Several previous security compromises related to FTP can be attributed to
software that was installed with debugging features enabled.
Strengths
This method satisfies the diverse needs of users with a simple, and easily
implemented protocol design.
Sajid Sayed
Santvan Shah
Final Project
Page 18 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
6 WUFTP
Wuarchive-ftpd, more affectionately known as WU-FTPD, is a replacement ftp
daemon for Unix systems developed at Washington University (*.wustl.edu) by Chris
Myers and later by Bryan D. O'Connor (who are no longer working on it or supporting
it!). WU-FTPD is the most popular ftp daemon on the Internet, used on many
anonymous ftp sites all around the world.
6.1 Sample WUFTP configuration
Here is a sample ftpaccess configuration file:
class
all
real,guest,anonymous
*
limit
all
10
/etc/msgs/msg.dead
readme
readme
README*
README*
Any
login
cwd=*
message /welcome.msg
message .message
login
cwd=*
compress
tar
all
all
yes
yes
log commands real
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
email user@hostname
6.2 A Vulnerability Example
Vulnerability exists with certain configurations of the SITE EXEC command in the
Washington University ftpd, also known as wu-ftpd. Exploitation of this vulnerability
may allow root access from any account on the system.
The vulnerable configuration is known to exist in numerous Linux distributions and is
currently being actively exploited by intruders.
It should be noted that this vulnerability is not necessarily limited to Linux but may
exist on any wu-ftpd installation. Thus, all users of the wu-ftpd program, not just the
Linux users, should take this opportunity to verify the configuration of their
daemons. Note that versions of wu-ftpd before the 2.4 release contain serious
security vulnerabilities and should be updated immediately.
Description
Sajid Sayed
Santvan Shah
Final Project
Page 19 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
There is a problem with the default configuration of the Washington University FTP
Server version 2.4 in major Linux distributions, including but not limited to
Slackware 2.0, 2.1, 2.2, 2.3, Yggdrasil Plug&Play Fall'94, and the Debian
Distribution. By exploiting this problem, any user who is able to log into a system
having the vulnerable configuration via FTP using their login, and not the anonymous
login, may gain root access.
Other systems besides Linux can be configured to be vulnerable although the
standard wu-ftpd 2.4 source code as distributed is not vulnerable.
The problem is that the variable _PATH_EXECPATH was set to "/bin" in the
configuration file src/pathnames.h when the distribution binary was built.
_PATH_EXECPATH should be set to "/bin/ftp-exec" or a similar directory that does
not contain a shell or command interpreter, for example. The source code shipped
with the Linux distributions contains the correct value ("/bin/ftp-exec") despite the
incorrect distribution binary. You should verify that _PATH_EXECPATH has the
correct value before recompiling.
Note that the documentation for wu-ftpd states that the directory defined by
_PATH_EXECPATH is relative to ~ftp, the ftp home directory as specified in the
password file. This is misleading. The pathname is relative to ~ftp for anonymous
users only. This pathname is relative to "/" for other user sessions.
Impact
Any user with a local account on a system offering FTP services with the vulnerable
configuration may gain root access. Support for anonymous FTP access is not
required to exploit this vulnerability.
How to determine if you are vulnerable
All systems running wu-ftpd should be checked to determine if the configuration is
vulnerable.
To test your configuration, access the FTP server using a legitimate user account
(not an anonymous FTP login) and login to your FTP server. For example:
srchost> ftp ftphost
Connected to ftphost
220 ftphost FTP server (Version wu-2.4(2) Mon Apr 18 09:135 [...]
ready.
Name (srchost:joe):
331 Password required for joe.
Password:
230 User joe logged in.
Then type:
ftp> quote site exec echo problem
Sajid Sayed
Santvan Shah
Final Project
Page 20 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
If you see the following response, then you are not vulnerable:
200-echo problem
200 (end of 'echo problem')
However, if you see this following response, then you are vulnerable (note the
additional '200-problem' entry):
200-echo problem
200-problem
200 (end of 'echo problem')
Solution
If you have the vulnerability, we recommend that you turn off ftpd immediately.
Once you have done that, you can then decide whether to rebuild or fetch a new ftpd
binary.
Sajid Sayed
Santvan Shah
Final Project
Page 21 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
7 File Transfer via SFTP
SFTP is a secure form of the ftp command. Whenever a user opens up a regular ftp
session or most other TCP/IP connections, the entire transmission made between the
host and the user is sent in plain text. Anyone who has the ability to snoop on the
network packets can read the data, including the password information. If an
unauthorized user can login, they have the opportunity to compromise the system.
When using ssh's SFTP instead of the ftp, the entire login session, including
transmission of password, is encrypted. It is therefore much more difficult for an
outsider to observe and collect passwords from a system using ssh/SFTP sessions.
Network engineers and systems administrators have been using FTP to send files
back and forth to and from remote systems since the early days of the Internet. FTP
is part of every reputable TCP/IP stack. Though we've all grown used to using FTP for
the bulk of our file transfer needs, using it securely is becoming more important
today than ever before. In this section we have provided information on Secure FTP
that will help people understand its practical application.
7.1 How To
SFTP is similar to ftp: SFTP username@ip_address at which point it will prompt you
for your password. Then you receive an SFTP prompt. For then on you use the same
commands as in an ftp session, i.e. dir, get, put, etc. Note that the commands bin,
ascii, prompt are not used in SFTP. Also, the transfer of multiple files with "mget"
and "mput" is not supported. If you want to transfer many files, use the "tar"
command to produce a single archive for SFTP. If you need a reminder which
commands are available type "help" at the SFTP> prompt.
7.2 Fingerprints
To make sure that you have exchanged data with the correct server during SFTP
connection, the SFTP server transmits cryptographic fingerprints of its official host
key before connecting. During the first connection the key is not known by the client
program and needs to be confirmed by the user. Once are you connected to a
remote server and you are sure that this is the server you wish to connect to, you
should save fingerprint information locally. For each new connection, you should
check, if the fingerprint information is the one you stored - to make sure that nobody
is in the "middle". Fingerprint information is almost unique for different servers and
is generated from the private key of the server.
7.3 OpenSSH
OpenSSH is a FREE version of the SSH protocol suite of network connectivity tools
that increasing numbers of people on the Internet are coming to rely on. Many users
of telnet, rlogin, ftp, and other such programs might not realize that their password
is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic
Sajid Sayed
Santvan Shah
Final Project
Page 22 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
(including passwords) to effectively eliminate eavesdropping, connection hijacking,
and other network-level attacks. Additionally, OpenSSH provides a myriad of secure
tunneling capabilities, as well as a variety of authentication methods.
The OpenSSH suite includes the SSH program which replaces rlogin and telnet, SCP
which replaces rcp, and SFTP which replaces ftp. Also included is SSHD which is the
server side of the package, and the other basic utilities like ssh-add, ssh-agent, sshkeysign, ssh-keyscan, ssh-keygen and SFTP-server. OpenSSH supports SSH protocol
versions 1.3, 1.5, and 2.0.
7.4 Need for SFTP
SFTP stands for ‘Secure File Transfer Protocol’. The Secure File Transfer Protocol
provides secure file transfer functionality over any reliable data stream, SSH in this
case. It is the standard file transfer protocol to use with the SSH2 protocol.
SFTP protocol is designed to provide primarily file transfer, but also more general file
system access on the remote server - in secure manner. SFTP protocol assumes it is
running on secure channel, thus no plaintext passwords or file information is exposed
to the network.
7.4.1.1 Technology Background
Keeping the files on your intranet in top working order and keeping your e-business
alive seems to require moving files around endlessly to keep things organized.
System and network administrators use FTP to update DNS zone maps, update web
sites, transfer user data, move around database files, and endless other chores to
keep file systems and hard drives tidy. Moving files from here to there is the
heartbeat of the Internet. The nice thing about FTP is that it allows you to move files
easily between systems that use similar or different operating systems, file
structures, and character sets.
7.4.1.2 Problems with Standard FTP
FTP was originally defined in the early 1970s to transfer files to and from various
ARPANET nodes. However, there are a few problems with standard FTP that we all
grew up with in the early days of the Internet. First of all, it doesn't use strong
authentication. It is based on password logins which can be guessed, or discovered
by cyber criminals using a sniffer. Even if the password is not guessed or sniffed,
with standard FTP none of the files being transferred to and from their destinations
are encrypted. FTP sends files in clear plain-text exposing them to the plethora of
bad guys out there who have nothing better to do than violate the privacy of others,
pilfer confidential information such as credit card information, and attempt to obtain
classified information that could compromise national security.
Sajid Sayed
Santvan Shah
Final Project
Page 23 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
Files being transferred by FTP are also vulnerable to man-in-the-middle attacks
where data is intercepted and then altered before sending it back on its way. Another
scenario where using secure FTP is critical is during web site updates. Without secure
FTP, it is very easy to hack a web site and edit it with digital graffiti. All a hacker has
to do is find out the IP address of the web site using a reverse ping on the domain
name, and then set up a sniffer to run 24 hours a day on the IP address to sniff and
log the login connection. As soon as the web master logs in to update the site, the
hacker's sniffer can grab and record the password and login information. Using the
login information, hackers can then download the site's web pages onto their own
computer. After downloading the website, hackers then can use any number of HTML
editors to edit the website with graffiti, fraudulent news, or anything else, and then
FTP it back to its real home on the Web using the login and password they sniffed
earlier. The main reason that web sites get hacked is because they are being
updated with insecure FTP transfers. There are other ways that web sites can get
hacked (due to improper OS and incorrect server configurations) but using secure
FTP certainly reduces the probability of hacks due to insecure file transfers and
logins.
7.5 SFTP Features
SFTP runs over the SSH protocol suite providing encryption for network services like
remote login or remote file transfer.
The following is a list of SFTP features:

Strong Encryption (3DES, Blowfish, AES, Arcfour)

X11 Forwarding (encrypt X Window System traffic)

Port Forwarding (encrypted channels for legacy protocols)

Strong Authentication
Authentication)

Agent Forwarding (Single-Sign-On)

Interoperability (Compliance with SSH 1.3, 1.5, and 2.0 protocol Standards)

Kerberos and AFS Ticket Passing

Data Compression
(Public
Key,
One-Time
Password
and
Kerberos
7.5.1 Strong Encryption
OpenSSH supports 3DES, Blowfish, AES and arcfour as encryption algorithms. These
are patent free.
Triple DES is a time proven and well understood cipher that provides strong
encryption.
Sajid Sayed
Santvan Shah
Final Project
Page 24 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
Blowfish is a fast block cipher invented by Bruce Schneier that can be used by
people that require faster encryption.
AES is the US Federal Information Processing Standard (FIPS) Advanced Encryption
Standard developed as a replacement for DES. It is a fast block cipher.
Arcfour is a fast stream cipher. It is believed to be compatible with RC4[TM], a
proprietary cipher of RSA Security Inc. Encryption is started before authentication,
and no passwords or other information is transmitted in the clear. Encryption is also
used to protect against spoofed packets.
7.5.2 X11 Forwarding
X11 forwarding allows the encryption of remote X windows traffic, so that nobody
can snoop on your remote xterms or insert malicious commands. The program
automatically sets DISPLAY on the server machine, and forwards any X11
connections over the secure channel. Fake Xauthority information is automatically
generated and forwarded to the remote machine; the local client automatically
examines incoming X11 connections and replaces the fake authorization data with
the real data (never telling the remote machine the real information).
7.5.3 Port Forwarding
Port forwarding allows forwarding of TCP/IP connections to a remote machine over
an encrypted channel. Standard Internet applications like POP can be secured with
this.
7.5.4 Strong Authentication
Strong authentication protects against several security problems, e.g., IP spoofing,
fakes routes, and DNS spoofing. The authentication methods are: .rhosts together
with RSA based host authentication, pure RSA authentication, one-time passwords
with s/key, and finally authentication using Kerberos.
7.5.5 Agent Forwarding
An authentication agent, running in the user's laptop or local workstation, can be
used to hold the user's RSA or DSA authentication keys. OpenSSH automatically
forwards the connection to the authentication agent over any connections, and there
is no need to store the RSA or DSA authentication keys on any machine in the
network (except the user's own local machine). The authentication protocols never
reveal the keys; they can only be used to verify that the user's agent has a certain
key. Eventually the agent could rely on a smart card to perform all authentication
computations.
Sajid Sayed
Santvan Shah
Final Project
Page 25 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
7.5.6 Interoperability
OpenSSH versions before 2.0 support the SSH 1.3 and SSH 1.5 protocols permitting
communication with most UNIX, Windows and other commercial ssh
implementations.
As of OpenSSH 2.0, as well as supporting SSH 1.3 protocol and SSH 1.5 protocol,
OpenSSH also has support for the SSH 2.0 protocol. This protocol avoids using the
RSA algorithm. since at the time protocol 2.0 was invented the RSA patent was still
in effect and uses the freely useable DH and DSA algorithms instead.
Thus, OpenSSH gives you the best of both worlds. You can interoperate with both
types of ssh clients and servers!
7.5.7 Kerberos and AFS Ticket Passing
SFTP also passes tickets for Kerberos and AFS on to the remote machine. A user can
thus access all his Kerberos and AFS services without the need to type in a password
again.
7.5.8 Data Compression
Data compression before encryption improves the performance for slow network
links.
7.6 Security Analysis
SFTP is developed with very rigorous security processes for which it is famous for.
Strengths

SFTP is not vulnerable to the RC4 cipher password cracking, replay, or
modification attacks. At the time that SFTP was started, it was already known
that SSH 1 used the RC4 stream cipher completely incorrectly, and thus RC4
support was removed.

SFTP is not vulnerable to client forwarding attacks in unencrypted
connections, since unencrypted connection support was removed at SFTP
project start.

SFTP is not vulnerable to IDEA-encryption algorithm attacks on the last
packet, since the IDEA algorithm is not supported. The patent status of IDEA
makes it unsuitable for inclusion in SFTP.
Sajid Sayed
Santvan Shah
Final Project
Page 26 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective

SFTP does not treat localhost as exempt from host key checking, thus making
it not vulnerable to the host key authentication bypass attack.

SFTP is not vulnerable to uncontrollable X11 forwarding attacks because X11forwarding is disabled by default and the user can de-permit it.

New SFTP versions do not allow a remote attacker to execute arbitrary
commands with the privileges of sshd if UseLogin is enabled by the
administrator. UseLogin is disabled by default.

SFTP imposes limits on the connection rate, making the attack unfeasible.

SFTP does not allow malicious servers to access the client's X11 display or
ssh-agent.

SFTP does not allow users to delete files named "cookies" if X11 forwarding is
enabled. X11 forwarding is disabled by default.

SFTP does not allow users to pass environment variables to login if UseLogin
is enabled. The UseLogin option is disabled by default in all OpenSSH
releases.
Weaknesses

SFTP has the SSH 1 protocol deficiency that might make an insertion attack
difficult but possible. The CORE-SDI deattack mechanism is used to eliminate
the common case. Ways of solving this problem are being investigated, since
the SSH 1 protocol is not dead yet.

A buffer overflow in the CRC32 compensation attack detector can lead to
remote root access. This problem has been fixed in SFTP. However, older
versions were vulnerable.
Sajid Sayed
Santvan Shah
Final Project
Page 27 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
7.7 SFTP usage and implementations over time
SFTP Usage on the Internet over time
SFTP Implementations on the Internet over time
Sajid Sayed
Santvan Shah
Final Project
Page 28 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
8 FTP Security Extensions
8.1 General Issues
The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 and in place on
the Internet uses usernames and passwords passed in cleartext to authenticate
clients to servers (via the USER and PASS commands). Except for services such as
"anonymous" FTP archives, this represents a security risk whereby passwords can be
stolen through monitoring of local and wide-area networks. This either aids potential
attackers through password exposure and/or limits accessibility of files by FTP
servers who cannot or will not accept the inherent security risks.
Aside from the problem of authenticating users in a secure manner, there is also the
problem of authenticating servers, protecting sensitive data and/or verifying its
integrity. An attacker may be able to access valuable or sensitive data merely by
monitoring a network, or through active means may be able to delete or modify the
data being transferred so as to corrupt its integrity. An active attacker may also
initiate spurious file transfers to and from a site of the attacker's choice, and may
invoke other commands on the server. FTP does not currently have any provision for
the encryption or verification of the authenticity of commands, replies, or transferred
data. Note that these security services have value even to anonymous file access.
Current practice for sending files securely is generally either:
1. via FTP of files pre-encrypted under keys which are manually distributed,
2. via electronic mail containing an encoding of a file encrypted under keys which are
manually distributed,
3. via a PEM message, or
4. via the rcp command enhanced to use Kerberos.
None of these means could be considered even a de facto standard, and none are
truly interactive. A need exists to securely transfer files using FTP in a secure
manner which is supported within the FTP protocol in a consistent manner and which
takes advantage of existing security infrastructure and technology. Extensions are
necessary to the FTP specification if these security services are to be introduced into
the protocol in an interoperable way.
Although the FTP control connection follows the Telnet protocol, and Telnet has
defined an authentication and encryption option [TELNET-SEC], [RFC-1123] explicitly
forbids the use of Telnet option negotiation over the control connection (other than
Synch and IP).
Also, the Telnet authentication and encryption option does not provide for integrity
protection only (without confidentiality), and does not address the protection of the
data channel.
Sajid Sayed
Santvan Shah
Final Project
Page 29 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
8.2 Security Extensions
At the highest level, the FTP security extensions seek to provide an abstract
mechanism for authenticating and/or authorizing connections, and integrity and/or
confidentiality protecting commands, replies, and data transfers.
In the context of FTP security, authentication is the establishment of a client's
identity and/or a server's identity in a secure way, usually using cryptographic
techniques. The basic FTP protocol does not have a concept of authentication.
Authorization is the process of validating a user for login. The basic authorization
process involves the USER, PASS, and ACCT commands. With the FTP security
extensions, authentication established using a security mechanism may also be used
to make the authorization decision.
Without the security extensions, authentication of the client, as this term is usually
understood, never happens. FTP authorization is accomplished with a password,
passed on the network in the clear as the argument to the PASS command. The
possessor of this password is assumed to be authorized to transfer files as the user
named in the USER command, but the identity of the client is never securely
established.
An FTP security interaction begins with a client telling the server what security
mechanism it wants to use with the AUTH command. The server will either accept
this mechanism, reject this mechanism, or, in the case of a server which does not
implement the security extensions, reject the command completely. The client may
try multiple security mechanisms until it requests one which the server accepts. This
allows a rudimentary form of negotiation to take place. (If more complex negotiation
is desired, this may be implemented as a security mechanism.) The server's reply
will indicate if the client must respond with additional data for the security
mechanism to interpret.
If none is needed, this will usually mean that the
mechanism is one where the password (specified by the PASS command) is to be
interpreted differently, such as with a token or one-time password system.
If the server requires additional security information, then the client and server will
enter into a security data exchange. The client will send an ADAT command
containing the first block of security data. The server's reply will indicate if the data
exchange is complete, if there was an error, or if more data is needed. The server's
reply can optionally contain security data for the client to interpret. If more data is
needed, the client will send another ADAT command containing the next block of
data, and await the server's reply. This exchange can continue as many times as
necessary. Once this exchange completes, the client and server have established a
security association. This security association may include authentication (client,
server, or mutual) and keying information for integrity and/or confidentiality,
depending on the mechanism in use.
The term "security data" here is carefully chosen. The purpose of the security data
exchange is to establish a security association, which might not actually include any
authentication at all, between the client and the server as described above. For
instance, a Diffie-Hellman exchange establishes a secret key, but no authentication
Sajid Sayed
Santvan Shah
Final Project
Page 30 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
takes place. If an FTP server has an RSA key pair but the client does not, then the
client can authenticate the server, but the server cannot authenticate the client.
Once a security association is established, authentication, which is a part of this
association, may be used instead of or in addition to the standard
username/password exchange for authorizing a user to connect to the server. A
username specified by the USER command is always required to specify the identity
to be used on the server.
In order to prevent an attacker from inserting or deleting commands on the control
stream, if the security association supports integrity, then the server and client must
use integrity protection on the control stream, unless it first transmits a CCC
command to turn off this requirement. Integrity protection is performed with the
MIC and ENC commands, and the 63z reply codes. The CCC command and its reply
must be transmitted with integrity protection.
Commands and replies may be transmitted without integrity (that is, in the clear or
with confidentiality only) only if no security association is established, the negotiated
security association does not support integrity, or the CCC command has succeeded.
Once the client and server have negotiated with the PBSZ command an acceptable
buffer size for encapsulating protected data over the data channel, the security
mechanism may also be used to protect data channel transfers.
Policy is not specified by this document. In particular, client and server
implementations may choose to implement restrictions on what operations can be
performed depending on the security association which exists. For example, a server
may require that a client authorize via a security mechanism rather than using a
password, require that the client provide a one-time password from a token, require
at least integrity protection on the command channel, or require that certain files
only be transmitted encrypted. An anonymous ftp client might refuse to do file
transfers without integrity protection in order to insure the validity of files
downloaded.
No particular set of functionality is required, except as dependencies described in the
next section. This means that none of authentication, integrity, or confidentiality are
required of an implementation, although a mechanism which does none of these is
not of much use. For example, it is acceptable for a mechanism to implement only
integrity protection, one-way authentication and/or encryption, encryption without
any authentication or integrity protection, or any other subset of functionality if
policy or technical considerations make this desirable. Of course, one peer might
require as a matter of policy stronger protection than the other is able to provide,
preventing perfect interoperability.
Sajid Sayed
Santvan Shah
Final Project
Page 31 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
8.3 Login Authorization
The security data exchange may, among other things, establish the identity of the
client in a secure way to the server. This identity may be used as one input to the
login authorization process.
In response to the FTP login commands (AUTH, PASS, ACCT), the server may choose
to change the sequence of commands and replies specified by RFC 959 as follows.
There are also some new replies available.
If the server is willing to allow the user named by the USER command to log in based
on the identity established by the security data exchange, it should respond with
reply code 232.
If the security mechanism requires a challenge/response password, it should respond
to the USER command with reply code 336. The text part of the reply should contain
the challenge. The client must display the challenge to the user before prompting for
the password in this case. This is particularly relevant to more sophisticated clients
or graphical user interfaces which provide dialog boxes or other modal input. These
clients should be careful not to prompt for the password before the username has
been sent to the server, in case the user needs the challenge in the 336 reply to
construct a valid password.
8.4 Data Channel Encapsulation
When data transfers are protected between the client and server (in either direction),
certain transformations and encapsulations must be performed so that the recipient
can properly decode the transmitted file.
The sender must apply all protection services after transformations associated with
the representation type, file structure, and transfer mode have been performed. The
data sent over the data channel is, for the purposes of protection, to be treated as a
byte stream.
When performing a data transfer in an authenticated manner, the authentication
checks are performed on individual blocks of the file, rather than on the file as a
whole. Consequently, it is possible for insertion attacks to insert blocks into the data
stream (i.e., replays) that authenticate correctly, but result in a corrupted file being
undetected by the receiver. To guard against such attacks, the specific security
mechanism employed should include mechanisms to protect against such attacks.
The sender must take the input byte stream, and break it up into blocks such that
each block, when encoded using a security mechanism specific procedure, will be no
larger than the buffer size negotiated by the client with the PBSZ command. Each
block must be encoded, then transmitted with the length of the encoded block
prepended as a four byte unsigned integer, most significant byte first.
When the end of the file is reached, the sender must encode a block of zero bytes,
and send this final block to the recipient before closing the data connection.
Sajid Sayed
Santvan Shah
Final Project
Page 32 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
The recipient will read the four-byte length, read a block of data that many bytes
long, then decode and verify this block with a security mechanism specific procedure.
This must be repeated until a block encoding a buffer of zero bytes is received. This
indicates the end of the encoded byte stream.
Any transformations associated with the representation type, file structure, and
transfer mode are to be performed by the recipient on the byte stream resulting
from the above process.
When using block transfer mode, the sender's (cleartext) buffer size is independent
of the block size.
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE command if
the current protection level is not at the level dictated by the server's security
requirements for the particular file transfer.
If any data protection services fail at any time during data transfer at the server end
(including an attempt to send a buffer size greater than the negotiated maximum),
the server will send a 535 reply to the data transfer command (either STOR, STOU,
RETR, LIST, NLST, or APPE).
Sajid Sayed
Santvan Shah
Final Project
Page 33 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
9 SFTP Recommendations
The following are some of our recommendations for anyone considering a secure FTP
implementation

If you're a U.S. Federal Agency, you'll probably want to pick a secure FTP
product that is FIPS-140 Certified. If a vendor tells you their product is FIPS140 Certified, ask to see the FIPS-140 Validation Certificate.

If you don't want to manage and administer client side software, you'll want
to find an application service provider (ASP) model that offers secure FTP
functions.

If you want to use secure FTP for collaboration and file sharing, you may want
to consider using a digital vault with an address book that has built-in FTP
security. (A digital vault is a secure online storage receptacle typically set up
as an ASP service.)

If you are a web master updating a web site using a secure FTP product will
ensure that your website login and password information does not get
compromised.

If you are transferring any sort of financial information or credit card numbers
across public networks you should use a secure FTP product if you are not
protected by a VPN.
Sajid Sayed
Santvan Shah
Final Project
Page 34 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
10 Other FTP implementations
Here is a partial list of some other FTP software available:
Troll Ftpd, a free ftp-server, available from
<URL:http://www.troll.no/freebies/ftpd.html>
FileDrive, a commercial file-server which needs its own clients, available from
<URL:http://www.filedrive.com/>
NcFTPd server, commercial server (free for educational domains), available from
<URL:http://www.ncftpd.com/>
ProFTPD, a free ftpserver (GPL), available from <URL:http://www.proftpd.org/>
ftpd-BSD, a port of the OpenBSD ftpd, available from
<URL:http://www.eleves.ens.fr:8080/home/madore/programs/#prog_ftpd-BSD>
Net::FTPServer, written in Perl, available from
<URL:http://ftpserver.bibliotech.net/>
WFTPD, a commercial server for Windows with a Pro version for NT/2000/XP,
available from <URL:http://www.wftpd.com/>
Sajid Sayed
Santvan Shah
Final Project
Page 35 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
11 Key challenges for new research
One of the biggest challenges for IT decision makers is that they are not properly
educated on why they need to use secure FTP products, and under what
circumstance they should use them. In some cases using ordinary FTP is may not
pose much for a risk. For example, using ordinary FTP while on the inside of a VPN is
not that risky, but using it across the unsecured Internet creates increased risk.
To avoid liabilities, vendors who build standard FTP into their products should advise
and educate customers if no security measures have been implemented. By
qualifying whether or not products have built-in security, vendors will limit their
liabilities since customers will be forewarned of the risks involved. If these same
vendors license or build in a secure FTP product for integration into their product,
they will be able to achieve notable marketing leverage in advertising embedded file
transfer security features.
Vendors who sell secure FTP products need to educate prospective customers on why
they need to use these products. Many system and network administrators may not
understand the risks they are taking when using FTP products that do not offer
advanced security features.
In summary, some of the key challenges for new research in this field are:




Migrating the existing regular (anonymous) FTPs to a more secure version
Simplifying encryption for file transfers, so that ordinary users can use it
without any training or expertise.
Simplifying key setup, management, distribution and rotation.
Training and Awareness among users
Sajid Sayed
Santvan Shah
Final Project
Page 36 of 37
CMPT585 - Computer and Data Security - FALL 2004
File Transfer Methods: A Security Perspective
12 References
http://www.cert.org/
http://www.faqs.org/rfcs/rfc959.html
http://www.wu-ftpd.org/
http://www.wu-ftpd.org/rfc/rfc2228.html
http://www.landfield.com/wu-ftpd/
Sajid Sayed
Santvan Shah
Final Project
Page 37 of 37