I have ST running on my home. Only devices in my trusted VLAN have it installed. My FW rules do not allow ST to access anything outside this VLAN nor can anything in any other VLAN, or the internet (WAN) access the computers running ST. And I have all relay/discovery/etc. disabled in ST.
So I am inclined to not PW protect ST. I’d only access it from devices in the same trusted VLAN.
Wanted to check with folks here if there are any risks/issues I may be missing.
I password-protect all instances of Syncthing I install. Most of them use wrappers, so I don’t need to use the GUI anyway. I just set a randomly-generated password and forget about it - if I ever need the GUI I can reset the password.
This blanket approach means I don’t have to wonder what attack surface I might be opening, leaving the GUI without a password 
I also password protect all my instances (and save the passwords in a password manager), but if you do not, then obviously your protection will be dependent on how secure your VLAN is.
Also, just a side note, but you cannot not password protect the Web UI in the Android application. The password is set to the API key and you cannot change it (and if you do, it will reset on the application restart).
@tomasz86 Regarding Android
… If the API key is used as the password, the key can be renewed from the web ui and I expect it to get the new password on Syncthing restart.
Imagine you got malware as some non-priviledged user, and syncthing runs as a privileged user or other user. You’d be able to effectively switch users on local machine without needing passwords.
Understood but I am trying to do a threat model/analysis to figure out exactly what attack surfaces there are – if any. I fully get it is better to be safe than sorry but I’m wondering what the sorry viability is.
I am not running it on any mobile clients. But that is good to know. Thanks!
I mean, all the infected non-privileged user would be able to do is interact with ST, right? In order to switch to the privileged user that ST is running as, the infected non-privileged user would need to compromise ST to run arbitrary commands as the privileged user that ST is running as.
So that begs the question, how secure is ST. Based on what I saw, I’d say pretty secure. So the chance are pretty slim that anyone could get into ST to leverage anything. No? But I do like where your heads at.
I only have ST running on a server and two computers, all three on the same trusted VLAN. Sure one of the computers could be infected with ransomware/malware but in order for the ransomware/malware to do any ST damage it would have to be ST aware – malware written specifically with an understanding of ST’s architecture to be able to leverage the privileges ST has. So the possibility/risk is there but I think its pretty low risk – at least for me.
It would be enough for the malicious actor to add a new malicious device, add new folder with path set to /etc/ and bulldoze /etc/gpasswd (or whatever it’s called) to change root’s password.
If this was not root, you could still potentially place some malicious binary in ~/bin/, add startup of it in to ~/.profile and get a reverse shell.
Or to be honest, even setup external versioning to launch whatever binary you want.
These are great!
Can’t add a new device since all WAN traffic is blocked. On my Linux server I’m running ST in a container so minimal attack surface there. But you’re right, they could muck with existing shares.
Brilliant! I had not considered that. Thank you. This is great.
They can run a new Syncthing instance on that same machine. Or just talk BEP (Syncthing’s data exchange protocol) directly to Syncthing, since all they need to do is instruct it to overwrite a specific file or two.
The more general point is that if someone can configure Syncthing, they can instruct it to overwrite any file or run any executable on that system which it has permission to.
Where did privileges/root come into this? I think it’s far more important to not run Syncthing privileged than setting a password. My syncthing instances listen on localhost only and any user on localhost anyway does have access to all the data Syncthing has access to. So I don’t see any potential for access/privilege escalation by not having a password in this scenario. Where’s the flaw in my reasoning (if any - one might foolishly hope )?
I mean its all contextual right?
If its a single user system running as that user, the yeah it’s probably safe.
But even then, you run some dodgy expliotable mongodb as nobody, it gets hacked and you escalate yourself from mongodb to a shell as the user running syncthing.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.