Security analysis of BTsync
During last Hackito Session, a group of passionate tech gathered and during one evening dug whatever they could on BTsync. The goal of this Hackito Session was to analyze the security of BTsync.
Why? Because BitTorrent Sync growing popularity means more and more private data gets exposed, and as it is a closed source program, there’s a need for some verified and neutral information about its intrinsic security and also about the degree of privacy it provides.
Comment: This is not a professional assessment but a community effort to analyze a solution used by the public. This is a quick response to some critics on this Hackito Session results, this is not a commercial report 🙂
1. Doc URLs
2. BTsync components
3. Attack surface
4. Security Analysis
5. TL;DR & Conclusions
6. Updates post publication
1. Doc URLs
Introduction to BTsync
- https://en.wikipedia.org/wiki/BitTorrent_Sync
- http://www.bittorrent.com/sync/tech-specs
- http://sync-help.bittorrent.com/customer/portal/articles/1632902-introducing-sync-1-4
- https://stackoverflow.com/questions/20594302/how-does-the-bittorrent-sync-secret-work
- http://www.mcld.co.uk/blog/blog.php?406
- http://www.agentofkaos.net/2013/02/a-closer-look-at-bittorrents-syncapp.html
- http://httpshaming.tumblr.com/post/95206154681/bittorrent-sync-requests-its-tracker-relay-and
BTsync Protocol:
- http://forum.bittorrent.com/topic/21338-inofficial-protocol-specification/
- https://github.com/picosync/workingDraft/wiki/Protocol
- https://github.com/picosync/workingDraft/
Some alternatives for BTsync:
- https://gowalker.org/github.com/takuan-osho/syncthing
- Now also called Pulse
- SyncThing sharing model is unnatural even though its opensource nature make it preferrable to BTsync.
2. BTsync components
* BTsync client Mac/Linux/Win
Closed source client, uses multiple hashes for sharing Read or Read/Write access to a shared directory
* BTsync mobile client (Android)
Download Android APK from here:
https://mega.co.nz/#!LA51GRoY!Al3XQZw8FVQyn2Yoa4aTed6M6PV7GeZQrUHJIfJeRjs
* BTsync “getsync” sharing server
https://link.getsync.com/
This is used to share the hashes to another person.
3. Attack surface & Potential attack vectors
Attack surface:
- Client ports
- Client passive egress traffic sniffing
- Peer invite must be approved on this device
- Link expire
- getsync.com server logs
Potential Attack vectors?
- CSRF / local change password without old password?
- A lot of JS libs in 127.0.0.1:8888/gui/ –> audit libs
- DoS on getsync.com == 98.143.146.7 ?
4. Security Analysis
[LOW] confirmed: When registering, http traffic for creating new user on loopback http://127.0.0.1:8888
[HIGH?] Tracker server gets hashes of new folder?
[MEDIUM?] Leak of IPs to relay/tracker during initial JSON pull (Renaud: Not CNIL compliant)
[LOW] confirmed:: t.usyncapp.com server logs — gets all IPs that create shared folders, even before they are used
[LOW but fun / anecdote] no filter of RFC1918 peer addresses means you can make anyone connect to IPs inside his network; if the guy is on a IPS-protected LAN, make him connect to 2000 IPs and port and he’ll get parked to a “DECONTAMINATE” VLAN.
[LOW] Once the peer is approved for Read Access is automatically approved for READ-WRITE access as well (provided the peer knows the key)
[MEDIUM] RFC1918 IP leaks of all local interfaces of BTsync sharer
Turned out 10.65.6.165 was the one IP of one of the 3 peers sharing 1 folder, which was offline since about 3hrs at least, and couldn’t reach the other peers via its en0 interface (they were on tap0, L2 VPN on the 10.10.70.0/24 range)
[BP] Analysis of the Android APK
arm-none-eabi-objdump -T libbtsync.so 0008f738 g DF .text 00000002 KeccakInitialize ... 0008ebbc g DF .text 00000b7a KeccakPermutationOnWordsAfterXoring1344bits
Keccak == SHA3 identified in binary
[MEDIUM] A lot of HTTP endpoint identified from android client, showing a lot of collection done by client:
https://sync-push-proxy.bittorrent.com https://syncdev.bittorrent.com/check_api_key.php?key=%S&id=%s http://%S/sync.conf http://%s/updatestats.php http://%s/installstats.php http://%s/update_event.php http://www.usyncapp.com/cfu.php https://link.getsync.com/
[HIGH] GetSync.com server receives many (all?) hashes in cleartext when sharing the directory:
It is used to share links amongst people, even though the previous BTsync hash sharing mechanism was better for security as it used the btsync:// prefix and did not disclose (some) hashes to a 3rd party website:
gives:
This corresponds to:
https://link.getsync.com/#f=<FOLDER_NAME>&sz=<SIZE?>&s=<SKEY>&i=<IKEY>&p=<PKEY>&e=<PSEUDO_SERIAL_NUMBER>
* shared folder for Vuln resesearch:
btsync://link.getsync.com/?f=BTsync_vulnressz=0s=4CFSJ5N6VBZ5V6FJJ7NNHMSFGNJL3JD7i=CG7ZOY5EMSBVGZ2F2ZYBYNYCXJOC6QFFIp=CBIXBYY5DVY5E4IV4WCXCD6IB2TETXZTe=1414091285
BHQ2YF6OABESZA3ZQNXIPALEVHWLXWTQX
Decoding :
AKFAGQLZN46LKKYHLJ7AB6WZFYFXQMBYA
BVGBHFB7P6RX2Z4TAHZAJZ5W44UCBFJ3L
===
[HIGH] Bootstrap of a new shared folder == sharing of info to t.usyncapp.com which then receives the hashes in encoded but cleartext format
$ host t.usyncapp.com t.usyncapp.com has address 54.225.196.38 t.usyncapp.com has address 54.225.92.50 t.usyncapp.com has address 54.225.100.8
Data captured by:
sudo tcpdump -w sharing2.pcap -n -i en0 host 98.143.146.7 or host 54.225.92.50 or host 54.225.100.8 or host 54.225.196.38
Test_sync2
RW: AIYTDJ4YAQW4PUDEDMCHW437SUBAYSCYS (B32 prefixed with A) -> B32encode of 462634f30085b8fa0c83608f6e6ff2a041890b12
DSECRET = DIYTDJ4YAQW4PUDEDMCHW437SUBAYSCYS
$Esecret = `btsync –get-ro-secret $Dsecret`
ESECRET = EDU574JYKIESJEPII4KV7SFLOX2ZJWMWIGMXOS4KKI56ZAAKT366Q5RE7GQ
ESECRET[0:32] == download key
RO: BF7ZMYKECFTUSIQC3KALBC66EK6G7YYSE (B32 prefixed with B) -> B32encode of 2ff2cc28822ce924405b5016117bc4578dfc6244
https://link.getsync.com/#f=Test_sync2&sz=0&s=75LXJNGQX7ZKJM7GTBAU3JTAGE45NQUB&i=CZXT6CZOTHJ5QRWWD3YAIKWSJZKAT5KOP&p=CBIXBYY5DVY5E4IV4WCXCD6IB2TETXZT&e=1414092046
client i386 Linux :
.text:08126967 mov dword ptr [esp+4], offset aSFSSSSISPSS ; "%s#f=%s%s&s=%s&i=%s&p=%s%s"
- s=75LXJNGQX7ZKJM7GTBAU3JTAGE45NQUB -> B32encode of ‘\xffWt\xb4\xd0\xbf\xf2\xa4\xb3\xe6\x98AM\xa6`19\xd6\xc2\x81’ ff5774b4d0bff2a4b3e698414da6603139d6c281
- i=CZXT6CZOTHJ5QRWWD3YAIKWSJZKAT5KOP -> C prefixed of B32 encode of ‘\xcd\xe7\xe1e\xd3:{\x08\xda\xc3\xde\x00\x85ZI\xca\x81>\xa9\xcf’ cde7e165d33a7b08dac3de00855a49ca813ea9cf
- p=CBIXBYY5DVY5E4IV4WCXCD6IB2TETXZT -> B32 encode of ‘\x10Qp\xe3\x1d\x1dq\xd2q\x15\xe5\x85q\x0f\xc8\x0e\xa6I\xdf3’ 105170e31d1d71d27115e585710fc80ea649df33
“s” can be found also in .sync/ID on the shared folder
“s” leaks to t.usyncapp.com
“p” leaks to t.usyncapp.com
[HIGH] Btsync leaks p=’105170e31d1d71d27115e585710fc80ea649df33′ in bootstrap comms to t.usyncapp.com at packet #1 at offset 0x71
Proof:
0070 3a 10 51 70 e3 1d 1d 71 d2 71 15 e5 85 71 0f c8 :.Qp...q.q...q.. 0070 3a 10 51 70 e3 1d 1d 71 d2 71 15 e5 85 71 0f c8 :.Qp...q.q...q.. 0070 3a 10 51 70 e3 1d 1d 71 d2 71 15 e5 85 71 0f c8 :.Qp...q.q...q..
Full packet:
0000 00 06 4f 8f e8 6c 3c 15 c2 dd 11 d6 08 00 45 00 ..O..l<.......E. 0010 00 96 92 62 00 00 40 11 4a 60 0a 00 00 82 36 e1 ...b..@.J`....6. 0020 5c 32 c0 ab 0b b8 00 82 d2 4e 01 00 ac 80 43 8e \2.......N....C. 0030 8e f1 ed e1 a4 15 00 10 00 00 d0 d3 cd fe 00 00 ................ 0040 00 62 64 32 3a 6c 61 36 3a 0a 00 00 82 c0 ab 32 .bd2:la6:......2 0050 3a 6c 70 69 34 39 33 32 33 65 31 3a 6d 39 3a 67 :lpi49323e1:m9:g 0060 65 74 5f 70 65 65 72 73 34 3a 70 65 65 72 32 30 et_peers4:peer20 0070 3a 10 51 70 e3 1d 1d 71 d2 71 15 e5 85 71 0f c8 :.Qp...q.q...q.. 0080 0e a6 49 df 33 35 3a 73 68 61 72 65 32 30 3a aa ..I.35:share20:. 0090 28 6e 21 88 b7 0f 18 e0 39 b5 4c e4 20 af 0d 42 (n!.....9.L. ..B 00a0 4f cd 7c 65 O.|e
[HIGH] Btsync leaks s=’ff5774b4d0bff2a4b3e698414da6603139d6c281′ in bootstrap comms to t.usyncapp.com at packet #28 at offset 0x8F
Proof:
0080 0e a6 49 df 33 35 3a 73 68 61 72 65 32 30 3a ff ..I.35:share20:. 0090 57 74 b4 d0 bf f2 a4 b3 e6 98 41 4d a6 60 31 39 Wt........AM.`19 00a0 d6 c2 81 65 ...e
Full packet:
0000 00 06 4f 8f e8 6c 3c 15 c2 dd 11 d6 08 00 45 00 ..O..l<.......E. 0010 00 96 5a 62 00 00 40 11 1a 6c 0a 00 00 82 36 e1 ..Zb..@..l....6. 0020 c4 26 c0 ab 0b b8 00 82 38 83 01 00 43 10 4a 9f .&......8...C.J. 0030 28 7e ca d8 41 18 00 10 00 00 e1 e6 0f 57 00 00 (~..A........W.. 0040 00 62 64 32 3a 6c 61 36 3a 0a 00 00 82 c0 ab 32 .bd2:la6:......2 0050 3a 6c 70 69 34 39 33 32 33 65 31 3a 6d 39 3a 67 :lpi49323e1:m9:g 0060 65 74 5f 70 65 65 72 73 34 3a 70 65 65 72 32 30 et_peers4:peer20 0070 3a 10 51 70 e3 1d 1d 71 d2 71 15 e5 85 71 0f c8 :.Qp...q.q...q.. 0080 0e a6 49 df 33 35 3a 73 68 61 72 65 32 30 3a ff ..I.35:share20:. 0090 57 74 b4 d0 bf f2 a4 b3 e6 98 41 4d a6 60 31 39 Wt........AM.`19 00a0 d6 c2 81 65 ...e
https://gist.github.com/anonymous/10002835
>>> from base64 import b32encode, b32decode >>> from hashlib import sha256 >>>
>>> import base64
>>> base64.b32decode("75LXJNGQX7ZKJM7GTBAU3JTAGE45NQUB")
'\xffWt\xb4\xd0\xbf\xf2\xa4\xb3\xe6\x98AM\xa6`19\xd6\xc2\x81'
>>> base64.b32decode("75LXJNGQX7ZKJM7GTBAU3JTAGE45NQUBsdfdsf")
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/base64.py", line 198, in b32decode
raise TypeError('Incorrect padding')
TypeError: Incorrect padding
===
[LOW] Client has large open port attack surface
on OS X, 10.9, latest beta of BTSync as of 2014-10-16
$ sudo lsof -n -i4 | grep BitT BitTorren 21586 gufo 8u IPv4 0x66672eb09113c9a5 0t0 TCP *:58246 (LISTEN) BitTorren 21586 gufo 9u IPv4 0x66672eb093ee4345 0t0 UDP *:58246 BitTorren 21586 gufo 10u IPv4 0x66672eb08c8c2df5 0t0 ICMP *:* BitTorren 21586 gufo 19u IPv4 0x66672eb0911517d5 0t0 UDP *:sos BitTorren 21586 gufo 28u IPv4 0x66672eb08d4101c5 0t0 UDP *:sos BitTorren 21586 gufo 37u IPv4 0x66672eb08e4579a5 0t0 TCP 10.10.70.54:58551->67.215.231.242:hbci (ESTABLISHED) BitTorren 21586 gufo 56u IPv4 0x66672eb08d98d18d 0t0 TCP 10.10.70.54:58924->10.65.6.165:37658 (SYN_SENT) BitTorren 21586 gufo 57u IPv4 0x66672eb08b5a49a5 0t0 TCP 10.10.70.54:58925->213.46.228.104:9678 (SYN_SENT)
===
[HIGH] Many vulnerabilities of the Web administration interface on http://localhost:8888/ in the Linux client :
– Traffic is HTTP and not encrypted
– Session Cookie without flags “Secure” nor “HTTPOnly” (accessible from javascript)
– Authentification HTTP basic, problem if XSS
– Vulnérable to click-jacking
– Admin Interface is iframeable
Interface reveals contents of dirs (but this requires the token local auth):
GET /gui/?token=0fNf-snGBnzD5uQBYe3X8j2EcHdXYhN5VUNnZuD3Wtt8r-CyLn81orFdRVQAAAAA&action=getdir&dir=/&t=1413832523603 HTTP/1.1
{ "folders": [ "//bin", "//boot", "//cdrom", "//dev", "//etc", "//home", "//lib", "//lib32", "//lib64", "//lost+found", "//media", "//mnt", "//opt", "//proc", "//root", "//run", "//sbin", "//srv", "//sys", "//tmp", "//usr", "//var" ] }
====
Anecdote : le shareHash est un double SHA256, comme pour miner des bitcoins -> si le shareHash commence par des null bytes, cela donne un bloc bitcoin valide
====
[MEDIUM] Attack vector potentiel : mise à jour automatique (silent update) du client en HTTP sur http://update.utorrent.com
====
[LOW] Username/Password for web interface can be overriden when providing a new config file to btsync:
./btsync –config conf_file
conf_file:
{
.....
"webui" :
{
"listen" : "0.0.0.0:8888" // remove field to disable WebUI
/* preset credentials. Use password or password_hash */ ,"login" : "another_login" ,"password" : "another_password" .... }
===
Crypto Specs
http://www.bittorrent.com/intl/fr/sync/tech-specs -> “Les clés Sync sont des chaînes de 20 octets générées aléatoirement à l’aide de /dev/random (sur Mac et Linux) et l’API Crypto (sur Windows).”
Some details about the different types of secrets:
- A read-write secret (“master secret”) currently begins with “A” and is 33 characters long.
- A read-only secret begins with “B” and is 33 characters long.
- A one-time secret (either full or read-only), valid for 24 hours, begins with a “C” and is 33 characters long.
- A read-write secret with encrypted support begins with a “D” and is 33 characters long. At the time of this post, you can’t generate one of these from the program, but you can just change the first character from “A” to “D” when you generate a new secret. Older versions of btsync will not accept such secrets.
- A read-only secret for a share supporting encryption begins with an “E” and is 59 characters long.
- A read-only encrypted secret (i.e. the machine can download and share the files but not decrypt them, so it can seed but not read them) begins with an “F”. It is the read-only secret but with the first character changed from “E” to “F” and truncated to 33 characters.
(source: http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/)
btsync-secret – A Bittorrent Sync Secret Generator : https://gist.github.com/anonymous/10002835
Perl script to generate secrets and config data for BTsync : https://gist.github.com/sciurius/787e99af74132b62b397
===
Pro tip from one participant:
If you have one charset being converted into another charset by a function, here is how to calculate the expansion factor:
Expand factor base32 :
? log(256)/log(32)
%1 = 1.6000000000000000000000000000000000000
? 59/1.6
%2 = 36.875000000000000000000000000000000000
? 33/1.6
%3 = 20.625000000000000000000000000000000000
===
[LOW] There are long hardcoded base64 strings in the binaries. This is a bit suspicious.
===
[MEDIUM] Infrastructure is dependent on other, maybe insecure, infrastructure and deployments
Incoming connection from 67.215.229.106:3000 106.229.215.67.in-addr.arpa domain name pointer relay-01.utorrent.com. Requesting peers from tracker 54.225.92.50:3000 50.92.225.54.in-addr.arpa domain name pointer ec2-54-225-92-50.compute-1.amazonaws.com. Requesting peers from tracker 54.225.196.38:3000 38.196.225.54.in-addr.arpa domain name pointer ec2-54-225-196-38.compute-1.amazonaws.com.
If Amazon gets hacked, security of whole BTsync architecture is compromised. Not a graceful failure.
===
The local BTsync database are stored as SQLite3 static files:
# echo .dump | sqlite3 E08B24F5BEA873DAF8A94FDAD3B2453352BDA47F.db
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE files(path TEXT NOT NULL PRIMARY KEY, data BLOB NOT NULL);
INSERT INTO "files" VALUES('SOMETHING.txt',X'31534645000202010204010503105E45540000000005050F5E45540000000005060B0000000000000001071400000027EA44293CBCBF85EDC78942253CF4F59B2CA53205080100000000000000040AA4010000010B14000000105170E31D1D71D27115E585710FC80EA649DF33051FF92B000000000000010D4000000079CC14BDBB24A186BB191421F3DA25C9B4917063C61FB4B0F959B813BD710893AFB9A98A728681FB1314BA66CBE00F912C94B2F03C32FA166B8B8EE038F9760D050E01000000000000000210010511FFFFFFFFFFFFFFFF0512FFFFFFFFFFFFFFFF0113140000000000000000000000000000000000000000000000021700021801021900021A00021B01021C00011D1400000042A6A216454A96EBD29E5E491209B1858CBEA46C012018000000315346450001010D000000534F4D455448494E472E747874');
INSERT INTO "files" VALUES('macosx-sharing-preference.png',X'31534645000202010204010503C5664554000000000505A86645540000000005060D5E0300000000000107140000001EB8B63229D7A82E11335C2E8CA3264EB680318B05080700000000000000040AA4010000010B14000000105170E31D1D71D27115E585710FC80EA649DF33051FFC2B000000000000010D4000000011BF9D19C09EEB1027BA5637F6438A49E15B50AB20B7C51D03D4A0286CFCCBC5E9E277584B00ED052E2C249C14C0946C62701A0C286ADDC91CC9EFFD82B83E05050E0700000000000000010F040000005F0000000210010511FFFFFFFFFFFFFFFF0512FFFFFFFFFFFFFFFF0113140000000000000000000000000000000000000000000000021700021801021900021A00021B01021C00011D140000007050006B555D8C087F35EE61C1C94BD5A239394C012028000000315346450001011D0000006D61636F73782D73686172696E672D707265666572656E63652E706E67');
INSERT INTO "files" VALUES('sharing2.pcap',X'315346450002020102040105035164455400000000050550644554000000000506780F000000000000010714000000FD40BEE17447198DCEFEFDBB942890204CE8674505080100000000000000040AA4010000010B14000000105170E31D1D71D27115E585710FC80EA649DF33051FFB2B000000000000010D4000000065FC7374E3C8E18D44615C5A537714B1C484AF61E080B085FACD3DF365B1B7E526BD0277E8E3D9116F7EB33D0CC49DD8C5C6590933C72EBBE0C2035967DD770C050E01000000000000000210010511FFFFFFFFFFFFFFFF0512FFFFFFFFFFFFFFFF0113140000000000000000000000000000000000000000000000021700021801021900021A00021B01021C00011D14000000DE01D8D1E0D7538C3B32E2081DDDA2ECBC53D947012018000000315346450001010D00000073686172696E67322E70636170');
CREATE TABLE deleted_files(hash BLOB NOT NULL PRIMARY KEY, data BLOB NOT NULL);
CREATE TABLE meta(hash BLOB NOT NULL PRIMARY KEY, data BLOB NOT NULL);
INSERT INTO "meta" VALUES(X'27EA44293CBCBF85EDC78942253CF4F59B2CA532',X'64343A696E666F64363A6C656E6774686931316531323A7069656365206C656E67746869333237363865363A70696563657332303A1E4217A810941AE00410A08896DC8BD3F59721FE6565');
INSERT INTO "meta" VALUES(X'1EB8B63229D7A82E11335C2E8CA3264EB680318B',X'64343A696E666F64363A6C656E677468693232303638356531323A7069656365206C656E67746869333237363865363A7069656365733134303A4F153692EB44ACD0CB9964457C58F0C912C4BC366576CCFF5EF9A076962F78B651966E451CE865DA2BB45AEDA32D3A408B83F1D9B598CB91B767D9D4A16FF047F6B927C0AB42F1B3CCF277986E16844CD6DB0CFB1A267D2BCDDFD38EC6241DEA8C550188F683A4EC96D37B416D14BF0A5E962999744C3F7B087634F89C9B4333FD0AEED772A9D2410A5253486565');
INSERT INTO "meta" VALUES(X'FD40BEE17447198DCEFEFDBB942890204CE86745',X'64343A696E666F64363A6C656E67746869333936306531323A7069656365206C656E67746869333237363865363A70696563657332303A8D1919C2731CB917671FCFEF2D961ACFA43C598D6565');
COMMIT;
VALUES('SOMETHING.txt',X'31534645000202010204010503105E45540000000005050F5E45540000000005060B0000000000000001071400000027EA44293CBCBF85EDC78942253CF4F59B2CA53205080100000000000000040AA4010000010B14000000105170E31D1D71D27115E585710FC80EA649DF33051FF92B000000000000010D4000000079CC14BDBB24A186BB191421F3DA25C9B4917063C61FB4B0F959B813BD710893AFB9A98A728681FB1314BA66CBE00F912C94B2F03C32FA166B8B8EE038F9760D050E01000000000000000210010511FFFFFFFFFFFFFFFF0512FFFFFFFFFFFFFFFF0113140000000000000000000000000000000000000000000000021700021801021900021A00021B01021C00011D1400000042A6A216454A96EBD29E5E491209B1858CBEA46C012018000000315346450001010D000000534F4D455448494E472E747874');
This will produce :
0000000: 3153 4645 0002 0201 0204 0105 0310 5e45 1SFE……….^E
0000010: 5400 0000 0005 050f 5e45 5400 0000 0005 T.......^ET..... 0000020: 060b 0000 0000 0000 0001 0714 0000 0027 ...............' 0000030: ea44 293c bcbf 85ed c789 4225 3cf4 f59b .D)<......B%<... 0000040: 2ca5 3205 0801 0000 0000 0000 0004 0aa4 ,.2............. 0000050: 0100 0001 0b14 0000 0010 5170 e31d 1d71 ..........Qp...q 0000060: d271 15e5 8571 0fc8 0ea6 49df 3305 1ff9 .q...q....I.3... 0000070: 2b00 0000 0000 0001 0d40 0000 0079 cc14 +........@...y.. 0000080: bdbb 24a1 86bb 1914 21f3 da25 c9b4 9170 ..$.....!..%...p 0000090: 63c6 1fb4 b0f9 59b8 13bd 7108 93af b9a9 c.....Y...q..... 00000a0: 8a72 8681 fb13 14ba 66cb e00f 912c 94b2 .r......f....,.. 00000b0: f03c 32fa 166b 8b8e e038 f976 0d05 0e01 .<2..k...8.v.... 00000c0: 0000 0000 0000 0002 1001 0511 ffff ffff ................ 00000d0: ffff ffff 0512 ffff ffff ffff ffff 0113 ................ 00000e0: 1400 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 0000 0000 0000 0217 0002 1801 0219 ................ 0000100: 0002 1a00 021b 0102 1c00 011d 1400 0000 ................ 0000110: 42a6 a216 454a 96eb d29e 5e49 1209 b185 B...EJ....^I.... 0000120: 8cbe a46c 0120 1800 0000 3153 4645 0001 ...l. ....1SFE.. 0000130: 010d 0000 0053 4f4d 4554 4849 4e47 2e74 .....SOMETHING.t 0000140: 7874 xt
===
[HIGH] Many crashes of the client by fuzzing
Fuzzing with /dev/urandom
167 hits / 10 000 000 packets : [20141020 21:17:03.307] Incoming connection from 192.168.0.1:42630
Example:
# echo QQJ0VVF9s2inNx4nRrR6Qexa7X3uZ12s3BheRoJmYfSi4xWdsOqHSASpUr2FgBI/ydW4g3hzwLkhhKE2c3VgZFDjEU0dhjAtCm1Ymg== | base64 -d >packet # hping -2 -E packet -d 76 [IP] -p [PORT]
Exploitability:
glibc23_i386 (static):
Position Independent Executable: no, normal executable!
Stack protected: no, not found!
Fortify Source functions: no, not found!
Read-only relocations: no, not found!
Immediate binding: no, not found!
glibc23_x64 (static):
Position Independent Executable: no, normal executable!
Stack protected: no, not found!
Fortify Source functions: no, not found!
Read-only relocations: no, not found!
Immediate binding: no, not found!
i386:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes
Read-only relocations: yes
Immediate binding: no, not found!
x64:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes
Read-only relocations: yes
Immediate binding: no, not found!
5. TL;DR & Conclusions
- Probable leak of all hashes to getsync.com and access for BitTorrent Inc to all shared data.
- 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.
- Leak about the private network addresses of clients that gives indication about where and what to attack.
- Probable multiple vulnerabilities of the clients.
- Bottom line: Do not use for sensitive data.
About Hackito Session
Hands-on hacking sessions held on selected subjects for security enthusiasts while eagerly waiting for the next Hackito Ergo Sum conference that takes place each year in Paris around April-May. If you want to join next, come chat with us on #hackito on FreeNode.
Update 1: 2014-11-17
Some people are discussing this on Hacker News:
https://news.ycombinator.com/item?id=8618067 –> Top page of Hacker news today
And on Reddit:
https://www.reddit.com/r/netsec/comments/2mi978/bittorrentsync_security_privacy_analysis_hackito/
Update 2: 2014-11-18
BitTorrent has some reaction to that post and are preparing a thorough answer. Also some forum posts:
It’s good that they care about their security. From the forum post, one commenter said:
> Wording of “Probable leak of all hashes to getsync.com and access for BitTorrent Inc to all shared data.” is very close to “I almost hacked microsoft today”
If the client was a bit more open or at the very least explained, then such claim could be easily disproved right? To me, that’s the price of opacity.
Hopefully Bittorrent is going to change this by providing real security insights and more information about their solution.
Update 3: 2014-11-19
Official response from BitTorrent Inc. Let’s praise their quick-to-react and overall nice reaction to this research.
http://forum.bittorrent.com/topic/32592-bittorrent-sync-security-is-our-highest-priority/ –> top page of Hacker news, again 😉
What we would need is a clear explanation of the relationship and uses of all the hashes, an explanation of the findings on stability of client. Maybe a roadmap + timeline for fixing issues that are relevant to them (if any 😉 this is still a possibility).
Lastly, what is interesting is the number of trolls in the forums who are prompt to shoot the messenger. This is still a “witch hunt” behavior that depicts some “security researcher hostile” conservative view which is recessing/decreasing but sadly still present. BitTorrent Inc. was not in any way behaving in a conservative way toward this research, kudos to them for being mature on this subject.
Speaking of responsible, some forum comments also said something along the lines: “bzz bzzz bzz Responsible bzzz Responsible bzzz bzz bzzz RRRRResponsible!” in a very “Being John Malkovich” way. One must not mistake Responsible disclosure (not giving firearms to kids) with ahead notification (enabling Marketing downplays by advance disclosure to the software or service editor). Based on our experience, advance notification usually harms fast patching. In the end, what only counts is better security.
