Massachusetts Steamship Authority hit by ransomware attack; ferries delayed

Many (if not most) companies have file shares with fairly wide-open access and/or a complete lack of backups so peer-to-peer spreading within the company is enough to cause a lot of trouble.

At its root these are technological problems that we could choose to solve:

1. The program is not the user. Code running as a user shouldn't necessarily have permission to access everything the user can access. 2. New code is not treated with suspicion when it should be. New code should have its file access throttled in proportion to how many files it accesses. 3. Our systems do a terrible job of spotting unusual behavior. How many processes actually need to rewrite every file the user has access to? Almost none... rewriting 10% of the user's files should trigger an automatic throttle/stop and raise red flags. 4. As a variation on #3, most OSes these days ship parsers for a lot of common file formats... if the OS sees lots of user documents being rewritten and the parsers can no longer parse them stop allowing new rewrites and alert the user. If the user is encrypting their content on purpose they can approve it. If not you can at least limit the damage. 5. Similarly a network user that usually accesses a limited set of files should not be able to suddenly start rewriting thousands of files without some kind of intervention. 6. Our systems completely fail to take advantage of ancient technology called "file versions" (see VMS). Excess disk space should store old versions of files in a way that cannot be deleted (or the ransomware would just call that API or generate random writes to consume the space). Combine with 2/3: when there is suspicious activity on the system move into CoW mode and preserve previous versions of all files or an entire system snapshot and don't allow purging the snapshot without special intervention (eg rebooting into a special mode). 7. To go along with all of the above code should be tagged with its provenance in a system-tracked way. If a process writes a new binary to disk track that responsibility. Track it all the way back to the URL or email it came from. This entire audit trail should be attached to any of the mechanisms listed above. It should also be attached to any sort of activity monitoring program that shows you disk accesses, including historical accesses. If I see 50GB of disk reads/writes from a process group "JGjthjsfgl.exe, downloaded from p0wnme.example.farts" that is a huge red flag. Let me suspend that entire process group with a single click.

I'm sure smarter people could come up with even better ideas... but ransomware is absolutely something we can and should make nearly impossible. We could engineer operating systems to be resilient and limit the damage (eg: macOS prompting you to approve access to Desktop/Documents/Downloads) but it means giving up some sacred beliefs about how desktop operating systems should work that tends to make a subset of the HN audience extremely angry.

I am inferring (perhaps incorrectly) that you're saying this is an argument against cryptocurrencies. I think that's beside the the point: even outright outlawing cryptocurrencies wouldn't stop the technology from existing, and wouldn't discourage extortionists from using it to anonymously receive payments.

It would make it harder to pay, since you'd have to go outside of safe, legal channels to get money into the system.

If the best strategy when being extorted is to never pay or negotiate, then I suppose that could be a benefit. But, in that case it would be more efficient to just make it illegal to cooperate with extortion in the first place.

For all I know, this is already true. If not, let's try that first. If it is, it doesn't seem to matter, since people are paying ransomware hackers. Still, if paying at all is illegal, but people still do it, then making paying less convenient probably won't make much of a difference: they'll still ask for payment in crypto, and leave the logistics up to the victim.