Nextcloud: Improper integrity protection of server-side encryption keys

The public keys used for the server-side encryption are not integrity-protected. These can easily replaced by anyone who has access to the data-at-rest data (even when the per-user-keys are enabled, as described in https://nextcloud.com/security/threat-model/). This holds true for all key types - from the master key, the per-user-keys as well as for the (optional) recovery key.

Attack scenarios may look like this:

• A recovery key is set by the admin and users enabled the recovery feature (or it was mandatorily set by adding the corresponding configuration to the oc_preferences table for all users). As it is unlikely that the recovery key is used very often, a person that has access to the data directory (even if at rest) is able to replace the public recovery key with a newly generated one. Each newly added file and each modified file will also be encrypted for the newly generated recovery key.
• A per-user-key encryption scheme is introduced and organizational shared folders are set up. To better handle access management all organizational shared folders are owned by the admin that also handles access management requests. As it is unlikely that the admin account will be used to access the individual files, a person that has access to the data directory (even if at rest) is able to replace the public key of the admin account with a newly generated one. Each newly added file and each modified file that is put into any of the organizational shared folders will also be encrypted for the newly generated admin account key.

The mentioned attack scenarios may also be executed by an external storage provider if the folder that is used as the data directory is stored at this external storage provider. Administrative access to the actual Nextcloud server is not necessary to mount this attack.

Impact

After mounting the attack the person would be able to read and modify all newly created files as well as files that have been modified since the attack was launched.

Preventing this attack could look as follows:

• The fingerprints of public and private key files that have been generated by the application could be stored in the database.
• Whenever public or private key files are read from disk the fingerprint of that file is checked against the value stored in the database.

An alternative approach for preventing this attack could look as follows:

• For each public and private key file that has been generated by the application a MAC could be calculated.
• The key for the MAC could be derived from the instance id, the instance secret and the relative file name of the corresponding key file.
• The MAC could be stored directly in the corresponding key file.
• Whenever a public or private key file is read from disk the MAC of that file could be calculated and compared with the MAC stored in the file.