Proof-of-concept exploit for FTP over TLS data connection stealing
Full exploit here: https://filezilla-project.org/misc/ftps ... xploit.cpp
Below the description:
FTP suffers from data connection stealing vulnerability . While there are mitigations for plaintext FTP they are incomplete. Without bi-directional authentication, an attacker can steal the data connections and do tricks like swapping connections between users.
There are two mechanisms in FTP over TLS that can solve connection stealing:
- Client certificates [a] and
- TLS session resumption 
In the following we will discuss how TLS session resumption benefits FTP over TLS and how incorrect implementations, despite requiring session resumption on the data connection, still allow connection stealing.
FTP over TLS and TLS session resumption
Not only does session resumption speeds up the data connection handshake, it also guarantees the authenticity of the data connection: If the same session is used for both the control connection and the data connection, both client and server know that the data connection is authentic.
With an unresumed session, the client can only check that the connection comes from the server. The client however cannot verify that the data connection is associated with his control connection.
Likewise, without resumption the server cannot verify the authenticity of the client.
Session resumption can be facilitaded through different means:
- Session IDs and a server-side session cache
- Session tickets sent to the client
Both work equally well for FTP over TLS.
Due to an implementation flaw in some servers, an attacker can inject his own session into the server's TLS context.
The problem is that these servers, while requiring session resumption, do not verify that it is indeed the same session on both control- and data connection. Thus, if an attacker can inject a session, he can then resume it and thus successfully steal data connections.
Let's assume Alice wants to download a file from Bob. She has established a control connection with Bob and has just issued the PASV and RETR commands. Mallory sees Alice's attempt to establish the data connection and connects to the server in place of Alice. Mallory does however not know a valid session on the server.
After the data connection handshake, Bob checks whether the connection was resumed and, noticing it isn't, drops it.
At this point however, Mallory now knows of a valid session: The one that just got closed! He now either has a session ID or a session ticket.
The next time Alice wants to transfer a file using the same control connection to Bob, Mallory attempts to steal the connection again. Mallory presents his own session in the TLS handshake. Bob sees that the connection is resumed. Not checking that the session matches the session of the data connection, Bob then proceeds sending the file to who he believes is Alice.
In the following we assume that the FTP server uses OpenSSL to keep things simple and concrete. There is no reason however to assume that the problem does not occur with other TLS implementations.
When performing a handshake that isn't resumed, OpenSSL adds the new session to its session cache and sends a session ticket to the client. This is done before the FTP server checks whether the session is resumed or not, thus even if the server decides to drop the unresumed connection, the client now has valid session credentials.
The next time the client connects he can thus present a valid session to the server.
There are at least two feasible solutions:
If the server sees an unresumed handshake on the data connection, the server should close not only the data connection but also the control connection . Note that this requires that the lifetime of session IDs and session tickets is bound to the lifetime of the control connection. A server that uses a single long-lived TLS context cannot use this solution.
The server can verify that the session of the control connection is the same as the session of the data connection. Note: At least with OpenSSL, it is not obvious how to do this .
This is a partial list of affected servers, there may be many more that
haven't been tested.
- vsftpd 3.0.2 or earlier, fixed in 3.0.3
- ProFTPD 1.3.5 or earlier, fixed in 1.3.5a
- FileZilla Server 0.9.50 or earlier, fixed in 0.9.51
[a] I believe that with client certificates an attacker could still swap data
connections belonging to the same user.
 https://web.archive.org/web/20000303212 ... sec_01.txt
 http://scarybeastsecurity.blogspot.de/2 ... eased.html
 http://vincent.bernat.im/en/blog/2011-s ... c5077.html
 Solution proposed by Chris Evans <email@example.com