A boutique Swiss security outfit recently wrote about a sneaky new sort of ransomware.
It’s an intriguing story.
The crooks, it seems, decided to take it out on company X by means of extortion: encrypt customer data, and then offer the decryption key for a price.
There are several unsubtle way to do this, such as:
- Hack into the network, shut down the network facing part of the webservers, scramble everything you can find, and make your demand.
- Compromise the webservers with an exploit kit, foist ransomware on everyone who logs in, and extort money piecemeal from every customer.
- Foist ransomware on everyone who logs in, and tell them to get the company to pay.
And so on: you can probably think of your own ways in which crooks could attack (and thinking of them is not some kind of “security sin” – understanding your enemy helps you predict and prevent possible problems).
In this case, however, the crooks took a surprisingly low-key, annoyingly simple, and hard-to-spot approach.
Take over the login database
X was using phpBB for its online customer forum.
So the crooks broke in and hacked the PHP code that dealt with the user database.
Basically, the database engine itself was slightly modified so that user login data was scrambled with a key held by the crooks when it was saved, but quietly decrypted when it was read out.
On the surface, everything was hunky-dory, but the raw data underneath was shredded cabbage.
The key was never actually stored on the hacked server, but was instead fetched into memory at startup time from a dodgy remote server operated by the crooks:
Come the day, apparently after about two months, and the crooks removed the decryption key from their dodgy server.
So, even though the vast majority of the forum data was intact, and accessible, and archivable, and online…
…customers couldn’t log in, because their usernames had suddenly changed from JIMMY to FKOVWH3Z7LUV.
Worse, of course, their password hashes were scrambled too.
So who knows what password could possibly produce the required hash and unlock each account?
So customers started calling up to say, “We can’t log in.”
Recovery, first attempt
Oh no!
What to do?
You recover from a backup, of course.
Except that your backups for the past two months include shredded-cabbage login data.
What next?
Recovery, second attempt
One thing you could do, but it wouldn’t be an exercise to be undertaken lightly, would be to trawl laboriously through all your databases, either automatically, manually, or using a bit of both, and work out what users had been transformed into which weird names.
Then you could reset their passwords, and email them with their new, unusual, usernames as a temporary measure.
It would be ugly, but it would work.
Oh no!
The crooks scrambled usernames, passwords, and email addresses.
So even if you can fix JIMMY‘s account, you can only let him know by emailing him by emailing someone called RDoj2PM4 AT yivLUZ6aabF DOT GzO3.
Recovery, third attempt
Guess what happens next?
A message arrives.
Would you like to buy the decryption key?
There’s no indication of how much the crooks in this case asked for, or whether X eventually paid up (the impression given is that the company did not).
But it’s an interesting reminder of how security on your server is as much about your customers and your reputation as it is about your server.
It’s also a reminder of how, even when the bulk of your database records look fine, crooks could have put a customer-facing spanner right in the works.
NB. Although this particular attack seems like a one-off, Sophos products detect the PHP components used to initiate this compromise as Troj/PHPRansm-A, and block connections to the crooks’ key server. Just in case.
