Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of Phobos – How we almost cracked a ransomware using CUDA

cert.pl

Post reply on HN
Print view View original

31–40 of 65 posts

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#31

Post by bauruine »

degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

I use borgbackup to a server and once a month upload it to backblaze b2 with a 90 day retention policy on the bucket. The policy doesn't let you modify or delete the files for 90 days even if you have access to the account. Costs something like 5$ for the 3x500GB of backups I have.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#32

Post by GordonS »

degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

> when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files?

Maybe you could check the level of entropy (measure of randomness) of files before backing up - very high entropy could suggest encrypted data?

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#33

Post by TacticalCoder »

jxramos wrote: post #29
TacticalCoder wrote: post #27

Earlier quoted context omitted.

I agree. And for some stuff you get cryptographic checksums for free. Backup of Git repositiories: ... # git fsck --full error: unable to unpack contents of .git/objects/a2/cf1a9631658799733f43c3b3f0a799696a4b21 error: a2cf1a9631658799733f43c3b3f0a799696a4b21: object corrupt or missing: .git/objects/a2/cf1a9631658799733f43c3b3f0a799696a4b21 Oops... No matter if it's a malware, the lack of ECC which by bad luck induce…

what do you mean adding checksum to the picture, do you add the checksum as a filename suffix eg IMG0001_ .jpg, something like that? Or do you tuck it into the exif data and have a tool that computes the checksum of the file minus the checksum part.

Yup exactly just adding a suffix. I'm not only backing .jpg files. For example I also backup a few screenshots (some are in .png and some are in .webp format).

So I don't care about the different pictures (or short family movies) format.

I just wrote some Clojure / babashka code to do that. I also truncate the checksum so that the filename doesn't become gigantic: it's not sensitive content, it's just to detect corruption.

Then I can use another computer and generate, say, all the thumbnails of the pictures and do a quick eyeball verification. If it looks correct, later on I can just automatically have the checksums verified.

Funnily enough I got a few old JPG pictures who were corrupt but I ended finding the correct version on older backups.

Checksum then helps too: otherwise you have two files with the same name (say on different HDD), but only one is correct and you don't know which one without manually opening them.

It's not super advanced and maybe a bit overkill but it's not complicated and works fine for my use case.

P.S: I take it another way would be to use a fs that use content-based addressing or does checksumming for me.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#34

Post by KMag »

GordonS wrote: post #32
degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

> when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? Maybe you could check the level of entropy (measure of randomness) of files before backing up - very high entropy could suggest encrypted data?

This is good. Some antivirus programs run this check, but some ransomware adapted by encrypting 16-byte AES blocks every so often in the file, so that the file becomes useless without entropy increasing too much.

Also, JPEG, PNG, .jar, .xlsx, etc. are already compressed, so pretty high entropy to begin with.

As others have pointed out, the growth rate of your de-duplicated backup size is probably the best way to detect ransomware.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#35

Post by bobleeswagger »

xwdv wrote: post #14
comboy wrote: post #12

I know I'm in minority and that this view is not empathetic one, but I really like that ransomware is around. More secure data storage at companies where otherwise it would be just silently stolen and sold. More backups. Even some incentive to research security of encryption methods. We won't get more secure systems without some proper incentives.

I love that ransomware is around because it forces companies to take security seriously or pay the price. You could even say ransomers are the good guys in this regard, contributing to a safer world.

Robber barons have always shaped the world in mysterious ways that history does not fully grasp.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#36

Post by proactivesvcs »

degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

I use restic which has very flexible retention policies. Rather than retain simply "x days", one can have it "keep the last x hourlies" all the way up to "keep the last x annuals", and XOR many criteria in one policy. Since it uses snapshotting, compression and deduplication it's very storage-efficient. They also offer a simple REST server which allows one to backup with append-only permissions, which can alleviate a ransomware attack.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#37

Post by temp2022account »

fps_doug wrote: post #23
degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

Don't do simple rolling backups, use something with deduplication like borg backup or ZFS/btrfs if you want to do it at the FS level. The backup size should not increase by much more than the actual size of any new files, so if suddenly, you need twice as much backup space because all your files seem to have changed, you should get suspicious.

Seconded, I have an external 2tb HDD that stores 1 years worth of daily backups from my 256gb (~180gb used at any time) laptop hard drive. My backup script (https://gist.github.com/Jeffrey-P-McAteer/7d4b9052825914b5e0...) takes maybe 30 minutes for a full backup, 5 minutes for most deltas. Files which are the same get hard-linked to the previous days backups, new files are copied over and content-de-duped by btrfs.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#38

Post by powersnail »

degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

I use rsync manually, and always with "--dry-run" first. Unless the ransome-ware is smart enough to rot my backup very, very, very slowly, I should be able to detect any problem by simply reading which files are to be overwritten. 99.99% of the files I back up rarely change.

I also have most of my non-sensitive data on Onedrive, which keeps old versions of files.

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#39

Post by zht »

comboy wrote: post #12

I know I'm in minority and that this view is not empathetic one, but I really like that ransomware is around. More secure data storage at companies where otherwise it would be just silently stolen and sold. More backups. Even some incentive to research security of encryption methods. We won't get more secure systems without some proper incentives.

This is like saying it’s a good thing that burglars exist so it forces us to invest in stronger locks/doors

Re: A tale of Phobos – How we almost cracked a ransomware using CUDA

#40

Post by 0cf8612b2e1e »

ridgered4 wrote: post #16
degenerate wrote: post #5

Nearly all my personal photos were encrypted by the helprecover@foxmail.com ("HELP") variant of Phobos. I've been holding onto the encrypted copies for a while in hopes that some people were working on a crack, and I'm excited to read this update. Sidecar question: when automating your backups, what's a good way to make sure your rolling backups aren't simply backing up malware-encrypted files? I found out too late t…

One technique would be to place unchanging bait files that you pre-check before allowing the backup to proceed.

That’s a nifty and cheap idea. Now I am wondering if I should make the standard juicy targets (eg ~/Documents, .config, .ssh) complete decoys and put all of my real data just off to the side. Could still be hit by a generic attack, but targeted data extraction attempts would initially fail.
Post reply on HN