-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bypass Duplicati Login Authentication Using DB Server-Passphrase #5197
Comments
ContextIt is a problem if someone can access the MitigationsPermissions 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 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. BackgroundThe 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. ImprovementsGiven 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 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. |
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 |
This particular issue has been fixed by #5227 which makes the stored password PBKDF2 hashed. |
This issue has been mentioned on Duplicati. There might be relevant details there: https://forum.duplicati.com/t/release-2-0-9-103-canary-2024-08-15/18827/7 |
Environment info
Description
When Duplicati is configured with a login password , it is possible to bypass the login authentication using the Database server passphrase without actually knowing the correct password. The issue lies in the way the server passphrase is used to generate the authentication token.
https://github.com/duplicati/duplicati/blob/67c1213a98e9f98659f3d4b78ded82b80ddab8bb/Duplicati/Server/webroot/login/login.js
First saltedpwd is the SHA256 hash of the plaintext password entered by the user concatenated with the salt. Then noncedpwd is the SHA256 hash of the nonce concatenated with saltedpwd, which is then sent as the password parameter to login.cgi.
Steps to reproduce
Successfully logs into the Duplicati web interface without needing the login password, using the server passphrase.
The server passphrase should not bypass the login authentication. Only the correct login password should grant access to the web interface.
Screenshots
N/A
Debug log
N/A
The text was updated successfully, but these errors were encountered: