BitTorrent Sync security and privacy analysis(2014.hackitoergosum.org)
2014.hackitoergosum.org
BitTorrent Sync security and privacy analysis
http://2014.hackitoergosum.org/bittorrentsync-security-privacy-analysis-hackito-session-results/
18 comments
> If they want in, they'll get in, and there's nothing* you can do about it.
Yeah, but you don't have to make it _easy_ for them, like using closed-source software that's capitalizing on the name recognition of "BitTorrent" to pretend to be open.
(I expect that even if you lived in McLean, Virginia and never locked your doors, if you were writing open-source software, nobody would make you put a backdoor in. The intelligence agencies have shown a great bias towards doing things that people won't notice.)
Also, even assuming you can't keep the NSA and FBI out if they really care (which I somewhat agree with), it's definitely worth it to keep everyone else out. Like BitTorrent the company, or anyone MITMing any of those HTTP URLs.
Yeah, but you don't have to make it _easy_ for them, like using closed-source software that's capitalizing on the name recognition of "BitTorrent" to pretend to be open.
(I expect that even if you lived in McLean, Virginia and never locked your doors, if you were writing open-source software, nobody would make you put a backdoor in. The intelligence agencies have shown a great bias towards doing things that people won't notice.)
Also, even assuming you can't keep the NSA and FBI out if they really care (which I somewhat agree with), it's definitely worth it to keep everyone else out. Like BitTorrent the company, or anyone MITMing any of those HTTP URLs.
They've made a preliminary response here: http://forum.bittorrent.com/topic/32575-multiple-massive-sec...
"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/
[2] http://www.rsync.net/resources/notices/canary.txt
You do have that. Further, you've had it since 2006.
Point duplicity[1] to rsync.net[2].
Cheers!
[1] http://duplicity.nongnu.org/
[2] http://www.rsync.net/resources/notices/canary.txt
Those are not the same as BTsync.
but duplicity is a backup program. btsync isn't.
setting this up when I get back home. thanks.
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
If they check the digital signature on an update package, this is not an issue. If they don't, it is.
> [MEDIUM] Attack vector potentiel : mise à jour automatique (silent update) du client en HTTP sur 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.
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.
There are ways to mitigate this, but not well given the design constraints of closed-source software.
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.
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.
> 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.
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.
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?
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?
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.
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/
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?
Pulse (https://ind.ie/pulse/) is the main one I'm aware of.
rsync, and I'm not delighted at this answer either.
[deleted]
Say I encrypt a folder with my own encryption then BitTorrent Sync it, would it then be safe?
They are working on a detailed answer...
with the new UI version, some "enable tracker" option appeared.
I thought everything happened with a DHT ?
I thought everything happened with a DHT ?
Also, not open sourced.
Bottom line: do not use for sensitive data.
Bottom line: do not use for sensitive data.
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.
> 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.
I think there's a bit of FUD and jumping to conclusions; the hashes shared are not permanent keys but one-time secrets (i.e. invite codes) according to this link (although we probably will want some confirmation): http://forum.bittorrent.com/topic/31588-wont-use-getsynccom-...
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.
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.
At least, that's how any competent developer would code it.
The government has a window into basically all the file sharing services.
How would this compare to DropBox and other alternatives?
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.
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.
Well with Dropbox you know that the government can request any data presently or previously in your folders. With btsync it doesn't seem to be so easy because data isn't stored centralized, but there are some potential leaks. Still better than Dropbox.
Has Pulse/Synching protocol been reviewed?
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.
What's wrong with using http instead of https on the localhost web server?
I assume you refer to this:
> [LOW] confirmed: When registering, http traffic for creating new user on loopback 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.
> [LOW] confirmed: When registering, http traffic for creating new user on loopback 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.
keep on reading...
[deleted]
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.
It would be perfect if only they open-sourced it.
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/
Why don't you suggest some good changes? The issues page on github seems quite active and quick to fix stuff.
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.