Filezilla FTP server is vulnerable to FTP PORT bounce attack and PASV connection theft

Filezilla FTP server is vulnerable to FTP PORT bounce attack and PASV connection theft

Date: May 6th, 2015

Filezilla FTP server (affected versions: 0.8.0 - 0.9.50) is vulnerable to PORT bounce attack and to PASV connection theft. The attack concepts are very old. FTP PORT bounce attack is described e.g. in Hobbit’s 1995 writeup “The FTP Bounce Attack” and in CERT’s 1998 tech tip “Problems With The FTP PORT Command or Why You Don't Want Just Any PORT in a Storm” (originally at http://www.cert.org/tech_tips/ftp_port_attacks.html, that page is no longer responsive; mirrored at http://web.archive.org/web/20131105191347/http:/www.cert.org/tech_tips/ftp_port_attacks.html). Among the first descriptions of the PASV connection theft attack are David Sacerdote’s 1996 paper “Some problems with the File Transfer Protocol, a failure of common implementations, and suggestions for repair”, Jeffrey R. Gerber’s 1999 paper “FTP PASV ‘Pizza Thief’ Exploit” (originally at http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt but no longer available there; mirrored at https://web.archive.org/web/20000303212433/http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt), and Daniel J. Bernstein’s 1999 paper “PASV security and PORT security”, which names the attack and discusses effective and ineffective defense mechanisms. This advisory will refer to Bernstein’s work for terminology.

Filezilla FTP server was designed to protect against these attacks chiefly by verifying that the data channel remote IP address is identical (in “strict mode”) or at least from the same class C (in the more relaxed mode, which is the default) to the control channel remote IP address. See the Filezilla Server Interface (GUI) screenshot:

 

Unfortunately, due to a bug in Filezilla FTP server (introduced in version 0.8.0, released January 1st, 2003), it is not the remote IP address of the channels which is subject to these tests, but rather the local IP address. This means that as long as the control channel and the data channel are established to the same IP address (that of the Filezilla server, naturally), the security test is passed, regardless of the remote addresses. In other words, practically there’s no IP address restriction, no matter what settings are chosen in the Filezilla server GUI.

For the (PORT) bounce attack, the net result is that the attack can proceed without hindrance.

For PASV connection theft, Filezilla FTP server offers an additional de-facto security layer in the form of a weak variant of “PASV SYN protection”, namely “Closing a socket as soon as accept() succeeds”. From experiments, Filezilla doesn’t verify that there’s only a single TCP connection established to the data port. It does close the listening port for the data channel almost immediately after the first connection is established (this is done after the accept() call returns). However, as Bernstein mentions, this defense is inadequate. It is still possible to have two (or even more) connections established to the data port (the first one is the attacker’s and the second one is the legitimate client’s), with the extra connections being sent RST by the Windows server soon after they’re established (in experiments, this was around 0.2-0.4 milliseconds after the first connection is established) due to the application (Filezilla FTP server) not accepting them and closing the listening socket (after the first accept()). Moreover, on Windows 8 the port number is used by Filezilla for the passive connection is predictable (it increments by 1 on each incoming connection, if there’s no additional port-consuming activity on the server).

This means that it is possible to mount a “PASV connection theft” attack against Filezilla FTP server from any IP address. Such attack requires accurate timing on behalf of the attacker (to both win the race condition, and yet allow the legitimate client to momentarily establish a connection), and a bit of guesswork or enumeration (to get the port guessing right). First the attacker needs to predict the port Filezilla server will use for the data channel. If the attacker has access to the FTP service (i.e. has an account, or can use a public account), the attacker can obtain a port number sent by the server in a PASV response, and presume that the next port to be assigned is the port he/she received, incremented by 1 (the attacker can of course try increments by other small numbers to compensate for additional port consuming activities taking place in the meanwhile). Next, the attacker waits for the legitimate client’s session to reach the point where Filezilla opens a data port. The attacker then needs to carefully time his/her actions: the attacker needs to establish a 3-way TCP handshake to that port such that the final ACK packet will reach the Filezilla server just before the ACK packet of the 3-way TCP handshake established by the legitimate client. If the attacker manages to establish the TCP connection before the legitimate client, but in such timing that the legitimate client’s TCP connection is established before the port is closed, then the attacker’s TCP connection will be used by Filezilla server as the data connection, while the legitimate client’s TCP connection is established successfully, thus allowing the FTP logic on the legitimate client to proceed, issuing e.g. RETR/STOR/LIST, resulting in the data being sent or received via the data channel open between Filezilla server and the attacker. The end result is data theft (RETR – file, LIST – directory) or data spoofing (STOR – file).

The attack was simulated successfully over a switched LAN with the legitimate FTP client being Internet Explorer 11 (RETR scenario).

FXP transfers are also possible (again, regardless of the GUI settings) and trivial to mount because the PASV additional hurdle is irrelevant – the FTP servers are coordinated and hence there’s no race condition.

A new version of Filezilla FTP server (0.9.51) is available for immediate download at https://filezilla-project.org/download.php?type=server

I would like to thank the vendor (Tim Kosse) for his prompt response and highly professional and friendly conduct.

BugTraq ID: 74535