security hole in Linux WebUI makes all your files publicly accessible


aaronmk

Recommended Posts

Running btsync on Linux will by default create a *publicly-accessible, unprotected* WebUI, allowing anyone on the web to create a sync folder to view and edit files your files (i.e. files in directories writable by you). Could the defaults (used when running btsync without a config file) be changed to prevent this unintended data leak?

A temporary workaround is to run `killall btsync` to turn off the WebUI, and then use --config with a config file that sets webui > password to a secure password. You can use `lsof -i` to verify that the WebUI is not running.

Link to comment
Share on other sites

But without the --config option, I don't believe it saves any data*.

It will actually show previously-added shared folders when you restart btsync. The /tmp/SyncApp_dumps/ directory is empty, though, so I'm not sure where it stores the configuration. Maybe in the BitTorrent Sync tracker itself?

Link to comment
Share on other sites

The best fix would be for btsync web daemon to default binding to 127.0.0.1 instead of 0.0.0.0.

That works as long as you are the only one with access to your computer. If btsync is running on a shared computer, any other user on the computer would also be able to access it. (Other users would also notice that someone else was already running the WebUI on port 8888.)

I think ideally, the default mode for btsync would just prompt for a password to use with the WebUI, and generate (and reuse) a default config file stored in user's home directory.

Link to comment
Share on other sites

Even better :) Man I wish I knew enough Javascript to chroot the users "Add folder" option :\

Javascript doesn't support filesystem-level security because it's browser-based. You would instead have to modify the btsync program itself (i.e. the server-side code) to support things like chroot. Modifying btsync to fix security problems would of course require the source code, which BitTorrent hasn't made public (yet?).

Link to comment
Share on other sites

The best fix would be for btsync web daemon to default binding to 127.0.0.1 instead of 0.0.0.0. In the meantime you can manually set that in the json config file:



{
"webui": {
"listen": "127.0.0.1:8888"
}
}

I would hate that the default was in this way, using btsync on NAS devices - I would not be able to gain access to it.

And if you are already working with the config file - why not just set a user and password ?

As mentioned, btsync works fine without having the --config option used, remembering the shares set up from start to start.

So, for me when doing a first time run, prompting for user and password to be set, would be a great...no wait, awesome start.

Link to comment
Share on other sites

I think ideally, the default mode for btsync would just prompt for a password to use with the WebUI, and generate (and reuse) a default config file stored in user's home directory.

Yes, I think a conf file should always be used, automatically, with one being generated the first time if it doesn't already exist. Then when you start btsync without specifying a config file, it will use the default one, but keep the option to use an alternate conf file.

Link to comment
Share on other sites

  • 1 year later...

Heya everyone

 

Just wanted to say that I tried btsync and find it to be quite awesome in terms of usability. But I'm pretty horrified by the fact that btsync listens on 0.0.0.0 per default.

 

As suggested before I can only recommend setting it to 127.0.0.1. If you've got a NAS with SSH/CLI, you probably have the skills to change the listen address in a config or use the -L flag in SSH. This would be security/privacy first, which is, as I understand it, a main point of what btsync is about.

 

Using a mandatory password would be kind of ok as well I guess. Although I think a lot of people will just enter the "I'll change that later for sure"-value and forget about it.

Link to comment
Share on other sites

Proposed change is going to kill the usability for people who use btsync for NASes

 

But wouldn't NAS users want their data protected, too? This would suggest that requiring the user to set a password (and warning them that their data will be wide open otherwise) is the best solution.

Link to comment
Share on other sites

  • 8 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.