Has anybody reviewed the rest of this chapter?
https://books.google.com/books?id=xp-oCgAAQBAJ&pg=PA85#v=onepage&q&f=false
3 Likes
Full version:
3 Likes
The last sentence in the introduction pretty much sums it up.
There are a few details which are wrong in the paper, hence I think it’s more of a paper released for the sake of getting a diploma.
TL;DR: They are looking at the case where a “suspect” has files stored in Syncthing, which an “investigator” wants to access. If the files aren’t directly accessible (because they were deleted, encrypted, on an external drive), they can restore the files from a peer. For this, they take the suspects Syncthing keys and connect to a node to download the files.
If you store confidential files in Syncthing, keep your keys and logs secure!
@AudriusButkevicius They wrote such a tool for the paper (called SSERT).
2 Likes
Awesome!
I should add that the attention is validation of the efficacy and slick design of the tool.
“At the time of writing, there are no tools available for the recovery of evidence from Syncthing.”
It also seems that the POC tool they present requires a good bit of information before Syncthing can be exploited (term used loosely):
- Peer *.log files
- Device-ID
- Announce Server
- Machine’s cert.pem and key.pem files
This should give Syncthing users a great deal of confidence that their data will remain private, assuming some greater power doesn’t have the ability to break the crypto.
1 Like
Was BEP developed for Syncthing, by Syncthing? Are there any other known applications which are known to use this protocol?
Yes, it was initially developed by calmh, the specification is here. There are a few alternative Syncthing implementations listed here, and the iOS client by vhbit also implements it.
I guess at least two points of attack in that paper can be turned into opsec tips for the security minded user:
-
If a device of yours is lost, make sure to revoke its access from your other devices.
-
If you’re syncing confidential data on an encrypted disk to guard against device theft, put the Syncthing config on the same encrypted disk to avoid leaking keys and metadata.
Beyond that it just seems like a lot of words around the fact that Syncthing can get files from a peer device.
There was an stdownload tool for testing early on that just connected to a device, received the index, and downloaded all files for a folder. But it wasn’t interesting enough to keep around…
Oh, and
- Syncthing does not provide anonymity. Don’t assume it does. If the law catches you and your accomplice, and your devices, they may prove you communicated with each other.
And they call it “SyncThing”. 
3 Likes
If it’s for forensic analysis, I agree that BEP is valid for having a file identically clone for verify, but you need both the machine to add each other and share the same folder id in order to communicate and sync file, and for that, I don’t think any “suspect” will give up their permission on that and this highly may not approve for use in court.
Plus any manipulate on host will compromise the source HDD and should not be tempered with, so syncthing is not recommend for use in digital forensic situation.
BEP, however, can also be use to develop a new tool for its read-only method.
P.S. “Former” cert holder of CHFI by EC-Council
You understand wrong. Tthey recover the keys from a suspect’s device, so they can use that to connect to other nodes. No need to add a new device, because to Syncthing it’s the same one.
That won’t help them if your computers are whole disk encrypted…
if they recover the keys from a suspect and use that to connect to other nodes, they also risk having the sources being alternate and plant virus/backdoor; if you don’t add a new device, syncthing would have wipe the evidence on the other side clean, either way, the chances are 50/50