End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem

https://brokencloudstorage.info/

This was shared as part of the "Programmer Weekly" newletter. Below is their description:

This research analyzes five major end-to-end encrypted cloud storage providers (Sync, pCloud, Icedrive, Seafile, and Tresorit), revealing severe cryptographic vulnerabilities in four of them. The study exposes common failure patterns across independent designs, demonstrating that creating secure E2EE cloud storage is more challenging than initially thought, with vulnerabilities ranging from file injection to breaking confidentiality of uploaded files.

This is not directly related to rclone but may be of interest to those who rely on these services (with or withour rclone crypt) and crypt shares some of the same stack.

note: I am not suggesting there is a flaw with rclone crypt. Sharing similar approaches does not equate to the same issues. I am not even close to an SME on the subject matter. I suspect these services have a much harder job since they also have to distribute the keys.

My goal with this post is to (a) share for those interested and (b) spur discussion. It is not to spread fear or rumors or suggest anything.

3 Likes

I am not a professional security researcher, but I could imagine that rclone crypt is less prone to some of these attacks.

TL;DR: Most of the key-management problems seem to be related to convenience features w.r.t. the password management and the remaining "data tampering issues" could potentially be overcome with something like git-annex git-annex->rclone.

First of all the "password replacement": It seems that pcloud ties the passwords to the original user authentication somehow. For crypt storage the (2) passwords need to be generated on the users machine, so this should not be an issue for rclone (crypt).

  1. The sharing of keys is not directly supported via crypt-storage, unless you either unencrypt manually or share your keys with your friends or (best solution) create a new crypt-storage and only share those new keys with your friends.

  2. Protocol Downgrade: As everything happens locally, also does not seem reasonable. Perhaps one of the developers can shed more light on this?

So I think we can summarize 1-3 as security flaws due to well-intended but badly implemented convenience features.

  1. Tampering with file names and location &

  2. Tampering with file metadata

    I think both of these should be partially possible with rclone crypt storage.
    You can easily test such attacks yourself, as you can always mount the unencrypted storage as well.
    Please note that due to the encryption of the filenames renaming is a rather limited attack vector. One would probably quickly notice such "renamings" or "file shufflings" as they would appear like corrupted data.

    The only exception is a dictionary attack if you have a lot of similar sounding filenames, as rclone does not salt the filenames (you can easily test this yourself). As the used key-phrase (for file-name encryption) is derived from the original key-phrase this might be an attack vector to deduce the original pass-phrase, but I personally think it is a rather weak attack vector, as it is still a derived password.

    It is definitely possible, to copy data around and put it into different folders.

    I think it might be possible to counter-act most of that by combining rclone with git-annex c.f. git-annex->rclone. But I haven't further investigated it.

  3. Injection of Files

  4. Injection of Folders
    Injecting files should not be easily possible, due to salting + encryption. What I mean is: Obviously you can dump some file in there, but it would appear like corrupted data, if you can't break the encryption. So it seems to be of rather limited utility.
    Folder are potentially a weak-point in case of a succesful dictionary attack (see above) or if you just reuse existing folder names.

    I think one could also potentially overcome this with git-annex.

  5. Unauthentication of encryption modes.
    I am not sure if I understand this correctly. The encryption algorithm is run locally and always the same. So I guess there is no negotiation (and downgrade) happening here.

  6. Unauthenticated chunking.

    The chunking in rclone seems to be tied to the original encryption key. I don't see a way to modify it, without generating garbage, but I am not entirely sure. Can one of the developers shed some light on this, please?

    It seems this is also something that could be countered with git-annex.

Conclusion: Perhaps one should integrate a git-annex-like remote into rclone itself. Has something like this been discussed already?

That is a great reply. I too am not an expert so take this with a grain of salt

I am less certain about a dictionary attack. While the names are not randomly salted, the password (maybe password2?) is like a salt for the names so you couldn't do a dictionary attack. Less secure than true salted names but needed for repeatability

I actually think the rclone scheme is susceptible to "Unauthenticated chunking" or something similar. The way rclone works, it does not ensure file integrity. It is an unauthenticated encryption.

I suspect this is by design to allow streaming the file up and down with only having to read the first couple bytes to get the salt then able to read it in chunks.

It's a reasonable tradeoff in my opinion since any tampering with the files will be evident when decryption fails.

Again, I am far from an expert and welcome corrections or clarifications.

This would further obfuscate the names as they would be stored in encrypted files with the actual data in encrypted names of content addressable storage. But it would introduce considerable overhead for little in savings.

This is an interesting discussion on the challenges of implementing truly secure end-to-end encryption in cloud storage. The research highlights how even well-known providers struggle with vulnerabilities, which raises concerns for users who prioritize security.

For those looking for alternative cloud storage options, I've been exploring TeraBox Mod APK, which offers enhanced storage features beyond the usual limitations. While it's not a direct E2EE solution like the providers mentioned, it can be useful for those who need more flexible cloud storage options. Security remains a key concern, though, so it's always good to research encryption methods before trusting any service with sensitive data.

Looking forward to hearing more thoughts on how rclone crypt compares to these E2EE implementations!