2

Saintbot PCI/vuln scanner (via Controlscan) is flagging FTP port 21 vulnerable to Sweet32, based on the existence of a 3DES "grade C" cipher.

The fix is easy -- update the available ciphers to be more secure. However Cpanel v62 has a current "issue" where their version of PureFTP does not obey ciphers set forth in pure-ftpd.conf.

This causes a PCI fail until we switch to ProFTP. We don't really want to do that....at all.

Question is, can/does Sweet32 even work with FTP or similar style "authenticated" connections? I want to attest their finding, unless it's actually possible to pull this attack off on non-web tunnels.

dhaupin
  • 161
  • 1
  • 7
  • Final thought: IMO this attack is pretty much theoretical. It is not possible via any port if better ciphers than 3DES are included in the list. To make it possible, a TLS/cipher downgrade would be needed in addition to Sweet32, and all data would need to flow on 1 single TLS pipe using the same keys, through a MITM. For FTP, that data would need to contain enough minable data (785GB+) to make identifier assimilation a possibility to begin with. Highly unlikely that we will see this pulled off anywhere but in a lab. – dhaupin Feb 16 '17 at 16:30

1 Answers1

2

Sweet32 does not specifically attack authentication but it tries to extract secrets contained in kind of structured, partly known and very large data. Authentication information in the HTTP header fit this description if it is possible to send lots of HTTP requests over the same TLS connection. But depending on the kind, amount and sensivity of data you transfer with FTP this can be a problem for FTP too.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Hmm interesting. So say there is a ~10 min window of inactivity, and clients FTP session is booted on server side, forcing re-auth. Client reconnects 30 min later to upload more. Is this is a "different" TLS connection in the eyes of Sweet32? Is it still able to assimilate with intermittent data flow? Forgive my noobness, I'm not adept with the semantics of this vector. – dhaupin Feb 15 '17 at 23:31
  • @dhaupin: FTP has a control connection for the command and for each new transfer (upload, download, listing...) a data connection. The control connection is probably not the problem since too few data so I guess the login credentials itself are not in danger. But if you transfer well structured files where the attacker can have knowledge of some plain text and wants to guess a repeated secret inside the files then it might be possible. Just imagine an uncompressed archive with thousands of similar transactions and the attacker wants to guess the some secret ID used in all these transactions. – Steffen Ullrich Feb 16 '17 at 05:34
  • 1
    @dhaupin: additionally many FTP servers support or even require TLS session reuse between data connections so that it does not matter if this is a single large file transfer or thousands of smaller transfer since the key used is still the same due to session reuse. – Steffen Ullrich Feb 16 '17 at 05:35
  • 1
    If you mean reusing the TLS _connection_ yes but if you mean a new connection using TLS session resumption that (re)uses the _same master secret_ but derives _new keys/IVs_, see (recent!) http://security.stackexchange.com/q/151141/ – dave_thompson_085 Feb 16 '17 at 11:27
  • 1
    @dave_thompson_085: thank's for pointing this out. I wasn't aware of it. This means to trigger the problem a single large data transfer (i.e. one TCP connection) is needed and multiple transfers (multiple TCP connections) are not enough even if they share the same TLS session. – Steffen Ullrich Feb 16 '17 at 12:10
  • @SteffenUllrich Thanks guys, that helps to clarify. In theory, how big of a single large transfer would be needed? The spec says an attacker needs to capture ~785GB of data. Does this imply that the large transfer would need to be at or above that size? – dhaupin Feb 16 '17 at 15:09
  • @dhaupin: it depends on the data but if they are similar structured as HTTP (i.e. some lines of HTTP request, most of them known and only the cookies needs to be guessed) then this is about the size you need. – Steffen Ullrich Feb 16 '17 at 15:15
  • @SteffenUllrich Ok thanks. Makes sense. I highly doubt that we will ever init a 785GB+ transfer containing enough HTTPish fingerprints via FTP. I'm gonna consider this one "attestable". – dhaupin Feb 16 '17 at 15:34