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.
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.
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. :)
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?
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....
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.
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
Maybe they didn't think it that far through?