Castaglia/proftpd-mod_proxy

ProFTPd server flagged for "FTPS Cleartext Fallback Security Bypass"

ws0w opened this issue · 10 comments

ws0w commented

This is really more of a question that an issue report ....

Tenable has flagged two of my ProfTPD servers for a vulnerability:

FTPS Cleartext Fallback Security Bypass

The report says that after a failed TLS negotiation, the server responded to the "FEAT" command with a list of features the server supports.

I can telnet to port 21 and get a valid response to the FEAT command, but I'm not sure that's a vulnerability ... any other command gets the error: "550 SSL/TLS required on the control channel" (or "500 Invalid command: try being more creative")

I'm thinking that responding to FEAT in the clear is not really an example of the flagged vulnerability.

What are your thoughts on this?

Castaglia commented

IMHO, the FEAT command should be accepted before any AUTH TLS command occurs; issuing a FEAT command is how a well-behaved client can "discover" that the server accepts/supports FTPS.

A brief reading of the Tenable docs for this suggest that responding to FEAT -- by itself -- is not a problem. Or rather, that the issue they are flagging is that a client tries do the TLS handshake first, and -- assuming that TLS handshake files -- then sends a FEAT request. Their docs suggest that a "good" FTPS server, if it fails the TLS handshake, would close the control connection altogether.

I'll see if I can reproduce this behavior locally. If that does indeed happen -- a good response to a FEAT command, sent after a failed TLS handshake on the control connection, then I would think it's a bug, in the mod_tls module. (Failed TLS handshakes for data transfers can occur for many reasons, and thus are common; I would not think that they should be treated as a bug/failure. If this Nessus module does so, it's a bug in their Nessus logic.)

Castaglia commented

What ProFTPD version is running, on your flagged servers? Reading through these docs:

makes it sound exactly like Bug #3624, which should have been fixed long ago. (It's possible that it has regressed, hence the checking of the version.) And, reading the comments in that old bug report, perhaps the necessary clearing of buffers is not happening for failed TLS handshakes. Hmm.

I don't suppose you'd have detailed TLSLog (especially with TLSOptions EnableDiags enabled) for these Tenable scans/checks?

Castaglia commented

And, to muddy the waters further, the code seen here (which purports to be that same Nessus plugin) uses port 990, not port 21. ProFTPD doesn't use port 990 for FTPS connections unless configured to do so; are you using that configuration, for implicit FTPS connections?

This could, of course, just be a false positive:

# Get all known FTP ports, forking as necessary.
port = get_ftp_port(default:990);

# Ignore the port if it's not known to be an SSL port, since trying
# this against an unencrypted port would result in a false positive.
encaps = get_kb_item_or_exit("Transports/TCP/" + port);
if (encaps < ENCAPS_SSLv2 || encaps > COMPAT_ENCAPS_TLSv12)
  exit(0, "The FTP server on port " + port + " does not appear to be FTPS.");

I don't see any attempt to do the "STARTTLS" approach (sending AUTH TLS) here. Sigh. This thing looks like it was written to assume only implicit FTPS (which is infrequent, and discouraged by RFC). Typical.

(I can't say that I'm impressed by the lack of proper error/sanity checking in this Nessus plugin code; I tend to have a low opinion of such scanners, as they create more noise and stress than is actually warranted.)

ws0w commented

I get 1.3.7rc1 from proftpd -v .... we're using port 21 ...
I do have the TLS log from the time the scan was happening, but did not have TLSOptions EnableDiags enabled.

There are a lot of entries like this the day the scan happened, if it's useful:

2021-02-11 02:01:39,006 mod_tls/2.8[22872348]: TLS/TLS-C requested, starting TLS handshake
2021-02-11 02:01:39,007 mod_tls/2.8[22872348]: unable to accept TLS connection: protocol error:
2021-02-11 02:01:39,007 mod_tls/2.8[22872348]: unable to accept TLS connection: perhaps client requested disabled TLS protocol version: SSLv2, SSLv3, TLSv1, TLSv1.1
2021-02-11 02:01:39,007 mod_tls/2.8[22872348]: TLS/TLS-C negotiation failed on control channel

I was going to try to match it with FEAT commands using the pid, but the Feb 11 syslog is gone.

ws0w commented

I was able to retrieve the syslog for Feb 11 and I could not find a PID that issued FEAT commands and also had a TLS handshake failure in the TLS.log

My experience has been that Tenable's tests (especially related to FTP) frequently do not do what they think they do..

ws0w commented

It looks like a False positive to me, but I could add EnableDiags and request another scan if you think there's a change that would be helpful.

Castaglia commented

If it's not too much trouble, having them scan again would be useful, using e.g:

SystemLog /path/to/proftpd.log
DebugLevel 10

# Send mod_tls logs to the same file as normal ProFTPD logs
TLSLog /path/to/proftpd.log
TLSOptions EnableDiags

This way, we can see the FTP commands the client sends, along with the corresponding TLS commands/handshakes.

ws0w commented

I mad the requested logging change and requested another scan 5 days ago. I can tell from the logs that no scan has taken place. They're now flagging other servers that don't hae the additional logging.

I'll request another scan.

Castaglia commented

OK, no worries. Thanks for the update!

Castaglia commented

I found that this ticket was still open, so I did a little more research/work on it, which results in some regression tests to assert that ProFTPD is indeed doing the right thing; see proftpd/proftpd#1478.

I also ran the above tests against ProFTPD 1.3.7rc1 (and they passed); ProFTPD closes the FTP control connection if the TLS handshake fails, and does not leave that connection open in plaintext mode.

I should note, however, that there is one possible ProFTPD configuration that would result in a false-positive report, based on that linked Nessus scanner:

Port 990
TLSEngine on

# If we do NOT use the UseImplicitSSL TLSOption here, it could fool scanners making assumptions
# about how port 990 for FTP should be handled.

In the above situation, we have ProFTPD listening on port 990, the "implicit" FTPS port. The expected behavior is that the TLS handshake should occur immediately after connecting to port 990, and before issuing any other commands. With the above configuration, ProFTPD would not require that TLS handshake on port 990, though, because that particular "expect TLS handshake on connect" is enabled by the UseImplicitSSL TLSOption, not by the use of port 990. This means that a scanner could connect to port 990, not perform a TLS handshake, and issue the FEAT command -- just as if it were connecting to port 21. So the issue, in my opinion, is still that the scanner is flagging a false positive problem, when there is no problem.

I'm thus going to close this ticket. If we get similar reports from scanners/tools in the future, we'll take a look then.

Thanks!