CESA-2008-002 - rev 1
[See all my vulnerabilities at
http://scary.beasts.org/security]
[Blog if you want to subscribe to new findings is at
http://scarybeastsecurity.blogspot.com/]
Notes on the state of the security of FTP data connections over SSL
Programs affected: Many FTP clients and servers.
Severity: Possible hijack of FTP data connection despite SSL.
This is more of a technical note rather than a new vulnerability. It is worth
noting that both FTP clients and FTP servers are to blame. Perhaps no-one
cares. Certainly, not many people are using FTP over SSL. The main reason
I'm writing this note up is that I haven't found a decent document elsewhere.
(The original RFC, draft-murray-auth-ftp-ssl-16.txt, even has a section on
the importance of client certs so the current state of affairs is surprising).
The problem is that whereas the FTP control connection has authentication in
the protocol, the FTP data connections (send and receive) do not. We can
naively say: we set things up to use SSL for the data connections, so
cryptography makes us secure. But as usual, cryptography != security. If an
attacker connects and SSL handshakes on the data connection before the
legitimate user, they get to either steal the download, or supply the upload.
The likelihood of seeing this attack in the wild is probably quite low:
- Modern FTP servers require a matching IP address on the control connection
and data connections. So an attacker needs to have active MITM capability to
play this game well.
- A decent modern FTP server will randomize listen ports for PASV data
connection. Even wu-ftpd seems to do this (ftp.wu-ftpd.org). Although, the
occasional ftp client still defaults to PORT data connectons, which makes the
attacker's job easier.
- Who is using FTP / SSL to do sensitive data transfers anyway?
Solutions
The best solution unfortunately requires a certain server-side and client-side
behaviour. Clients should send SSL client certs, and the server should check
the cert presented on data connections is the same as the one presented on the
associated control connection.
Some clients allow certs to be sent, but this tends to default to off. The
"ftp-ssl" command-line tool has the useful -z option. Other clients, including
popular graphical ones, have no way to specify a client cert.
I've even been quite lazy with
vsftpd
in this area; only in the recent v2.0.6 release did I implement client cert
support. Again, no-one (users or FTP clients) seem to really care, and I'm good
at being lazy given half an excuse :) vsftpd 2.0.6 offers independent options
to insist the client sends a cert, and to validate the cert is valid and signed
by a recognized authority. If a cert is ever seen on the control connection
(regardless of whether it is required or not), the same cert must appear on
the data connection. Interestingly, even self-signed certs seem to have value
as client-certs. The server-side digest view of the client cert seems to
include some of the unique entropy associated with a cert as well as the
textual name fields.
For clients that can't resonably be modified, I have a crazy idea to use the
SSL session cache as a cheezy form of authentication. I don't yet have info on
what percentage of clients request session re-use on their data connections,
nor have I analyzed whether a server-side session cache hit represents a
cryptographic-strength guarantee that the connection came from the same
client.
Finally note that an active MITM could likely do much worse than mess with
theft of data connections. A lot of FTP clients by default do no checking of
the server cert.
There are other interesting attacks against FTP clients which issue FTP commands
prior to "AUTH TLS". For example, an attacker can force a downgrade attack
by forging the response to "FEAT" to not include "AUTH SSL" or "AUTH TLS", if
the client drives its behaviour from this response. Such clients do exist.
CESA-2008-002 - rev 1
Chris Evans
scarybeasts@gmail.com