RansomWeb: Crooks Start Encrypting Websites and Demanding Thousands of Dollars | Hacker News Reader

RansomWeb: Crooks Start Encrypting Websites and Demanding Thousands of Dollars

forbes.com

20 pointsxyby11 comments

I'm surprised they didn't just use openssl_seal() with a public key, instead of risking the decryption key being forensically recoverable by the victims.

Maybe they didn't think it that far through?

They needed the decryption key to be available to the web application because they had modified it to silently decrypt the data coming back from the db so that no one would catch on to their ruse until they'd encrypted enough data to be damaging.

Never heard of openssl_seal() until now -from my brief read am I right in thinking it's a similar workflow to PGP?

Yeah, similar in concept. You encrypt a message with a public key and can only decrypt it with the private key. It's great for storing data so that a root/filesystem compromise won't reveal any of the previously encrypted data.

I'm hoping that jedisct1 will add a parallel functionality to libsodium soon. :)

https://github.com/jedisct1/libsodium/issues/231

Parallelism is always a good thing.

The specific similarity with PGP that jumped to mind is that you're not actually using your key (or recipients key) to encrypt the message. You're actually generating a random session key to encrypt the message contents and then you're encrypting the session key against the recipients key and sending them that.

I was really taken by surprise the first time I read that, but after playing some more with crypto "obviously" you'd have to -otherwise what happens when your message is longer than your key?

Seriously?

How the heck does this happen to a real company, supposedly with a disaster recovery plan?

Seems like the obvious fix is blow away / reformat the compromised server, reload web application source code (backed up on another box, right?), reload application data (backed up on another box, right?) and away we go....

For a financial company???? <sadness>

The article explains that the site had been compromised for 6 months, and during that time all the data being stored was being encrypted and then silently decrypted.

So, restoring from a backup wouldn't get you much of anywhere, since the backed-up data would still be encrypted. Even assuming your backups are separate and uncompromised, you'd still have to go back to before the original compromise and lose 6 months worth of data.

How can you not detect something like that for 6 months... A simple audit should have caught this early on.

Yes. There was a time when people actually tested the backups.

Did they not make regular backups of their production environment? Surely one of them would have the encryption key in the source code.

I was just re-reading about the Drupal super-vulnerability of Oct 2014. This could be some of the fruit. That was an enormous vulnerability that might have compromised 100,000's if not millions of servers

Reply on news.ycombinator.com