New Ransomware tactic: First check backups and infrastructure, then encrypt

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
I was just reading an article about a new type of Ransomware called Samsa

- after infection it scans your whole it infrastructure and for backup procedures
and distributes itself over the network without any noticeable action

after some time when it knows your files, disks, storage and backup procedures,
It can happen, that it first encrypts all backups ( may wait until all backups are encrypted !!)
without any other actions.

it starts then encryption simultatiously on all systems
it deletes shadow copies (when using Windows)

So it can happen, that
- all files on many systems are encrypted one morning
- Windows snaps/ shadow copies are deleted
- backup is encrypted even on multiple rotating backup medias


The question is now, is a remote ZFS storage safe against such attacks
- current data: can be encrypted as long as you have permissions : not safe
- ZFS snaps are safe as they are readonly and cannot be deleted by a client admin user
as you need local root access on the storage system
 
  • Like
Reactions: lmk and Patrick

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
This is actually one of the reasons I am a big fan of zfs snapshots and zfs send/ receive.
 

cesmith9999

Well-Known Member
Mar 26, 2013
1,417
468
83
This is where you need offline backups. and a restore verification procedure.



Chris
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
The solution is readonly versioning that cannot be attacked.
Offline backup is a good idea in general but not if you have a lot of data that changes frequently as in such a case bandwith
and backupwindows is a problem.

A ZFS filer with frequent readonly snaps on active data can be the first wall against dataloss as you can create as many snaps as you need
without a delay on creation and without an initial space consumption. This also includes open files with their current on disk state.
Without console root access example via SSH, these snaps are safe.

You can pair with remote replication where you transfer these snaps to a remote location as a data stream based on a snap.
 

unwind-protect

Active Member
Mar 7, 2016
415
156
43
Boston
I have seriously thought about hacking up the FreeBSD kernel to disallow deleting snapshots. This would guard against myself fscking up, and against attacks like that. Of course they could still opt to delete the entire ZFS, but if they want to include it in randoming, then simply encrypting on top of the unencrypted snapshots would just blow up the filesystem (not enough space to copy-on-write everything).

I also made a now successful effort to in addition to the ZFS backup server also have a number of large USB drives that I also carry off-site. That is a coincidence since I bought 5 of those external 5 TB Toshiba drives and took the drives out. The enclosure with USB interface, which looks high quality to me, is now available to drag around random old drives. And any of my laptops can fill it, I don't have to do the SATA frame thing anymore.
 

unwind-protect

Active Member
Mar 7, 2016
415
156
43
Boston
What is the status on reasonable tape backup, anyway?

Let's say the cost for the non-consumables comparable to a 5-disk sata array, and capacity at least enough to only need 2 tapes. So that would be a 10-20 TB tape.
 

cesmith9999

Well-Known Member
Mar 26, 2013
1,417
468
83
Depends on our backup needs. an LTO-6 library (120TB native 300TB compressed) from HP costs over $6k without the LTO-6 drives (~ $5K each).

then there is the cost of tapes... at $37 each...

that makes looking at making cold archive servers look cheap.

Chris
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Short interval and safe read only versioning is the answer to these attacks
but tapes are way too slow and handling is bad with medium to large arrays.
 

TeeJayHoward

Active Member
Feb 12, 2013
376
112
43
I've often wondered if my ZFS snapshots were enough to protect me from ransomware. I'm really a big fan of how easy it is to set up an automated 30-day rotating backup in ZFS. 3 lines in crontab are all it takes:

Code:
1  1 * * * /usr/bin/rsync -av --delete /pool/ /backup/ 2>> /var/log/rsync.errors
1  0 * * * /usr/sbin/zfs snapshot -r backup@`date +\%Y-\%m-\%d` 2>> /var/log/zfs.snapshot
0  2 * * * /usr/sbin/zfs destroy -r backup@`date -d -30days +\%Y-\%m-\%d` 2>> /var/log/zfs.destroy
 

unwind-protect

Active Member
Mar 7, 2016
415
156
43
Boston
Snapshots have the same problem.

If your primary computer can create the snapshots, whether the snapshots are on the primary or a backup computer, then the primary computer has been given enough access to also destroy them. In my case the key question is whether the ssh agent around the rsync has the required ssh key. I could only add it around the actual backup but smart malware is likely to sit around and wait for you to do the backup. If they don't they wouldn't know what your backup is in the first place.

You could solve this particular one by pushing backups to a server via NFS and the server is snapshotting. The primary computer cannot access system operations on the backup computer. But then you lose that neatly ordered rsync-snapshot pingpong. Your snapshots are out of sync unless you overthink it more. Plus NFS kinda sucks, especially if you want to have that one encrypted. rsync over ssh is conveniently encrypted and volume-minimized.

You could have the backup server pull, but now you have keys floating around the backup computer to have all-access to the primary computer. Meh.

I'm going to the pond photographing some herons and beavers now. This gives me a headache.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
At the moment Ransomware targets mainly to Windows systems as a victim and SMB shares as storage including administrative shares like c$ with a upcoming risk to OSX. Linux/Unix/NFS/SSH is not affected as the marketshare is way too low to be attractive (beside using it as an SMB filer with same risks as Windows shares).

Of course you can think of a mechanism ex via SSH as root to destroy snaps on a shared ZFS SMB storage/ filer but as this is a very random setup, requires extra knowledge and it is easier to avoid these attacks compared to the Windows/SMB risks this seems not very likely. Regular ZFS snaps is therefor a quite secure and very easy way of a base protection, paired with any sort of offline disaster backups
 

unwind-protect

Active Member
Mar 7, 2016
415
156
43
Boston
Well, still, it is a concern.

Personally I am also bothered that I have to be root to backup (via rsync) a filesystem into another filesystem. It should be sufficient to have read permissions on the source side, and on the target side your userid should be allowed to create files of arbitrary ownership, inside that filesystem (you can then have mount options that disable setuid bits etc).

If I use tar as the target the problem doesn't apply. I can have a backup encoding all original ownership without having to be able to be that owner before restore.