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.

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).

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.

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.

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.

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.