Context

It is a problem if someone can access the Duplicati-server.sqlite in some way, as they can extract the password for the UI.
Using the password, it is possible to perform all operations a valid user would do (delete, create new, change, etc), and this can be used to escalate access.

Mitigations

Permissions are set on Windows and Linux/MacOS to prevent unathorized access to the database, meaning that an attacker needs access to the system and the folder where the Duplicati-server.sqlite is stored.

In case the file is, for some reason, part of a backup, it can be obtained through the backup. Encryption on the backup will prevent access, granted that the passphrase is kept secret.

Background

The password mechanism used in Duplicati is designed to never send a token/password that can be used to grant access or reveal the password. In other words, the security is designed to prevent passive & active monitoring over the http-connection between the server (or tray-icon) and the browser.

The scheme works by accepting a nonce/salt (can be attacker chosen) and then hashing the password with this and returning the result. Even if the attacker chooses the salt, they can only obtain the hashed value and not perform MITM because the server will send a new nonce at later connection attempts.

For this scheme to work, the server needs to know the "password" that is used to access it. To avoid storing the actual password in the database, a hash of the password is stored. This is only done to hide a weak password and means that the hash is now the password. It is, however, only slightly better than storing the password clear-text.

Improvements

Given that the password is exchanged for an access token, any attacker listening could simply intercept the access token instead.

Ideally, it would be great if we could get TLS in, but this is hard to do securely for localhost, without exposing the user to a greater risk with an approved self-signed certificate.

An alternative to this is to encrypt values that are sensitive, such as the UI password, and store only the encrypted versions in the database. This requires a good mechanism for storing the database password, which should ideally be using the operating system keychain for this.

Encrypting the entire database is currently not an option for SQLite database, but another database could be used, as performance is non-essential for the settings.

from duplicati.

This issue has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/battle-plan-for-dropping-httpserver/18002/7

from duplicati.