Protect config password from ransomware

Help and Support
1

Hi there,

happy to have found rclone as it looks really promising to do a sync of my local backup to some cloud storage! Even before starting, I have one question though...

I consider ransomware to be one of the most likely events to "break" my backup strategy. Problem is: as long as I want automated syncs to cloud, I have to store the access token on my machine, and so it can be found and used by some smart ransomware to make my cloud backup unusable.

Now with rclone I can use a password to encrypt the config/token, but the problem stays the same: as long as I want automated syncs, I have to store the password... I would really not be surprised to find current ransomware to search for terms like RCLONE_CONFIG_PASS or password-command in cron commands, or in scripts called by cron commands.

The only thing I came up with was to use some obfuscated wrapper script that generates the rclone call so that, at least, it isn't easily "auto-detected".

Is this only paranoia, or a relevant scenario in your opinion? How do you handle this?

Thanks for your thoughts
sben

2

hello and welcome to the forum,

once a hacker as admin access to a system, all bets are off.

there is no solution to that problem, only attempts to mitigate it.
and there are endless layer upon layer to use.

the issue is not so much the token, as how to configure permissions for the token.

for example, it would not matter much if i posted my config file.
-- whatever is backed up is already encrypted, using veeam and 7zip.
--- i only use s3 remotes, such as wasabi and aws.
which has iam/bucket polices, compliance settings, versioning and immutable buckets.

the main feature is using session tokens that require a 2FA/MFA token.
rclone can use temporary session token, but cannot create the token.
so even if you got the config file, it is useless, as the temp token is never saved to the config file.

3

Thanks for your thoughts asdffdsa,

Agreed, as long as we talk about an actual hacker that personally hacks into my system. I do not care much about that scenario as I'm neither rich nor famous nor important and cannot do so much about it anyway... I care more about some virus infecting my system and doing whatever an automated ransomware could do.

Encryption doesn't matter from my point of view as some ransomware still can add another layer of encryption and thus make your backup useless.

That is a good point, this is sort of an airgap backup as it cannot be altered from within your system!? I'm afraid this is out of my reach as my OneDrive doesn't seem to offer any of this features :unamused:

Can you explain this a bit more? Is there a way to create a temporary token automatically, but without exposing that very process to the ransomware?

4

not sure what you mean by ransomware, as ransomware simply a dumb scanner that scans the local hard drive and encrypts files with common file extensions such as .doc/.pdf and so on.
so cannot affect on your cloud files, unless, maybe, when using rclone mount
which i never use for backups.

ransomware only affects files on the hacked machine, not the files in cloud.
and even if ransomware could some how access the files in cloud,

  1. if versioning is enabled, then your cloud files are safe
  2. if you enable immutability for your files/folder/bucket, then ransomware could not even overwrite the cloud files.

no idea, would never trust/use onedrive for backups and as far as know, onedrive is not HIPAA compliant.

there are many storage systems that have those features, including but not limited to:
micro$osft azure, google cloud storage, s3 providers such as wasabi and s3.

in addition, yet another feature is to encrypt the files when uploading them to the cloud.
yes, rclone has the excellent crypt remote for that, but the passwords are stored in the config file.
so i use s3 sse-c encryption, and again, that password is not stored in the rclone config file.
and without that password, rclone will fail to upload/overwrite any cloud files, will not allow you to download any files.
so please, go ahead and steal my rclone config file.

i have a python script for that.

  1. creates the temp session token.
  2. creates an on the fly remote that uses that token and that token is never saved to the rclone config file.

so go ahead, steal my config file, does not matter to me but if you steal the config file, you would still have to have the rclone decryption password. and even if you get the config file, and get the encryption password,
then so what, as the config file does not have the temp session token, does not have the sse-c encryption password.

and even if you got all that info, still does not matter, as bucket immutability is enabled from the provider website.

5

I think this is already sufficient to protect from automated ransomware, from what I see it is rather simple, you just need to be better protected that the least protected half.

I use an uncommon way to compose my password from a password locked to my user account. This way it isn't enough to steal my config and rclone script, you would also need an IT knowledgable to find and execute the script from my user account. I consider that very unlikely unless you are a high value target. My script is inspired by this post.

The only way to truly protect against an IT knowledgeable human having access to you account is to have versioned backups behind a wall needing 2FA to delete/modify the historic versions, like @asdffdsa is doing with S3 policies. I do something similar using a server acting very much like the rsync.net snapshots.

Sounds like you will be happy to read this:

6

Yeah probably this is the right way to look at it. Maybe it was possible for randomware-authors to automatically detect your password-command and make use of it (in that case it doesn't matter how unusual or complex that script is, it just needs to be called and returns the password), but why should they bother if they don't see rclone users as a valuable majority...

Indeed, thank you! :smiley: Didn't know/ notice that feature. But for that matter, encryption might make a difference - in my OneDrive there is only encrypted files with hashed names in the first place, so I doubt their algorithm would detect an added layer of encryption (by ransomware) at all?!
Anyway, the ability to reset OneDrive to an earlier stage still exists and can be triggered also if not Microsoft, but myself detected an attack.

Thank you both for your insights! If anybody can add to this topic, I'm always happy to further think through all those scenarios :upside_down_face:

7

I don't think they are looking for patterns of encryption, that would be both difficult and resource demanding.

My guess is they primarily keep a vigilant eye on sudden changes in the file update/modification pattern and then check for signs of encryption by comparing the size of versions. That would work with any type of file and not take much CPU power.

8

Exactly, but then will they notice if my encrypted original is being overwritten with another (malicious) encrypted version? File size will not really change then, or is there a change in file size that is "typical" to encryption (like added headers or the like)?

9

usually ransomware marks files (already) encrypted by it. This may be by adding/changing file contents or by adding an extension like .wncry (wannacry) These modifications are visible even on another encryption. The only problem I see is if files are first encrypted by ransomware and then encrypted with rclone in this case onedrive will be unable to detect the ransomware attack. In any case versioning should be able to save your data.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.