What can InSync do to protect against Ransomware?

Feature requests
#1

This isn’t much of a question but rather an attempt to brainstorm about a key aspect of synced backups. Ransomware like CryptoLocker or Reveton is probably the hottest threat to personal computers these days. I take many precautions to prevent infection but no one is 100% secure. Taking backups on offline media is one possibility but didn’t we resort to cloud storage to eliminate such methods? I’m active on the Google Drive help forum and see these situations pop up where Ransomware encrypts entire drives and then they are synced to the cloud, rendering every file unusable. Let’s face it, Google’s file versioning system is worthless and this worries me a great deal.
I believe InSync can take this opportunity to provide protective measures. Perhaps it can utilise Windows’ own VSS or maybe InSync can detect anomalous behaviour (large amount of files being encrypted) and put a stop to the sync.

I’d love to hear your ideas!

1 Like
#2

No?.. No takers? So we’re all cool with all our data getting unrecoverably encrypted? Okay… If that’s how it’s going to be.

#3

Nice idea. Though I think technically a bit difficult. If an antivirus program in the system cannot recognize activity of some ransomware, do you really think InSync could do better?

But I have a simple idea that could actually work quite well in case of InSync if you use it mostly for syncing documents, media files etc. InSync could check if the header of each updated file doesn’t change (e.g. the JPG header, ZIP header, and so on). If it does, it should ask the user what to do next. Of course this method would be wrong if you use InSync to sync “arbitrarily formatted” data, like some experimental results, CSV/TXT files etc.

1 Like
#4

Smart thinking! That’s what I’m talking about. Of course, it shouldn’t drastically impact sync speed (which might be the case if an additional check has to be done on every file) but it seems reasonable. Whatever could be implemented, it could also be an optional setting. Perhaps even selective as in “do these header checks in folder A but not in B and C”.

#5

Personally I don’t think there’s much InSync can do. What I ended up doing is signing up with Spanning Backup to take snapshots of my Google Drive onto Amazon every day. Cloud-to-cloud backup, $40/year. Spanning is one of the few providers I found that will do personal Google accounts. (Why did I choose Spanning over someone else? I don’t really have an answer for that…)

1 Like
#6

I think the main danger with ransomware on GoogleDrive is the malware circumventing Google’s versioning mechanism (e.g., rapidly saving 101 new versions of each file to purge its history). Anything else it does could be fixed by simply rolling back all files to prior versions.

Therefore, I propose that the main effort should be put into addressing this thread, here.

1 Like
#7

I don’t think InSync can help, but there is a device that can help, it runs Linux and you connect to your network and have a hard drive on the other side, linux acts as a circuit breaker: https://www.baqapp.com.au/index.php

1 Like
#8

The best solution, on my view, is a encrypted file that is only accessible by InSync with an user password given at computer startup (so if any program try to change the database will end corrupting it), so insync can store checksums(SHA-256, etc) and verify a file integrity COMPLETELY… It is the best solution I believe is possible, similar technique without encryption is used to prevent against bit rot on first class enterprise FS like BTRFS and ZFS.

But this is not a “the end…” for those problems. Cloud can be merchandised as “the end of backup” but the truth is, that it is only a complement and things turn worst when the cloud did not take sane FS patterns, anyway, the solution I appoint is pretty hardened, as the program would need to explore InSync or the user to get vulnerability acess.

As I did not believe in the cloud as the silver bullet, (neither in me when I’m tweaking the system). I still use BTRFS in my machine, use it to take and transfer read-only snapshots of my drive in a day basis, as it is the most reliable protection against undesired modifications on backups as it would be necessary to explore Kernel faults to get access to those read-only subvolumes. So I protect myself against imprevisible catastrophes, but against personal mistakes that would break my system.

Seeing from Google perspective, it really should think on a two pass validation of read-only files, or something like this, is a pretty extra hardening.

Update:
I just want to point this only make sense for a read-only files feature, checksum are not secure for writable files, you can’t guarantee it is you modifying the file.

1 Like
#9

Great input you guys!

@Kevin_Matheson I like your Cloud-to-cloud backup solution, I was actually looking for something like that. You probably chose Spanning because, as you said, there isn’t much choice for non-professional users. I did some research and found one that’s $10 cheaper per year, CloudAlly (+ 2 months free). I’ll give that a try myself!

I didn’t even consider that, @yoniy0. So even if Google’s versioning would actually work, it’d be useless anyway :astonished:
On top of that, even if you have to go only one version back to recover the needed files, you’d have to go through them one by one as Google doesn’t support batch actions unless you start scripting (or so I’ve read). Perhaps InSync can make/implement a meaningful recover script. It’s comforting to read that they’re working on that.

#10

I would suggest that the two files, present “in use” (possibly encrypted by malware) and “good” (last unencrypted version, on cloud) be tested for their edit distance by something like Levenshtein distance https://en.wikipedia.org/wiki/Edit_distance , and the synchronization be held and flagged for approval by the operator if the edit distance is unreasonable. There are many cases this may succeed, although it will likely fail for things like resized photos.

Maybe we need something like Apple’s Time Machine, let’s say a certain maximum number of versions are held, which depends on the date between versions. The newest version is pushed up, and an older version falls off the back, but intermediate versions are not synched. Some number of old synched versions is held on the cloud without synching, possibly by shiftin to a folder “synched on back” which is not syched down. This could be set with user preferences, maybe on a mime type basis.

#11

Cool! You just explained how spellchecking works :slight_smile:
I like that line of thought but how can a system tell the difference between a file being encrypted and a file being altered in a normal way? Maybe there’s a fool proof algorithmic way, maybe this edit distance can be such way…

A Time Machine sounds good as well as it keeps recent changes but also originals from a week ago, a month ago and a year ago. Like that it doesn’t really matter how many times a file is encrypted, you can still restore last week’s version. I do wonder, if Ransomware would exist for OSX, would it also encrypt the Time Machine files on the connected external drive?

Whatever measure we can think of, it should happen remotely only as any local files are prone to be destroyed.

#12

Just evolving my point. The use scenarios are:

  1. avoid InSync to propagate corruptions for drive
  2. turn possible for InSync to REALLY restore file from drive or vice-versa.

How I would define the feature use case:

precondition -> user inform database password to InSync, so it can access for background verifying files

1 . wright click a file/folder and set to “local read-only file synchronization”.
2 . Ask the checksums database password so insync can store the file checksum in a encrypted database.
3 . set the file to read-only on the FS/system user rules/etc (but it would not be obligatory… see note 1). and hash the file and store it in the database.

note 1: if someone change the file (locally or on drive), verify both local and drive file integrity, the one that match the checksum is preserved and will substitute the changed one, be it in drive or locally, this way you did not need to care about FS or OS read-only features.

update

It can become more sophisticated…
1 . shared, signed database… where private key is encrypted to be shared too…

#13

I think of InSync as synchronization software. As you say, it’s not a backup since there is no concept of snapshots. I run separate software to push versioned backups into several clouds. I personally use Arq Backup but there are several alternatives.

It might be nice for InSync to offer that, but I’d expect it to be an addon at extra cost since it’s high complexity. The software algorithms aren’t complicated, but they have to be 100% correct. It’s the support costs that would be brutal, as InSynch would have to staff up to handle people dealing with the complexities of restoring data.

Personally, I’d like one of the existing backup services to integrate with Google Drive, OneDrive, and other APIs and do automatic backups. It would be like Arq except no desktop client to run.

Good thread, btw.

1 Like
#14

Okay, I haven’t used Drive’s versioning features, but I went and looked - it seems I could restore any file to any version I’ve had synced, for 30 days back. Surely that’s good enough for ransomware, isn’t it? You’d notice if it had been corrupted for 30 days.

I can only assume this feature doesn’t work as well as it appears to. Can someone explain?

Seems to me, the feature that would be useful for InSync would be to say “Hey, go tell Google Drive to restore everything to the way it was [10 days ago]. Copy my current sync directory HERE so I don’t lose them in case there’s something useful left, and copy the restored version from Drive THERE. Oh, and if you have to ask to restore each file individually, then go do that for me, thanks!”

Could it be that simple? It’s only 30 days, but…

EDIT: Addition
Oh, and I’m not sure I want InSync incurring all the overhead of monitoring what specific changes are being made to my files and trying to detect ransomware-like activity. There are antivirus products for that - if they can’t handle it, with security experts already on staff and already used to reading every file on your system, why should I expect this tool to? If they add it as a feature, I’d seriously consider disabling it from the start - why incur the cost, and potential collisions with antivirus, for the chance it MIGHT catch some behavior the antivirus didn’t? Seems like the wrong place to put this feature, to me.

1 Like
#15

The point I discussed work but sure it is not trivial to support and basically it would need intense support. Realistically talking, yes it is a dirty solution… But this will be pretty weird as is, at last until Google Drive API evolve to offer integrity solutions too. Lets see…

Anyway, any backup tool that did not rely on REAL read-only snapshots, is pretty much vulnerable to user catastrofe, ransomware, inadequate changes, bit rot, independent of antivirus. And I agree it is not much sane to turn InSync in this direction.

Personally I would prefer work done in an API for plugins.

update

@Zan solution is pretty sane for Windows users and not so much expensive, it relly on solid enterprise OS and FS, one cool example I saw those day was Nextcloud Box, that really is not much more expensive than a HD itself…

#16

Why don’t you just use cloudally.com; it’s cheaper and it does incremental backups of your private google drive onto their own servers.

#17

Spanning Backup does the same thing (incremental backups). Now that I’m thinking about it, I believe I didn’t go with CloudAlly because I didn’t like the answers their sales team gave, or maybe it was how long they took to get back to me. Using a known name (EMC, now Dell) also gave weight to my decision.

There’s also a service that’s even cheaper: UpSafe. However, I never was able to get a complete backup done, and their website lacks information on how they will keep my data secure.

#18

+1,000 eborah

There is absolutely no reason to expect, much less require, a $25 syncing utility to suddenly morph itself into an antivirus, versioning, impenetrable safe. Your network is just that, your network, and the fail-safes you implement are yours to implement. As others have suggested, using a simple versioning system like Spanning will practically solve all your requirements.

#19

You’re absolutely right, on a security level InSync should make no effort at all. I was thinking more of something like the client utilising Google’s revision API.

The major problem with Google’s versioning is that every single file has to be restored manually via the web interface. Perhaps InSync can automate this. How cool would it be if you could right-click a folder and select ‘Restore previous version’ which would snap the folder and all the files it contains right back to normal.

I’m no expert and I don’t know what’s technically possible (or feasible for that matter) but I did think it was a good idea to bring this up and brainstorm about it.

On the C2C backup note, I’ve trialed both CloudAlly and Spanning and found the latter to be the most useful as they provide an excellent UI with folder structure.
Backupify by Datto responded that “The personal Google account backup is now a legacy feature we no longer offer.”.
CloudAlly said “Just to let you know, please note that in the near future we are planning to change a pricing plan from user to storage based.” and “we are in process to improve our UI and reports”.

#20

re: versioning – we are working on something for 2.0 :slight_smile:

1 Like