Hacker News Reader

Comment by thaumasiotes | Hacker News Reader

I don't think this can ever happen.

If you don't back up very frequently, you're always vulnerable to having something recent taken.

If you do back up very frequently, you need to make some hard choices:

You need to connect to your backup media very frequently. But, you don't want any ransomware that may find you to also find your backup media; that would defeat the purpose of the backups.

Backing up a lot of data very frequently will end up requiring a lot of storage. If you erase old backups to save on storage, you're vulnerable to your latest backup turning out to contain only ransomware-encrypted data.

View on HN

Versioned / snapshot backups that you don't have full write access to (just append) prevents this. Even if all files are encrypted you'll maintain the previous version.

Do TimeMachine Backups fall under this? And if so, what would be the recommendation for Windows?

Windows Storage Spaces + File History. Two very, VERY good reasons to upgrade to Windows8 or higher.

File history to a NAS, with backups from the NAS.

> You need to connect to your backup media very frequently. But, you don't want any ransomware that may find you to also find your backup media; that would defeat the purpose of the backups.

If I was hit by ransomware and needed to restore from backup, I'd make damn sure to mount that backup drive readonly.

I think your parent is saying that if you are connecting to backup media frequently to make backups (in write mode, of course), then the ransomware has an opportunity to silently encrypt that too before you know you're infected, thus rendering your backups useles.

"Good enough" backups can include incremental backups, where changes are tracked at a sub-file level. You end up only actually backing up the parts of your computer that change (after an initial full backup of the system).

Everything but the requirement to have your backup media connected frequently is a long-solved problem in corporate-level software, we just need to start seeing it at the consumer level.

The ransomware could decide to re-backup some of your unchanged data, too, overwriting the non-encrypted backup.

I'm not talking about rsync'ing a bunch of files onto a NAS, I'm talking about an actual backup system. You'd just restore from the file revision immediately before the encrypted data.

Someone's point is that, when ransomware encrypts all your files, they have all changed (from the computer/backup system's point of view, not from the user point of view). With systems that do rolling incremental backups of changed files [until the backup volume is full and has to discard older versions], this will cause the oldest (pre-encrypted) files to be discarded far more quickly than during normal operations [and far more quickly than the user has become accustomed to].

That's not my point, but close to it.

The ransomware, while still in silent mode, will decrypt the data before the backup software sees it, so that the backup software doesn't see any changed data.

The ransomware could, however, know about a fixed set of backup programs, and, when it detects one is running, silently encrypt (parts of) backups of old data.

Things will get complicated for the ransomware, though. While in stealth mode, it must be smart enough to discriminate between files it encrypted and those that it didn't encrypt (yet). Otherwise, a test restore could fail. I would use an extended file attribute or a separate database (would be a single point of failure, but hey, it would not be _my_ data) for that, but from what I read here, lots of ransomware just encrypts everything in a target directory and then uses 'everything under directory foo is encrypted' (that should be done in a transaction, but ransomware writers wouldn't be too concerned about that)

> The ransomware could, however, know about a fixed set of backup programs, and, when it detects one is running, silently encrypt (parts of) backups of old data.

That assumes that the ransomware has direct access to the stored backup data, which seems like a flaw in the backup system that you're imagining.

I've got a particular backup system in mind, which I've been basing my assumptions on when I reply. It has a way to add a new backup, a way to retrieve any old backup that hasn't been expired yet, and a way to see if a piece of a file has been backed up in the past, but the server itself doesn't provide a way to remotely change past backup data directly.

Flooding the system with new data to push old backups out (as sokoloff mentioned) would be possible, assuming that the ransomware generated enough new backup data to fill up the backing storage, especially if it were scaled to give enough storage just for one or two computers.

That's a more believable attack than what most of the other posters have suggested. I suspect that the first step to fight that might be to store a value for the entropy of each backed-up file. A massive change in a file's entropy would be something to flag and require manual intervention on. Also, maybe some controls to limit the damage of a "push off the cliff by adding new data", like a way to set specific directories as "critical" to prevent the last copies of files in them from expiring.

I'm just playing with ideas =) The software I'm familiar with comes with hardware, generally scaled to keep a few months of nightly backups of a few hundred workstations and some fairly powerful rulesets for data expiration...so I've never really had to consider malicious backup expiration by ransomware. It's an interesting set of problems to consider.

Regular ZFS Snapshots taken through NAS4Free (served to my Windows box through CIFS)

Done and done. Additional storage is only taken if a file changes. You can always use a snapshot to revert to an earlier version of the filesystem (in the case of a malware attack).

Actual backups of the NASBox do happen of course, should the case fall over and all the hard-drives get scratched simultaneously.

If the ransomware encrypts all of your files, you will need 2x space to keep an old snapshot. If it repeatedly re-encrypts them, it could cause all of your unencrypted snapshots to expire.

An alarm or quota on disk IO volume could mitigate this.

Could this kind of attack be thwarted by keeping free disk space to a minimum - such as 15% free space? That way, the attack wouldn't have enough free disk space to happen. This would be difficult in systems with highly-dynamic storage needs, but could be done on application or caching servers.

No.

The attack happens on a file-by-file basis, within the free space that you have allocated on the live filesystem. foo.txt, bar.pdf, and baz.jpg are all encrypted in place, consuming only marginal free space during the operation.

Then, when the incremental backup happens, THAT will notice that ALL the non-OS files have changed and the backup consumption will explode.

Or paying attention to your NAS on a regular basis. Granted, this is my home network with only like 5 machines connected to it max. (My desktop, my laptop, my NAS, my home-theater PC, and my tablet).

Since the NAS is the center of my important data, I pay attention to it more.

-----------

A business solution would probably need an alarm of some kind, because a busy IT professional isn't going to have the time to baby a machine like I do.

Its just the whole "computers are cattle in professional IT settings" but are "pets for the home user".

I don't have to make any of those choices with Backblaze.

You do need a fast internet connection, and it's more expensive.

Backblaze is rubbish. I went to restore my files only two find half were there, even though the desktop client said it was fully backed up

Ransomeware finding the backups was the catalyst to the plot of Reamde by Neal Stephenson.

Tarsnap, Backblaze, et al.

Reply on news.ycombinator.com