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.

Improve this question
1
  • 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, 2017 at 16:30

1 Answer 1

Reset to default
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.

Improve this answer
8
  • 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, 2017 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, 2017 at 5: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, 2017 at 5: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!) security.stackexchange.com/q/151141
    – dave_thompson_085
    Feb 16, 2017 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, 2017 at 12:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .