
BitTorrent Sync security and privacy analysis - nimbs
http://2014.hackitoergosum.org/bittorrentsync-security-privacy-analysis-hackito-session-results/
======
Joeri
So if I understand this right, there's probably a backdoor in it? Honestly
though, I doubt that you can keep the NSA and FBI out of your system. If they
want in, they'll get in, and there's nothing* you can do about it.

Having said that, we do need these kinds of solutions without the back doors.
Why aren't any software developers from countries where mandatory backdoors
aren't a thing building stuff like BTSync? And does anyone know which
countries those are? For example, i live in Belgium. Were I to build such a
thing, would someone show up on my doorstep and force me to backdoor it?

(*) nothing that is reasonable, only paranoia and extreme lengths will
suffice.

~~~
rsync
"Having said that, we do need these kinds of solutions without the back
doors."

You do have that. Further, you've had it since 2006.

Point duplicity[1] to rsync.net[2].

Cheers!

[1] [http://duplicity.nongnu.org/](http://duplicity.nongnu.org/)

[2]
[http://www.rsync.net/resources/notices/canary.txt](http://www.rsync.net/resources/notices/canary.txt)

~~~
IshKebab
Those are not the same as BTsync.

------
atmosx
From the "Conclusions" section:

> Change of sharing paradigm that introduced this vulnerability happened after
> the first releases. This may be the result of NSL (National Security
> Letters, from US Government to businesses to pressure them in giving out the
> keys or introducing vulnerabilities to compromise previously secure systems)
> that could have been received by BitTorrent Inc and/or developers.

IF that's true, then it's extremely alarming. I wouldn't use their software to
share sensitive files.

~~~
higherpurpose
I'm no security expert, but when I saw they did that whole "easier sharing"
thing over e-mail that raised a _major_ red flag for me. It seemed quite
obvious that many of the previously secure systems would now be broken by that
insecure e-mail sharing system.

~~~
benguild
I disagree... My guess is that if you choose to enable features like that
you're most likely opening a door, but if you don't it won't compromise
anything.

At least, that's how any competent developer would code it.

------
Fastidious
Also, not open sourced.

Bottom line: do not use for sensitive data.

------
baldfat
I don't use it for sensitive information BUT for my needs this is a great
solution that is MUCH better then a cloud based file system. I have my media
files for my Phone just BTSync them when I need them and it works like a
charm. Also works great for syncing my photos between my computers like
photos.

~~~
joelthelion
It would be perfect if only they open-sourced it.

~~~
higherpurpose
There's Syncthing, but I'm not a big fan of the whole "server"-like interface.
They've improved it recently, but it still seems quite non-consumer-friendly.

[http://syncthing.net/](http://syncthing.net/)

~~~
nodata
Why don't you suggest some good changes? The issues page on github seems quite
active and quick to fix stuff.

------
rnhmjoj
Has Pulse/Synching protocol been reviewed?

~~~
ultramancool
They do recommend it as an alternative here and it certainly avoids many of
the mentioned issues (relying on other people's architecture, leaking hashes
of your data and probably much of the exploitability due to the use of a
memory-safe language), though I do not believe there has been a formal review.

------
huhtenberg
Something to keep BT on its edge, but this is hardly a "security analysis" in
an established conventional sense. It's a semi-random collection of surface
observations from half-a-day of poking around. Sure, some of these may be
indicative of serious underlying issues, but they may also be not. E.g. -

> [MEDIUM] Attack vector potentiel : mise à jour automatique (silent update)
> du client en HTTP sur
> [http://update.utorrent.com](http://update.utorrent.com)

If they check the digital signature on an update package, this is not an
issue. If they don't, it is.

~~~
geofft
Even signed automatic security updates, where the vendor runs the update
server, still allow the vendor to inject targeted attacks in your binary.

There are ways to mitigate this, but not well given the design constraints of
closed-source software.

~~~
huhtenberg
Well, if you are pulling down a vendor's binary, they can "inject" whatever
they want in it :)

If you meant that a _man in the middle_ can do that, then if things are
implemented correctly on the app's end and if an attacker doesn't have
vendor's private key, then - no, of course, they cannot inject anything that
way.

~~~
geofft
> Well, if you are pulling down a vendor's binary, they can "inject" whatever
> they want in it :)

Why does this have to be the case? Here are two specific alternative
deployment models that protect you from this attack:

1\. The update is signed at rest (e.g., PGP), instead of the update traffic
being signed in motion (e.g., SSL), and the update and signature are widely
mirrored or distributed through a third party. The vendor can still inject
malicious code, but everyone has the same code: they can't easily introduce
targeted attacks against a specific person.

This is the security model of Chrome or Firefox extensions, and it's one of
the reasons there are vague security advantages in distributing an app that
way instead of directly via a website. It's also the security model of the
Apple App Store, the Play Store, almost all Linux distros (kinda), etc.,
sometimes with the addition that there's a human reviewer at the third party.

2\. Same as 1, but the code is open source and reproducibly built, such that
anyone can audit (possibly even automatically!) that the sources match the
binaries. Or the code is open source and not in a compiled language. At that
point, any injected crap is visible to the world.

(This design has the secondary advantage that it disincentivizes the
government from compelling the software author to add a hidden backdoor, but
that's for the same reasons it makes it hard for the software author to add a
hidden backdoor of their own volition.)

My point is that we shouldn't settle for a bad threat model just because a
for-profit vendor tells us it's the threat model.

------
dmachop
If I am correct, the article suggests a deliberate bug that I s attackers view
information that can be used as a backdoor. Does this mean to abandon BTSync
completely?

------
cryptonerd
I've been waiting for a LONG time for an analysis of BTSync. While reading the
analysis, I can only imagine what this spells for similar closed-source (yet
purportedly "secure") file storage sites such as SpiderOak and MEGA. Thoughts?

------
WTH
[http://forum.bittorrent.com/topic/32575-multiple-massive-
sec...](http://forum.bittorrent.com/topic/32575-multiple-massive-security-
flaws-discovered-bittorrent-sync-is-totally-insecured/)

------
benguild
What else is there? I personally don't like the idea of not having a two-
factor authentication given that someone could theoretically "brute force" the
keys... although extremely unlikely in a non-LAN context.

~~~
wlesieutre
Syncthing is the other option I've used. Setup isn't as easy as Bittorrent
Sync though (each computer has to have the node IDs for other computers added
manually). And last I checked, there's not a convenient "run in the
background" checkbox, so it's not well suited to non-techies yet. But it's got
open source going for it. Don't know if it's been subjected to any security
audits, but the fact that it eventually _could_ be puts it ahead of
Bittorrent.

[http://syncthing.net/](http://syncthing.net/)

------
0x0
What's wrong with using http instead of https on the localhost web server?

~~~
lucb1e
I assume you refer to this:

> [LOW] confirmed: When registering, http traffic for creating new user on
> loopback [http://127.0.0.1:8888](http://127.0.0.1:8888)

And I wonder the same. Didn't really get that one, but yeah you may be right
that they mean it should be https. I guess the risk is when an application can
monitor loopback traffic, but you can only do that with special permissions or
if you're root. The former case is exceptional, in the latter case you're
pwned anyway and your keystrokes aren't safe either. So yeah, I don't know.
Https might do a _little_ bit extra... but I don't know.

~~~
kalops
keep on reading...

------
mellamoyo
There's a lot of people saying "don't use btsync for sensitive data" and
rightfully so. What are some alternatives that are considered more secure?

~~~
Veratyr
Pulse ([https://ind.ie/pulse/](https://ind.ie/pulse/)) is the main one I'm
aware of.

------
rlvesco7
How would this compare to DropBox and other alternatives?

~~~
nostromo
Well, you're setting a low bar. DropBox is not secure from the government in
any way. BTSync is better.

If I understood the article correctly, an MITM attacker (or federal agency)
could in theory know that you have a copy of a file only after they have a
copy of the same file themselves, by comparing hashes.

------
jmrlt
[https://github.com/syncthing/syncthing](https://github.com/syncthing/syncthing)

------
defiance360
Say I encrypt a folder with my own encryption then BitTorrent Sync it, would
it then be safe?

------
WTH
They are working on a detailed answer...

------
jokoon
with the new UI version, some "enable tracker" option appeared.

I thought everything happened with a DHT ?

