On my system (openSUSE Leap 15.0) running the current Beta version, clicking “run” on the tray icon beings be into the user interface even though I had logged off the last time I used duplicati.
Is this by design or is it a bug? If by design, is there a way to suppress this behavior at the server level? Not only is is a security issue, but it seems that whatever mechanism allows this to happen could be exploited.
Thanks!
This isn’t by design - I assume everything is running on the same port? (In other words, you didn’t do something like set up a password on the service at port 8200 then connect to the tray icon on port 8200?)
I’m running on openSUSE Linux (Leap 15.0).
So far, I’m the only user running duplicati on this system. In ~/.config/autostart I have a file named duplicati.desktop with the following contents:
[Desktop Entry]
Categories=System;Archiving;FileTools;Filesystem;
Comment[en_US]=Create and maintain local and remote backup copies of your data
Comment=Create and maintain local and remote backup copies of your data
Comment[es]=Cree y mantenga copias de seguridad locales y remotas
Exec=duplicati
GenericName[en_US]=Backup tool
GenericName=Backup tool
GenericName[es]=Copias de respaldo
Icon=duplicati
MimeType=
Name[en_US]=Duplicati
Name=Duplicati
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-Desktop-File-Install-Version=0.23
X-KDE-SubstituteUID=false
X-KDE-Username=
This causes /usr/bin/duplicati to run when I log in (I’m using the KDE desktop).
Clicking on the tray icon opens up a browser window at url http://localhost:8200/ngax/index.html - regardless of whether I have logged out of my last session or not. Attempting to enter the same url manually after having logged out correctly gives me a “Not logged in” error which then takes me to a login screen. Even after being denied manual access to duplicati, clicking on the tray icon and open brings up a new window already logged in.
So there are a few issues here:
Help will definitely be appreciated.
I’m a bit ashamed to say my Linux test VMs all died a while ago and I haven’t had time to rebuild them yet. Perhaps @Pectojin might be able to see if he can create the same issue?
I don’t run the tray icon on my server, but maybe I can give it a shot if it survives my 16.04 → 18.04 Ubuntu upgrade.
I’m not sure… I would expect it to not log you in, but I didn’t design it.
The tray icon will read the credentials from either input variables on start or from the database, so it’s just logging in. This is required since it needs to ask the server API about notifications to display the error tray icon.
I suppose - if it’s logging in on your behalf - then anyone with access to your graphical session could log in to Duplicati. So VNC/RDP or physical access while not locked, but I doubt you could over CLI/SSH unless you do some x-forwarding trickery - while having sudo rights.
Well, it isn’t strictly bypassing it since it knows the password and authenticates, but yeah any process that has access to the Duplicati database can get the password. So if you’re running it as your user then anyone with access to ~/.config/Duplicati can login.
All in all, I would have expected the tray icon to not log you in, but I can’t confirm or deny if it does or if it’s designed to do so 
Well… My idea was something like:
If you have access to the desktop where the tray-icon is running, clearly you have access to the data it processes as well.
Since the tray-icon needs the server password in order to display the status, it knows the password. When you click “Open” from the tray-icon, it creates a new session for you and opens the browser in this session, allowing you to use it without entering a password.
I was convinced that this was the user-friendly way, but I can see that many people are surprised by this, so maybe we should change the logic for it?
I think the people most worried are those who are security conscious, as they worry that it is not really password protected. Casual people probably never notice because “it just works”.
Seems fair. Good to know it’s not by accident 
I don’t have an opinion on whether it’s a problem or not, to be honest. But in my mind it doesn’t worsen the security.
I slightly disagree - if you’re worried about the data on the machine, then yes, it’s not any worse.
But if you’re worried about previous version of things that are in the backups or even passwords & such (say email logins) that might be in your Duplicati settings then I would think it is worse.
Of course some people will like it one way and others the other way, so maybe there should be a “Tray-icon requires password” checkbox (defaulted to false) that is enabled when a password is entered into settings.
And going down that rabbit hole brings up the question of should there be a timeout on the password login (e.g. Logout X mins after last interaction)…
There already is. IIRC it is one hour after the last request.
But “interaction” is special, because of the way Duplicati works, it keeps making background requests as long as the page is open. There is currently no “has user clicked on the page” timer.
I just had a horrible thought.
When I log out of duplicati, others trying to access my duplicati server/page/port are prompted to log in, as long as they don’t use my tray icon.
However, what happens while I’m logged in? Are other users (e.g., remote X session via VLC or other similar tools) on the system able to then access my duplicati server/page/port from a different login? If so, and if they start an action, will it show up in the status area of my view (assuming I’m on the home page to even see the status area)? Mind you, even if I have the potential of seeing their activity, I might not be at my screen, so this isn’t a security solution, just a point of curiosity.
If they have access, it’s a very big problem. They don’t have any access to my current files because of Linux access rights. But they can restore any of my backups to a directory of their choosing.
If this is indeed an actual security vulnerability, in addition to the issues related to the tray icon, some thought also be should be given this. (Break this out into a separate thread?)
I appreciate the time and thought that you all are putting into this. I don’t consider myself a security paranoid, but security based on trusting others to behave themselves doesn’t meet my minimum threshold of security comfort.
No one has access unless they have your password or your active browser session data.
Your “login state” consists of 2 pieces of information. A nonce and a token. The nonce is a 44 character string generated specifically for you when you try to log in and changes every time you try to log in. The nonce is used to hash your password[1] into an unrecognisable string which is your token.
Your browser stores these while your session is active. Without the token and nonce anyone visiting the GUI are still prompted to log in.
Any request you make to the server, after you logged in, will include the nonce and the token to authenticate. Since the nonce changes with every log in attempt the token will change every login and the server can validate your session.
This method means you never send your password to the server, so no one can see it in transit and use it to log in later… But it does mean that if you communicate over unencrypted HTTP someone can copy your nonce and token and “be logged in” with the server while your session is active.
[1] Technically both nonce and salt strings are used for hashing, but for this explanation that just introduces confusion.
You should be able to verify @Pectojin’s scenario by running two different browsers to log in to your Duplicati. It might also work to run a standard and Incognito / Private window of the same browser, just make sure the windows are opened BEFORE logging into Duplicati from either of them.
Works as expected - logging in does not allow others to access my duplicati access.
Still concerned over tray icon bypassing the need to log in, but I guess that’s the way it works for now.
How does the tray icon get access to the password to log into duplicati?
Given Linux’s default of allowing everyone read access - can others extract my password the same way?
Thanks!
Good question!
The password is only stored in a hashed version, so it cannot be read by lifting the database. If the tray-icon is not hosting the server (uncommon, need to set --serverurl= when starting the tray-icon), you need to supply `–webservice-password.
If the tray-icon is hosting the webservice as well, they communicate in-process to generate a random session-only password that allows the tray-icon to authenticate with the webserver (out-of-process, via http(s)).
So the tray icon does not use my password - hashed or otherwise - to connect to the server, but instead generates a random one?
How does the icon/server know what user to connect for, and what prevents someone else from fooling a tray icon to start up an instance for another user while connecting them to it?
(Sorry to keep dragging this on, but given the that I have a proprietary project underway, I need to be certain that backups for one user can not be accessed by anyone else by exploiting current mechanisms.)
Thanks for the explanations!
Kenneth , is possible that Tray Icon not bypasses UI password in Windows ??
The restriction must be, because in Windows usually all users are administrators and if the tray icon allows to enter the UI without a password, it allows users to modify the Duplicati configuration. ( it should not be allowed to modify the duplicate configuration for a Windows administrator user, it should only be allowed for the duplicate administrator with UI password )
It works such that the tray-icon runs in a user context (the desktop session), and when you choose the “open” action on the tray-icon, it will use the same user context (the desktop session) to open the browser window.
To circumvent this, you would need to send a request to the tray-icon in the other users session/desktop/context, and intercept the open call to extract the pre-authenticated url. Once you have this url, you can open it in your own session and be authenticated as the other user.
If these two injection points are possible, it makes for a really insecure multi-user environment.
I have added an option to the source that allows disabling this:
That is really bad security practice and invites a myriad of more serious problems.
That is not really possible. The Administrator account has full machine access, so they can just open the database and change the data there. Even with a fully encrypted database, the administrator account can dump kernel and application memory and extract all passwords.
Hi, Kenneth. Thank you very much for your help.
I do not understand a lot of programming, but hopefully useful for everyone.
Maybe this function is implemented in a new version.
Thank you again.
Yes, it is possible. But only administrator users with advanced knowledge. No regular users with administrator privileges on home personal computers. 