Duplicati environment variable security

[rkobriger]

Hi,
I’m new to Duplicati, and this forum, so pardon me if there’s a better way to post this, but…
I am evaluating Duplicati as my backup solution after losing CrashPlan, and I like the backup functionality, but I am looking to try to improve the reporting (email) capability, so I started experimenting with a post-run script, and in that script I dumped the contents of the DUPLICATI environment variables to a text file. I was shocked to find, not only the backup Passphrase in plain text, but also the password to my email account, via the send-mail-password variable! Worse, these settings are (momentarily) stored in a file, in plain text, in the temp folder. This seems to be a very significant security risk. If I were rogue, it seems that it would not take much to develop an app to monitor the temp folder and grab the contents of the file when it appears. Am I missing something here, or is this a legitimate concern?

Thanks.

[EDIT] - My apologies, the file in the temp folder does not contain the passwords - only the environment variables. Even so, a rogue process could do a memory dump and discover these plain text passwords!

[hydrian]

@rkobriger,
While I think you’re bringing up an important topic, it really needs its own topic. Put it here is a bit of thread highjacking.

[JonMikelV]

Hello @rkobriger, welcome to the forum!

I agree with hydrian that your ideas deserve their own topic so I have moved them over here, happy discussing!

[kenkendk]

If you have some infection that has full system access (able to read files, and dump memory) it is generally game over.

I wrote a bit about the problem here:

Defense against trojans

I agree, but this is actually not possible. Duplicati needs access to the destination, so the process that runs Duplicati needs the credentials in clear. On a compromised machine, ransomware can read such credentials, and do whatever Duplicati can. Storing the data in an OS keychain only guards against cold attacks, not when Duplicati is running. The only true way to guard against ransomware is to guard the server, and have a “no updates, no deletes” user. This means that backups grow foreve…

[hydrian]

It sounds like Duplicati isn’t doing proper sensitive data protection. Client passwords are a big one since Duplicati talks to many 3rd party services. Good memory storage practices for credential data:

Client Credentials

1. At process start, code generates key for symmetric encryption
2. Wait till the last moment to read credential data from persistence storage. Encrypt sensitive credentials with process random symmetric encryption. The sensitive credentials could be in memory for a while if the task is a long running.
3. Decrypt symmetrically encrypted credential as privileged task is executed.
4. Securely delete unencrypted sensitive reference: Overwrite length of variable content with 0/NULL. Then unset. I know .Net has functions for this. I know keepass2 uses them.
5. Make sure process encryption key is securely removed at process exit.

Does it protect from everything, no. There is no way to completely solve this. Does this protect against casual memory snooping, yes.

Server passwords

1. All password should be stored as cryptographically secure seeded hashes. SHA2 class hashes

[kenkendk]

@hydrian

1. All password should be stored as cryptographically secure seeded hashes. SHA2 class hashes

That is handled. All passwords that are stored/validated by the server are hashed and salted.

@hydrian

Securely delete unencrypted sensitive reference: Overwrite length of variable content with 0/NULL. Then unset. I know .Net has functions for this. I know keepass2 uses them.

That is possible with SecureString. It is not currently used anywhere in Duplicati.

@hydrian

Wait till the last moment to read credential data from persistence storage.

The setup you describe, increases resistance agains memory attacks, but adds no real protection as long as the stored credentials are not properly encrypted. If an attacker can simply read them from the database, there is no need for them to waste time on memory dump/snooping.

Until we implement proper credential storage with a protected key, guarding in-memory passwords is a low-priority task for me. So far the most promising solution seems to be using the OS KeyChain features, and then rely on the OS being able to guard that secret.

Once that is accomplished, we can rewrite all handling of passing credentials.

[hydrian]

Isn’t the configuration database protected by the --server-encryption-key parameter ? I know right now that defaults to RC4 which has slew of issues. One being that RC4 is a broken cipher. The other is that the RC4 support is not really cross-platform friendly with SQLite. I would recommend we switch of to AES. AES is well trusted and and well supported. On top of that, most platforms have hardware acceleration for it so it usually well performing cipher if performance is a concern.