Snapshot time question (possible attack)

Getting Help
1

Imagine a restic setup as follows:

  • Clients backup to central server running with restic rest server or rclone rest server with append only
  • Central server forgets/prunes backups of all repositories at time x by accessing backup data using separate server key as clients can’t prune themselves. Let’s say the forget policy keeps some amount of daily, weekly, yearly snapshots, etc.

Imagine a ransom ware attack where the attacker encrypts the client’s hard drive. While the client can’t delete his own backups (as server runs with append only), he can backup as many times as he wants. The ransom ware deletes client’s backup data by first encrypting drive then by making many snapshots with future dates (by changing system time) and a lot of them.

Now the attacker waits until time x when prune policy is executed by server and all the client’s legitimate backup data is lost/overwritten by bad snapshots of the encrypted drive. This is because the bad snapshots all have futuristic times and the prune policy will only keep recent snapshots.

Anyone have suggestions on stopping this?

Edit this attack is even easier if the forget policy keeps only the last 100 snapshots or so. Then the attacker makes this many bad ones to clear out legitimate data

2

It would be nice if the restic backend was the one who stored snapshot time that way the attacker needs to get control of the server. But I don’t think this is the current implementation.

3

Possible solution: Server compares local time to all snapshots in a repository. If it finds one that is too far in future, it doesn’t apply prune policy as safety precaution.

4

I raised a similar point on Github. AFAIK, the only reasonable solution is to audit the set of existing snapshots before doing any forgetting. restic snapshots --json outputs a JSON array suitable for automated processing, which could be used to populate a database. Comparing the list of snapshots in the repo against the database and ensuring that everything is sane is the only approach I can think of to resolve this.

This is, quite simply, not even possible. The backend is usually something like a directory or S3 or B2, and there’s no logic in those kinds of “dumb” services to accomplish this. This could only be enforced when the REST server is the backup target.

5

Ransomware attacks are automated in most cases. You are assuming that the attacker has knowledge that the client ist using restic as backup software and that the attacker knows how restic works. You further assume that the user does not recognize that the clients data is encrypted until the server starts its pruning job. While all of this is generally possible I’d say that this is unlikely to happen.

If your data is that important to you, you should consider a few things:

  • don’t prune automatically
  • don’t prune too often
  • verify the backups before pruning
  • use another backup software and have a 2nd backup set
2 Likes