Kurt Seifried, [email protected], Copyright Kurt Seifried 2001
FTP used to be the king of the Internet, if you wanted to download something you went to your favorite ftp server or used Archie to find the file. Even today the number of ftp servers is staggering, and many ftp sites contain several hundred gigabytes of online archives (take a look at your local sunsite). FTP was built to be an extremely flexible protocol, and therein lie many of it's problems. The FTP protocol not only allows you to transfer files from an ftp server to your machine but from one ftp server to another ftp server directly.
The FTP protocol actually uses two channels for communications, a control channel and a data channel. The control channel uses tcp port 21, clients connect to it from a local port (on Windows for example this is between 1024 and ~5000 or so) and then send and receive information. When you request a file it is send over the data channel which can behave in one of two ways:
With active ftp the client specifies to the server how the transfer will be done. The client chooses a local port and tells the server to send data to it. The server initiates a connection from port 20 to the client and sends the data. The problems with this are numerous, the primary one being the firewalls must allow incoming connections from port 20 to a large selection of ports on internal machines. This allows attackers to easily scan internal machines by initiating connections from port 20.
With passive mode ftp the client asks the server for a file and the server specifies how the transfer will be done. The server chooses a port (typically 1024 to ~5000, incremented by one for each new connection) and then tells the client to connect to that port and receive the file. This has one major advantages over active mode ftp, since the client initiates the connection you do not need to put holes in your firewall to allow incoming connections. However there is a major disadvantage as well.
pasvagg.pl was written by H D Moore of DigitalDefense, and it's very elegant in it's simplicity. pasvagg.pl allows you to steal files that people are trying to download from an ftp server. Because the server opens a port and then waits for the client to connect there is a windows of opportunity for an attacker to connect and receive the files instead of the real user. While several ftp servers do make sure that only the client IP that requested the file can actually receive it, many do not. pasvagg.pl connects to the ftp server, finds out how many connections per second the ftp server is making, and then starts connecting to ports higher up in an attempt to connect to them before the real user does. This allows you to steal files without having to know usernames, passwords or any other details, and can be done randomly with a good chance of success. Unfortunately there is nothing the client can do to protect themselves, it is reliant on the server to protect data transfers.
There are several possible workarounds:
The FTP server could remember which host requested the file and only allow that machine to download it, unfortunately this breaks the FTP standard according to various FTP related RFC's (this is because of multi-homed hosts). However breaking the standard will not affect the majority of hosts since they are not multi-homed (i.e. they only have one network interface).
The FTP server could use active mode ftp, however this will not work through many firewalls since the server must initiate the connection, so the server will no longer be able to talk to many clients.
Lastly the FTP server can choose random ports instead of incrementing them by one for every connection. This will make life for an attacker significantly harder but it is still possible for an attacker to guess a port and grab files before the real client gets them (and if the attacker can continually try several dozen or hundred ports they are virtually guaranteed to grab files).
Unfortunately there is no easy solution that will solve all problems without either breaking standards compliance, or creating other serious problems.
Probably the most popular FTP attack in past was the FTP "bounce" attack. By misusing the PORT command an attacker could use an ftp server to connect to other machines. This allows for all sorts of malicious activity from simple port scanning to moving files around. One program that makes use of this is the Nmap port scanner, using the bounce attack it can use an ftp server to proxy the scan, making it harder to trace back and possibly avoiding firewalls in some configurations. Other common problems include misconfigured FTP servers that allow for people to upload and download files from the same directory, thus turning your ftp server into a global /tmp directory for people to share data with each others (usually "warez"). This of course ignores all the root hacks that have been found over the years in various ftp daemons (including OpenBSD's).
With all these problems in the FTP protocol and various FTP servers one wonders if it's worth trying to fix at all. Personally I think FTP is great for public downloads, i.e. things like software distribution. I do not think FTP is a suitable solution when authentication is required, or the files being transferred are at all sensitive. Luckily several solutions exist, two of which I use:
Rsync is excellent for doing large data transfers and synchronizing large data structures (like ftp sites). If you need to mirror an ftp site this is often a preferred method, and can easily be used over SSH.
The SSH protocol has several ways for transfering data, scp is suitable for quickly copying files around (similar in function to rcp), and there is also sftp support now in OpenSSH. Using scp/sftp is by far more secure then ftp or virtually any other file transfer method and allows for strong user authentication.
In the last few years virtually every ftp server has been hit with a variety of problems ranging from remote root hacks to denial of service attacks. Even OpenBSD's ftpd had a remote root hack in it. Currently vsftpd (Very Secure FTPD) is the only ftp server I know of specifically designed with security as it's main goal.
H D Moore (of http://www.digitaldefense.net/) is the author of pasvagg.pl which exploits passive ftp and can "steal" files that users are downloading.
Kurt: What gave you the idea for the FTP passive attack?
H D Moore: At the time I was doing a comparison of different vulnerability scanners. I was going over the CyberCop report and one of the vulnerabilities it reported was the "Sequential FTP Passive Port". After digging around for a few minutes, I realized that nobody had ever written an exploit for it, so the "Passive Aggression" script was born.
Kurt: Do you have any suggestions on how server admins can avoid your passive ftp attack?
H D Moore: The more popular Unix FTP ftp servers already prevent this attack by default. A connection to a data port by anyone other than the address connected to the control port that requested it is dropped and logged. The newer versions of ProFTPD and WU-FTPD are immune, but any server that allows FXP transfers or "bounce" scanning are vulnerable to this exploit.
Kurt: What do you think of FTP in general?
H D Moore: To be plain, FTP sucks. It forces you to send your username and password in clear text as well as require a separate "data" channel for the actual transfer. Under "active" FTP, your client is forced to open up a port to allow the server to connect back. This is the other side of the "Passive Aggression" exploit, sending the client a different file than the one they requested. To do this you would need to know the client's IP, but the port number is normally static (tcp/20) for root-owned processes under linux as well as most non-unix clients. By repeatedly trying to connect to a client's ftp data port, you are almost gauranteed to be able to replace the file they are trying to download with your own. Uploads are just as fun, by finding the server data port (passive) during an upload request, you could force the system to accept your file instead of the client's. These types of attacks are easy when the server allows anonymous connections or the attacker has account on the system, because they can determine the next passive port by repeatedly sending the "PASV" command and using the next number as the target. Network backups and daily mirroring jobs are one of the easiest targets, because of the timing/race condition which is part of the attack.
Kurt: What alternatives would you reccomend?
H D Moore: For quick and dirty file transfers which dont require a bit of security, netcat is your friend. Using netcat you perform a network tar:
host1 > nc -l -p <port> | tar -zxv host2 > tar -zcv <directory> | nc host1 <port> -vv
This is exactly what the FTP protocol does, except you dont need to send your password across the network to do it. You also have all the features of a unix shell / pipe combination. If you have a command-line encryption utility, you can use it send your files encrypted across the network. Port hijacking is still an issue and you do need shell access to each machine to do this, but it does negate the need for an FTP server on local machines.
For a secure transfer protocol, I recommend scp, part of the OpenSSH package. There are FREE windows clients available, as well as Full-Featured GUI applications by companies like F-Secure. SCP does incur an encryption overhead, but for most cases it is fast enough. For admins that dont want to provide shell access to thier users just to allow them to do secure file transfers, there is a scp-only shell you can install which provides SCP functionality but no shell access. The URL escapes me, but I am sure you can find it on Freshmeat.
Reference links:
http://cui.unige.ch/eao/www/TechInternet/ftp-attack.html
http://www.cert.org/advisories/CA-1997-27.html
ftp://ftp2.netscape.com/ - Netscape ftp server
http://www.wu-ftpd.org/rfc/ - FTP related RFC's
http://rsync.samba.org/ - Rsync
http://www.openssh.org/ - OpenSSH
http://www.wu-ftpd.org/ - WuFTPD
http://www.proftpd.net/ - ProFTPD
ftp://ferret.lmh.ox.ac.uk/pub/linux/ - vsftpd
Last updated 9/10/2001
Copyright Kurt Seifried 2001