https://brokencloudstorage.info/ * Overview * Attacks * State of the Industry * Disclosure * About Us * Read the Paper --------------------------------------------------------------------- End-to-End Encrypted Cloud Storage in the Wild A Broken Ecosystem Jonas Hofmann, Kien Tuong Truong. Work to appear at ACM CCS 2024 Cloud storage is ubiquitous: Google Drive, Dropbox, and OneDrive are household names. However, these services do not provide end-to-end encryption (E2EE), meaning that the provider has access to the data stored on their servers. The promise of end-to-end encrypted cloud storage is that users can have the best of both worlds, keeping control of their data using cryptographic techniques, while still benefiting from low-cost storage solutions. However, previous analyses of MEGA and NextCloud have shown that even the largest providers of E2EE cloud storage are affected by cryptographic vulnerabilities and creating secure E2EE cloud storage is a harder problem than initially thought. Indeed, we show that the current ecosystem of E2EE cloud storage is largely broken. We conduct a cryptographic analysis of five major providers in the field, namely Sync, pCloud, Icedrive, Seafile, and Tresorit, in the setting of a malicious server. We unveil severe cryptographic vulnerabilities in the first four. The vulnerabilities range in severity: in many cases a malicious server can inject files, tamper with file data, and even gain direct access to plaintext. Remarkably, many of our attacks affect multiple providers in the same way, revealing common failure patterns in independent cryptographic designs. Read the Paper Overview * Sync * pCloud * Seafile * Icedrive * Tresorit Sync is a Canadian cloud storage provider founded in 2011 with more than 2 million users worldwide, including high profile institutions such as the government of Canada, the university of Toronto, and the Canadian red cross. It claims to store more than 130 petabytes of data. Our attacks allow a malicious server to break the confidentiality of uploaded files, as well as injecting files and tampering with their content. Cryptographic Primitives * Key Derivation + PBKDF2-SHA256 (random salt) * Symmetric Encryption + AES-GCM * Asymmetric Encryption + RSA-PKCS1v1.5 Key Hierarchy [sync_key_h] Attacks Key Replacement Link Sharing Leakage Tampering with Filenames Tampering with Metadata Folder Injection File Injection Key Replacement Attack This attack breaks confidentiality of all files uploaded after the server has been compromised. Many providers use RSA to encrypt cryptographic keys, which are then used to encrypt files. When using a solid primitive, like RSA-OAEP, the attacker is unable to directly decrypt the keys. However, RSA-OAEP provides confidentiality but not origin-authentication. In particular, the server can encrypt arbitrary cryptographic material and substitute it to the user's. The user will then use the server-chosen cryptographic material to encrypt their data. The server is then able to decrypt all data that has been uploaded after the substitution has taken place. Link Sharing Leakage This attack breaks confidentiality of all files shared via a link as soon as the link is clicked. Sync allows users to share data in a temporary fashion using links. These links contain a link password in plaintext, from which a key is derived that can be used to decrypt the file. When clicking the link, this password is sent to the server in plaintext, trivially leaking any information shared in this way. The problem here is that the password is part of the URL, rather than being encoded in the URL fragment (i.e. the part after the #, which is client-side only). Tampering with Filenames This attack breaks the integrity of all file names. In Sync, files are uniquely identified by a server-chosen ID. Ideally, the data, name and path of the files should be bound to this identifier, so that the contents of two files cannot be swapped or moved. However, for Sync, no such binding is present, allowing the server to move files anywhere in the storage and to swap the names of files. Tampering with Metadata This attack breaks the integrity of all file metadata. In Sync, some metadata is unencrypted and unauthenticated and can be arbitrarily manipulated by the server. This metadata includes fields like file size, file type or time of origin. More importantly, for shared files in Sync, it contains information about who created the file or folder. This means that the server can make it appear as if a file has been created by a different user, which is particularly relevant for shared folders. Additionally, the server can make it appear as if the user had shared a folder with any arbitrary user. For example, a malicious server could frame an employee by adding a company competitor to the list of people who have access to a confidential folder and accuse the employee of industrial espionage. Folder Injection This attack injects a folder with arbitrary content in the storage of any user. The intuition is that the server can simulate the process of permanently sharing a folder, as if it originated from an honest user and was accepted by the victim. Fundamentally, this relies on the fact that folders are shared by encrypting a symmetric key with the public key of the user. Once again, this provides confidentiality but does not provide authentication. The server can then inject a new folder simply by adding it to the list of shared folders and adding a new symmetric key. Then, the server can modify the metadata of the folder and make it appear in the user interface as if the user uploaded the folder themselves. This aesthetic change makes the injected folder indistinguishable from a honestly uploaded folder when observing the user interface. File Injection This attack injects a file with arbitrary content in the storage of any user. This attack is a direct consequence of the Key Replacement attack. After substituting the key, the server can now also inject arbitrary files in the storage, as it knows the symmetric key which the user will utilize. pCloud is a Swiss-based cloud storage provider founded in 2013 with more than 20 million users worldwide and claiming to be "Europe's most secure cloud storage" Our attacks allow a malicious server to break the confidentiality of uploaded files, as well as injecting files and tampering with their content. Cryptographic Primitives * Key Derivation + PBKDF2-SHA512 (random salt) * Symmetric Encryption + AES-CTR (variation) + Custom authenticated mode of operation * Asymmetric Encryption + RSA-OAEP Key Hierarchy [pcloud_key] Attacks Key Replacement Key Overwriting Unauthenticated Chunking Tampering with Files and Filedata Tampering with Metadata Folder/File Injection Key Replacement This attack breaks confidentiality of all file names of files uploaded after the server has been compromised. pCloud uses unauthenticated public key encryption (RSA-OAEP) to encrypt the keys used to encrypt file names, so called "folder keys". Whenever the client requests the encrypted folder key from the server, the adversary can choose a different folder key, encrypt it under the user's public key and serve it to the client. The client then proceeds to use this malicious key to encrypt file names, leaking them to the server. Key Overwriting This attack breaks confidentiality of all files uploaded after the server has been compromised. The user private key is sent to the client in encrypted fashion. The encryption is done using a custom variation of AES in counter mode, which is not authenticated and allows an attacker to arbitrarily flip bits in the plaintext by flipping the corresponding bits in the ciphertext. The principle is that the adversary can force the user to use a maliciously-chosen public key, which violates confidentiality. Unauthenticated Chunking This attack breaks integrity of all files, allowing an adversary to remove 4096 bytes at a time. PCloud supports chunking of files. The encryption for each chunk is conducted separately, so the chunks are cryptographically independent. Thus, an authentication mechanism is required to ensure integrity of the file. In pCloud, the client uses a Merkle tree of HMAC tags to provide integrity. However, the construction that pCloud uses is insecure. This allows an adversary to serve only a subtree of the Merkle tree, which the client will decrypt without raising errors. The consequence is that the server can decide to remove entire chunks from the user's data. Tampering with Files Names and Location This attack allows an attacker to swap file names and to move files in the storage. In pCloud, file names are bound to their parent folder but they are not bound to the file contents. Further, the file contents are in no way bound to the folder. This means that (1) file names can be swapped within the same folder, and (2) file contents can be placed anywhere in the storage and associated to any existing file name. Tampering with Metadata This attack allows an attacker to tamper with all file metadata in the storage. Most of the file metadata in pCloud is unauthenticated and can be changed arbitrarily by the server. Folder/File Injection This attack allows an attacker to inject arbitrary files and folders in the storage of the user. Further, the attacker can substitute the content of any file with arbitrary content. In pCloud, a malicious server is able to insert arbitrary files into the user's storage by using the fact that the user's public key is also known to the server. As all file keys in pCloud are encrypted using this public key and are not authenticated, the server can generate new file keys and encrypt a chosen file with them and add the file to an arbitrary folder. Creating a valid encrypted file name proves harder, since the file names are encrypted using the folder key. However, we can build upon the "Tampering with Filenames" attack and use an encrypted file name belonging to a different file, exploiting the lack of binding between file contents and names. In fact, a direct consequence of the combination of these two attacks is that the pCloud server can substitute an existing file's contents with arbitrary data. Seafile is an open-source cloud storage provider founded in 2012 with more than one million users worldwide. In contrast to the other providers we analyze, Seafile also offers a self-hosting solution. Among the organizations using it are Kaspersky Lab, the Humboldt University in Berlin, the University of Strasbourg, and the University of Turku. Our attacks allow a malicious server to speed-up bruteforcing of user passwords, as well as injecting files and tampering with their content. Cryptographic Primitives * Key Derivation + PBKDF2-SHA256 + BytesToKey-SHA1 * Symmetric Encryption + AES-128-CBC + AES-256-CBC + AES-128-ECB Key Hierarchy [seafile_ke] Attacks Protocol Downgrade Unauthenticated Encryption Unauthenticated Chunking Tampering with Files Tampering with Metadata Folder/File Injection Protocol Downgrade This attack allows a malicious server to speed up password bruteforcing by several orders of magnitude. Seafile supports multiple versions of its protocols and the client uses server-provided information to choose which version to use. The server can then downgrade security to the one of the oldest version and exploit its weaknesses. In our attack, the server targets a so-called "magic string" generated by the client and sent to the server during the creation of a repository. This string is generated by applying a key derivation function to the user password. In version 0 of the protocol, a very weak key derivation function (BytesToKey-SHA1) is used, which allows for very quick password bruteforcing. After our disclosure, this attack has been patched by Seafile in version 9.0.6 of the client. Unauthenticated Encryption This attack breaks the integrity of file contents in a semi-controlled manner. Seafile uses unauthenticated CBC mode for encrypting file content, which implies that neither files nor file names are integrity-protected. As usual with CBC mode, the attacker can violate integrity by changing the plaintexts in a semi-controlled manner: the content of any block can be arbitrarily flipped, at the cost of sacrificing the content of the block before, which will be replaced by a block of garbage. Seafile uses a fixed IV for the encryption of all chunks, which prevents the attacker from changing the content of their first block, with the downside that the confidentiality of the file is greatly reduced. Unauthenticated Chunking This attack reorders chunks within a file arbitrarily. Seafile supports chunking of files. The encryption for each chunk is conducted separately, so the chunks are cryptographically independent. Thus, an authentication mechanism is required to ensure integrity of the file. In Seafile, no such mechanism is present, therefore a malicious server is able to reorder or remove chunks arbitrarily. Tampering with Files This attack moves files in the storage arbitrarily. Seafile relinquishes complete control of the directory structure to the server, once again enabling the server to move files within a repository. File names are not encrypted nor authenticated and can be changed at the server's discretion. Tampering with Metadata This attack breaks the integrity of all file metadata. In Seafile, metadata is unencrypted and unauthenticated and can be arbitrarily manipulated by the server. This includes the size of files, the ownership of files, and their type. Folder/File Injection This attack creates a new file by composing fragments of other files. Seafile uses unauthenticated chunking of files. These chunks may be reorganized by a malicious server to form new files with valid encryption. However, this attack only allows for the forgery of files from preexisting file fragments and is not targeted. Icedrive is a UK-based cloud storage provider founded in 2019 with an estimated 150k users worldwide. Our attacks allow a malicious server to break the integrity of uploaded files, as well as injecting files and tampering with their content. Cryptographic Primitives * Key Derivation + PBKDF2-SHA256 * Symmetric Encryption + TwoFish-CBC + TwoFish (in custom mode) Key Hierarchy [icedrive_k] Attacks Unauthenticated Encryption Unauthenticated Chunking Tampering with File Locations and Names Tampering with Metadata File Injection Unauthenticated Encryption This attack breaks the integrity of file contents in a semi-controlled manner. Icedrive uses unauthenticated CBC mode for encrypting file content, which implies that neither files nor file names are integrity-protected. As usual with CBC mode, the attacker can violate integrity by changing the plaintexts in a semi-controlled manner: the content of any block can be arbitrarily flipped, at the cost of sacrificing the content of the block before, which will be replaced by a block of garbage. Further, the lax padding checks allow for an adversary to truncate files by removing the trailing blocks of ciphertext. Unauthenticated Chunking This attack reorders chunks within a file arbitrarily. Icedrive supports chunking of files. The encryption for each chunk is conducted separately, so the chunks are cryptographically independent. Thus, an authentication mechanism is required to ensure integrity of the file. In Icedrive, no such mechanism is present, therefore a malicious server is able to reorder or remove chunks arbitrarily. Tampering with Files Locations and Names This attack tampers with the name and location of files. In Icedrive, all files and file names are encrypted using the same key, without any cryptographic mechanism to bind them together and to the file location. This allows the adversary to arbitrarily change location of files and swap file names. Furthermore, due to the usage of unauthenticated CBC mode, the adversary can truncate file names with the granularity of one block. Exploiting the malleability of CBC mode is possible, but is hard in practice due to the requirement that file names should consist of only UTF-8 characters. Still, this must be seen as a flawed choice of primitive by the protocol designers. Tampering with Metadata This attack breaks the integrity of all file metadata. In Seafile, metadata is unencrypted and unauthenticated and can be arbitrarily manipulated by the server. File Injection This attack creates a new file by composing fragments of other files. Icedrive uses unauthenticated chunking of files. These chunks may be reorganized by a malicious server to form new files with valid encryption. However, this attack only allows for the forgery of files from preexisting file fragments and is not targeted. Tresorit is a Swiss-based cloud storage provider founded in 2011 with an estimated 10 million users worldwide. Our attacks allow a malicious server to present non-authentic keys when sharing files and to tamper with some metadata in the storage. Cryptographic Primitives * Key Derivation + scrypt + PBKDF2 * Symmetric Encryption + AES-GCM (key material) + AES-CFB (data) * Asymmetric Encryption + RSA-OAEP Key Hierarchy [tresorit_k] Attacks Key Replacement Tampering with Metadata Key Replacement This attack can break confidentiality by presenting non-authentic public keys. Note: We could not run the end-to-end exploit as it would have required us to compromise Tresorit's infrastructure. Sharing files in Tresorit requires obtaining the public key of the recipient. In order to provide some authenticity, Tresorit deploys certificates to attest for public keys. All certificates are signed using Tresorit's own CA. In the threat model of a compromised server there is the possibility that the CA is also compromised. If the direct compromise of the CA is not feasible (due to usage, for example, of a hardware security module), there is still the possibility that a compromised server is authorized to send arbitrary certificate signing requests to the CA. If this is the case, the server could obtain valid signed certificates and use them to serve arbitrary keys to a user, breaking confidentiality of shared files. In Tresorit, the server may also try to substitute the public keys of admins, which would allow the adversary to gain complete control over a user account. Here, however, the fingerprint of the admin key is presented to the user, which allows for out-of-band verification. Tampering with Metadata This attack breaks integrity of file and folder metadata. In Tresorit, some metadata is unencrypted and unauthenticated and can be arbitrarily manipulated by the server. This metadata includes fields like file size, file type or time of origin. More importantly, for shared files in Tresorit, it contains information about who created the file or folder. This means that the server can make it appear as if a file has been created by a different user, which is particularly relevant for shared folders. Additionally, the server can make it appear as if the user had shared a folder with any arbitrary user. For example, a malicious server could frame an employee by adding a company competitor to the list of people who have access to a confidential folder and accuse the employee of industrial espionage. Discussion What is your threat model? All of our vulnerabilities are in the setting of a malicious server. This means that the server is controlled by an adversary, who can read, modify, and inject data at will. This may seem like a strong adversary model, but it is the most realistic for E2EE cloud storage. This model is also consistent with the security claims made by the providers we analyzed. Here are some examples: Sync's unique end-to-end encrypted storage platform ensures that only you have access to your files, which is the only way you can truly trust the cloud. Sync No one, even pCloud's administrators, will have access to your content. pCloud [...] you, and only you, are the only individual that can view and decrypt your data - Not even us - And that's just the way it should be. Icedrive We do not claim that the providers themselves would act maliciously, but rather that, by virtue of the data they store, they are an attractive target for nation-state adversaries and hackers, who would attempt to compromise the server and mount attacks against the users. What are the takeaways of your analysis? First, there is a gap between what is marketed by some providers and the reasonable expectations users have of their products. Confidentiality is a baseline requirement which we break for some providers. We violate integrity for files and metadata in many other providers, injecting (possibly incriminating) files in the storage of users. Metadata is leaked in many cases, which can be a privacy concern. Our findings allow users to make more informed decisions about the security of their data if they ever decide to use one of the providers we analyzed. Second, we show that various products fail in similar ways, indicating that the challenges in this setting are non-trivial. Compare this to more mature fields such as secure channels, where protocols like TLS, SSH, and the Noise framework have been developed and analyzed for decades, or to secure messaging, where the most of the main products are based on the Signal protocol. In contrast, in the field of E2EE cloud storage there are many products that fail at a trivial level, cryptographically speaking. This is a strong indication that more foundational work is required in order to provide more secure products. What must be done to improve this field? The effort should be two-fold. On the one hand, more analyses of E2EE cloud storage systems "in the wild" need to be conducted. This is crucial to understand the current state of deployed protocols and what the challenges are. On the other hand, more theoretical work is required to provide a solid foundation for the design of secure E2EE cloud storage systems. The final objective is to create a standard for E2EE cloud storage, similar to the Signal protocol for secure messaging. This is an active research field: other than the previously mentioned analyses of MEGA and Nextcloud, Backendal et al. have recently developed a formal model for E2EE cloud storage, starting the foundations for a more secure ecosystem. How did you choose which products to analyze? Why have you not analyzed X? We have chosen the products based on their popularity, especially when using queries such as "most secure end-to-end encrypted cloud storage" on search engines. While clearly there are many more providers, some of which might be secure, we have decided to leave those as future work. We did not omit any provider on purpose, and we are open to analyzing more providers in the future. Also, simply enough, there are only so many providers we could fit within a conference paper. We encourage researchers to analyze different providers and to publish their findings. Coordinated Disclosure We have notified Sync, pCloud, Seafile, and Icedrive of our findings on the 23th April 2024, proposing a coordinated disclosure of the vulnerabilities and suggesting the standard 90 day disclosure window. The Icedrive team acknowledged our email on the same day and, after a brief exchange, opted not to address the issues we raised. The Seafile team acknowledged the email on the 24th April 2024 and replied on the 29th of April, informing us that they will patch the protocol downgrade issue. As of 10th October 2024, Sync and pCloud have yet to respond to multiple attempts to contact them through different channels. We contacted Tresorit on 27.09.24 to discuss their cryptographic design. They acknowledged our email on 30.09.24. About Us This work was conducted by Jonas Hofmann and Kien Tuong Truong with the Applied Cryptography Group at ETH Zurich. We are not affiliated with any of the providers we analyzed in this work. The accompanying paper will be published at CCS 2024. Imprint | Privacy Policy