Hacker News new | ask | show | jobs
by some_developer 1306 days ago
Last year I also learned that ransomware attackers are not computer gods, necessarily.

My QNAP NAS was open to the internet (a forgotten but-not-in-use port forward on my router) and the famous QLocker ransomware got hold of it.

I got out, I got really lucky. I've millions of files (useless to anyone in the world but me) on my NAS and the ransomware encryption took literally days. I probably discovered it on the 3rd day of its activity.

Someone brighter than me already figured things out and posted this on the qnap forums, that there's a 7zip process running which encrypts the files and they process all files sequentially (aka: takes a long time in my case). This 7zip process gets executed for every file and gets passed the password for it on the command line, though in the process view it was masked for me. But I could just replace the invoked 7zip binary with a shell script and redirect all the arguments -> presto, I had the password.

I then wrote some more shell scripts to decrypt all the files infected so far, wrote it more efficient than the attacker, and within 24 hours everything was back to normal.

Before anyone cries "BACKUPS": yes, of course I've off-site backup and they also were not (yet) affected. But actually I only backed up the real important data for me and my family, due to the costs at that time, I didn't backup _everything_. But I since switched cloud backup storage to Backblaze which I figured was the cheapest vs. acceptable ergonomics for recovery, so I could increase the amount of data I back up.

Lesson learned, I guess. I know not everyone can help themselves like I could, I feel really lucky I got away with just some blood sweating.

1 comments

Interesting. So you're saying that the ransonware uses symmetric encryption, i.e. the same key is used to encrypt and decrypt.

I always assumed it used asymmetric encryption, and that the decryption key would never hit the victim's premises.

Definitely not computer gods.

I think asymmetric encryption is not usable for large amount of data, the only thing it is good for is to encrypt a passphrase or a binary signature (like a hash). If you can catch the process of encryption while it is running, it is likely that the passphrase is in memory (or used as a command line argument).
That's why you create a lengthy random key (that you know it cant be brute forced) and encrypt everything using it and symmetric encryption.

Than you store that random key encrypted with asymmetric algorithm.

Same goes for things like disk encryption. You never use the users key for encrypting the data. You always encrypt using random large key that is not brute-forcable and encrypt that one with user password, so the process of changing the user password is just decrypting the random key and encrypting it back with new password. Or you would have to re-encrypt the whole disk on password change

Shh, don't give them any ideas!
If you have read anything at all about encryption written since 1997 (probably before, that is when I first started reading) you already knew that.
If.

Most ransomware authors, I'd wager, have not been reading since before 1997.

Advanced ransomware use a hybrid scheme that generates a new symmetric key for each file and then encrypts that with an asymmetric key.
gpg supports using public / private keypairs to encrypt any amount of data you like. I use it for uni-directional backups from machines where trust is an issue.

Or is the reality of this that it's just encrypting a symmetric key with the asymmetric cipher, and then encrypting data using that key?

Everything is encrypted with a symmetric key. It is just that sometimes there is an asymmetrically encrypted symmetric key packet included in the message so that GPG (or whatever) does not have to ask you for the symmetric key. This is all fairly generic, if you actually have the symmetric key you can use it directly even if a key packet exists. This means that you can give some entity a key to decrypt a particular message/file without revealing your asymmetric secret key associated with your identity.