Slashdot Mirror
Researchers Develop A Way To Stop Ransomware By Watching The Filesystem (phys.org)
An anonymous reader quotes a report from Phys.Org: Ransomware -- what hackers use to encrypt your computer files and demand money in exchange for freeing those contents -- is an exploding global problem with few solutions, but a team of University of Florida researchers says it has developed a way to stop it dead in its tracks. The answer, they say, lies not in keeping it out of a computer but rather in confronting it once it's there and, counterintuitively, actually letting it lock up a few files before clamping down on it. "Our system is more of an early-warning system. It doesn't prevent the ransomware from starting [...] it prevents the ransomware from completing its task [...] so you lose only a couple of pictures or a couple of documents rather than everything that's on your hard drive, and it relieves you of the burden of having to pay the ransom," said Nolen Scaife, a UF doctoral student and founding member of UF's Florida Institute for Cybersecurity Research. Scaife is part of the team that has come up with the ransomware solution, which it calls CryptoDrop. "Antivirus software is successful at stopping them when it recognizes ransomware malware, but therein lies the problem," reports Phys.Org. "'These attacks are tailored and unique every time they get installed on someone's system,' Scaife said. 'Antivirus is really good at stopping things it's seen before [...] That's where our solution is better than traditional anti-viruses. If something that's benign starts to behave maliciously, then what we can do is take action against that based on what we see is happening to your data. So we can stop, for example, all of your pictures from being encrypted.' The results, they said, were impressive. 'We ran our detector against several hundred ransomware samples that were live,' Scaife said, 'and in those case it detected 100 percent of those malware samples and it did so after only a median of 10 files were encrypted.'" The University of Florida uploaded a video briefly explaining its software.
The team isn't very explicit on what they're doing. But if they're doing it in a reasonable manner, it's probably not that naive, as to only look for "sequentially read, encrypt, write, delete" patterns. I think it's more fundamental. No matter what pattern it uses, a piece of ransomware has to fundamentally do the following.
1) Read the data. So, for each block that there's actual reads of, flag it.
2) Write data, somewhere, somehow. Can be to a disk, card, even over the net. Writes to disk might be to new files, archives, overwrites, etc. Even if compression is used, the writes have to be a relevant fraction of the size of the data read in.
3) Somehow invalidate the original block. There are different approaches one can use to invalidate data, and all of them need to be covered.
The key factors are #1 and #3. A process that just reads blocks isn't a problem. A process that just invalidates original blocks isn't a problem (that can't be ransomware, only deletion... and you can't get a ransom for files that are outright gone). But a process that reads and then later writes over blocks may or may not be a problem. We can divide this down into different scenarios.
1) Processes that only slowly, randomly, modify things that they've read, only on a limited number of files. These are most likely not a problem.
2) Processes that do read and write over a large amount of files, but always - in some recoverable form or another - keep an understandable copy of the file around (for example, writing the same file out elsewhere). These are not a problem.
3) Processes that modify vast numbers of things, without keeping a recoverable copy on hand. Particularly processes that do it quickly. Particularly processes that do it to files that aren't modified frequently. These are most likely a problem.
There is some level of nuance and heuristics involved here, of course. And another nuance is that this clearly has to be done at the system level, something dug into the operating system everywhere reads and writes are done. It probably needs to modify a number of pieces of system functionality as well to make sure that they don't do anything weird that might unintentionally trigger the heuristics. It might also be wise to break down the file system into monitored and unmonitored segments, where the unmonitored sections are where OS files, temp files, etc tend to be stored, while the monitored sections tend to be user files.
But the key issue is that - if they're doing this right - they're looking at the fundamental things that ransomware has to do - in particular, reading data blocks, then trying to leave then unrecoverable at some point afterward. The protection software should not interfere when a program reads, but when it tries to invalidate things that it's read - in a manner that triggers the "this is excessive, strange, suspicious behavior" heuristics - then it suspends the application. Because, say, the overwrite behavior of a person using MS Word or Photoshop doesn't look at all like when ransomware does it - no matter what "pattern" they use for their encoding. They could mimic the overwrite behavior of programs like that to avoid the heuristic.... but then it'll take them weeks, months, or even years to get through all of the files on a person's computer, and they'll get caught long before that.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
The real solution, of course, is a proper versioning filesystem with a regularly scheduled snapshot - say, once a week, or once a day if you're extra paranoid. You can even cycle the snapshots if you want to cut disk usage down.
Never underestimate the stupidity inherent in all human beings.
ok, 2 years ago (when i first heard about ransomware) i wrote a nagios plugin that through inotify watched for activity on dummy files automatically placed around my directory trees. with that, nagios also watched for out of hours IO load. it had watched for processes hogging io/cpu during the day, i just made it more sensitive at night. plus, i have hourly filesystem snapshots.
i then tested it with whatever trojan came in my email on a windows7 pc with a samba volume mounted. it detected it straight away.
this really is a ms windows only problem. any bsd/linux admin has so many tools of protection available that it's virtually a non-issue for us.