Hugh Pickens writes:
Alina Simone writes in the NYT that her mother received a ransom note on the Tuesday before Thanksgiving.“Your files are encrypted,” it announced. “To get the key to decrypt files you have to pay 500 USD.” If she failed to pay within a week, the price would go up to $1,000. After that, her decryption key would be destroyed and any chance of accessing the 5,726 files on her PC — all of her data would be lost forever. "By the time my mom called to ask for my help, it was already Day 6 and the clock was ticking," writes Simone. "My father had already spent all week trying to convince her that losing six months of files wasn’t the end of the world (she had last backed up her computer in May). It was pointless to argue with her. She had thought through all of her options; she wanted to pay." Simone found that it appears to be technologically impossible for anyone to decrypt your files once CryptoWall 2.0 has locked them and so she eventually helped her mother through the process of making a cash deposit to the Bitcoin “wallet” provided by her ransomers and she was able to decrypt her files. “From what we can tell, they almost always honor what they say because they want word to get around that they’re trustworthy criminals who’ll give you your files back," says Chester Wisniewski.
The peddlers of ransomware are clearly businesspeople who have skillfully tested the market with prices as low as $100 and as high as $800,000, which the city of Detroit refused to pay. They are appropriating all the tools of e-commerce and their operations are part of “a very mature, well-oiled capitalist machine" says Wisniewski. “I think they like the idea they don’t have to pretend they’re not criminals. By using the fact that they’re criminals to scare you, it’s just a lot easier on them.”
Not really. The best solution is to have data in more than one place, at one time, and with different versions when you can't entirely trust your computing environment. Online backup can remember different versions. This was 7 days from the notice, and I've set up 30 days for individual files as a policy before. I don't think the encryption can be any more damaging than a disgruntled employee, so you can easily get your data back even if heavily modified data is sent repeatedly during those 7 days. Took me 3 minutes to restore all of the employee's data, profile, emails, etc. along with what they deleted off the shared folders.
Of course there's an associated cost with this, but you do get the benefit of cross platform backups and zero knowledge storage. In order to prevent hijacking of the backup software possessing the encryption keys, I run that externally as another server accessing my data over the network. Although typically, anything really important and sensitive is stored on NAS and not on local storage in the first place.
Overall, I think moving towards well protected journaling file systems (the online backup is just ZFS with a custom manager) that are possibly set up at the hardware level to only record changes will be the only way to do it. This way attackers are just simply unable to prevent access to older copies. Once we get there it's not all that much to add some logic and firewall rules preventing any number of changes over X files with an average timestamp delta of Y coming from domain Z without escalating privileges. We've had these abilities with database platforms for some time, and it seems like it would be appropriate to apply some of that knowledge when we can't really trust our systems anymore. If that much data is going to be changed, is it not appropriate to raise a modal dialog box (like UAC) and ask the user to commit the changes? You screw up on a well implemented and maintained database you can just go back through transaction logs and rebuild to the last known point with no corruption. No extortion required, just competent IT.
It may come down to just how much effort we really want to spend to store and work with data. We could take a page from Intel and start creating true multicore systems with shared distributed memory where we get to compile and install our own binaries into them directly. I imagine something like USB storage on the board, and to provision your system you physically add your encryption keys to one module, memory core to another, file system to another, etc. Under normal conditions an attacker could never hope to control your data since they might wait months or a year before somebody swapped out the storage firmware. Let's finally separate out all the components of a system (probably sacrificing some performance) and have them run physically isolated with their own kernels and memory, but able to modify shared resources. You could even create the whole thing like a key that needs to be inserted into the motherboard to load your OS, and modifying your key requires loading a special OS from the key (physical switch) solely designed for updates from authenticated repositories and adding code modifications with it's built-in IDE. I would like to see storage abstracted away into a suped up secure version of iSCSI targets with the codebase and processes running it completely inaccessible to the module accessing it. Right now, the same processor is running the iSCSI drivers that is running userspace.
We could try it all virtually, but there are known weaknesses where encryption keys can be weakened in one guest OS from another guest OS through side channel attacks against the host. I'm not convinced this will ultimately be as secure as a system with modular bare metal security, or that such bare metal security is not well suited for it's own virtualization environments that have truly separated resources.
The protection needs to be at filesystem level not block level to be really useful. Or you need to restore the whole filesystem image.
How is these binaries supposed to be installed "directly" ..?
Compartmentalized system could perhaps work with existing systems that have multi-core CPUs and use IPC ..? Or some proven microkernel. Because one needs to lock down hardware like harddisk and network to a specific core which could be corrupted at boot (or by spy-bios).