Researchers Develop A Way To Stop Ransomware By Watching The Filesystem (phys.org) 102
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.
Re: (Score:2)
Why would I use truecrypt on a mac? The mac already has FDE built in, courtesy of FileVault.
Re: (Score:3)
Did you happen to find a sale on asterisks or something?
Re: (Score:2)
You should be using VeraCrypt since TrueCrypt is outdated.
Re: (Score:1)
PGP + Truecrypt + Tor
Snowden endorsed.
Good enough for me.
Hey, you can do this too (Score:5, Interesting)
1. Your main computer (call it 'right brain') automatically takes a 'VM snapshot' of itself at a point in time.
2. Another computer ('left brain') inspects the VM to check if data files are still accessible
3. If not, left brain 'diffs' the VM with previous 'known-good' VMs to find the source of the problem
4. Swap VMs
5. profit!
Re: (Score:2)
What would really help (Score:2, Interesting)
...is if a few of these ransomware authors/operators started turning up dead.
Seriously.
Re: (Score:2)
...is if a few of these ransomware authors/operators started turning up dead.
I've been pushing for this solution for some time now.
Re:Hey, you can do this too (Score:4, Informative)
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.
Re: (Score:1)
Care to share the source? Maybe a github repo or tarball on dropbox or something? I would like to use something like that, but I'm not much of a programmer.
Re: (Score:1)
Editorial skills (Score:2)
Re: (Score:2)
Nah, typical of a UF edumakashen
But hey, at least they have Burrito Brothers close by...
Heuristics (Score:5, Interesting)
That's called "heuristics" and AV has been doing that for quite a while now. And attackers will work around this system the same way they work around heuristics... if your system is freely available, they can download and test their ransomware against it until they can escape notice.
Re: (Score:1)
Re: (Score:1)
Omg. Amazing indeed.
On the same note, if I had mod points right now, I would mod you both down for being clueless, while thinking you are the opposite.
No, your kneejerk reaction that this will be easily defeated just like everything else is unfounded. You haven't read the paper. You haven't thought it through.
Try harder.
Re:Meh (Score:4)
Nice try, but with 3 potential problems (Score:4, Insightful)
The software detects the behavior of an application. The detection is probably like 'if a process accesses each image file (OpenFile/CreateFile) , read it, create a new file with "same_name+.encrypted", then delete the original image file.' x 10 times, then that process is likely guilty.
1. What happens if the malware instead use MapFileView and 10 others potential Win32/kernel32 APIs combination? This quickly become a arms race and is going to be terrible in terms of system overhead, not to mention the time gap between a new method appearing and the detection software catching it.
2. What about Windows' internal processes that, for example, shadow copy the file? Would the detection software catches it? What about false detection of, say, the disk defragmentation software?
3. Since the system is already compromised, what stops the malware from detecting the countermeasure and just delete all the files in the system straight out? If that's too obvious, then how about write a random byte per x bytes offset to all files? Even if you killed the malware process, you can't be sure that there no other malware running on the system that can go into revenge mode.
Re: (Score:1)
Actually, there is a much easier way to defeat this in a wholesale way. They track each process across three indicators (they describe them in their paper). These indicators include an entropy metric and a similarity score (comparing two versions of the same file -- ransomware encrypted file of a previously unencrypted file should look much different). For more details, see the paper. The main issue is that it is per process, so an attacker could simply use multiple processes to achieve an end-goal of extra
Re: (Score:3)
I hope if I run an application to convert a bunch of music files from one format to another then their program isn't going to be set off.
Re: Nice try, but with 3 potential problems (Score:1)
Reencoding music should get your door kicked down and send you to federal pound me in the ass prison.
Re: (Score:1)
Agree with Anon, re-encoding music is a very nasty thing to do, every different encoder adds different artifacts, encoding sound with more than one lossy encoder will hugely decrease the quality of the sound.
Re: (Score:2)
Well since I'm not going to put FLACs on my iPhone I'm going to have to convert them to something else that will work better on it (and not take up as much space even if I got something that would play them).
Re: (Score:2)
Fair enough with FLACs because they are losslessly encoded so you're not going from lossyA to LossyB, I should have made it clearer that lossy to lossy is not nice and risks introducing ugly audio artifacts into the music.
Re:Nice try, but with 3 potential problems (Score:5, Informative)
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.
Re: Nice try, but with 3 potential problems (Score:1)
Shit (Score:1)
See subject
Better yet (Score:2)
Just have your files backed up on another computer at your house, on a NAS, or online. If you get ransomware then just nuke the computer and restore everything from your backup. Though if you were to combine both the backup and this then you probably wouldn't lose anything as the few modified files between backups aren't likely to be the ones to be encrypted.
I wouldn't suggest backing up to a hard drive connected directly to the computer because the ransomware will also encrypt those files too.
Re: (Score:2)
Bingo. NAS offerings are relatively cheap. Both Synology and QNAP offer both snapshot functionality (useful because someone can cd into the snapshot directory to get their pre-fucked files), as well as backups to external drives, other NAS offerings, or the cloud (encrypted on the client, of course.)
Then, add a decent backup program like Veeam for Windows which has the ability to mount a share only when it is using it, to narrow down the window that ransomware can trash it, and this not just functions as
Re: (Score:2)
Problem is, if you ask a lot of companies why they don't bother with backups or security, you will get an answer along the lines of "security has no ROI", "nobody has made a cent from padlocks except the padlock maker", or something along those lines.
Then they get stung, and what happens is that some worker bee gets blamed for everything, shitcanned, some "security measure" is taken like forcing all AD users to change their password, and life goes on.
Re:Better yet (Score:4, Interesting)
Just have your files backed up on another computer at your house, on a NAS, or online.
Bingo.
If you get ransomware then just nuke the computer and restore everything from your backup.
double bingo.
I wouldn't suggest backing up to a hard drive connected directly to the computer because the ransomware will also encrypt those files too.
Yes... but that's not nearly going far enough. The vast majority of 'simple' backup systems fail hard on ransomware; especially the roll-your-own sort often advocated here.
cloud sync, torrent sync, etc. Fail. So you've got 3 redundant storage sites; The encrypted files get synchronized and overwrite the backups; and you've got nothing.
rsync, or any thing to an offsite or local nas/server/whatever = fail. same reason. double fail if the local system mounts the drives on the remote system as part of the procedure giving the ransomware direct access to the remote filesystem.
Essentially any backup solution that cannot easily and reliably restore to a given point in time, including deleted files is a hard fail vs ransomware.
You need continuous ongoing incremental backups via an agent/daemon/service on a remote system. Its certainly possible to set something like this up and manage it yourself, but its not simple.
Honestly for personal / home / small businesses stuff like carbonite and crashplan and spideroak are probably your best line of defense vs ransomware.
That's not to say having torrent sync setup with 3 offsite systems is a bad idea. Its a fine idea for all sorts of disaster scenarios; and is probably quicker to recover from in the event of a system failure. Its just not much defense against ransomware.
For that you really need continual incremental backups.
Re: (Score:2)
I have my zfs server, an offsite realtime replicated backup, and a revolving carousel of offline SMR HDDs that include all the snapshots currently held on my zfs servers weekly to cover catastrophic hacks on the file servers.
Yeah, that sounds just like what my grandmother would do. /eyeroll
Re: (Score:2)
We've been hit with a crypto at work. Some "engineer" thought it would be a good idea to open the company computer and pull a SATA line out for his portable eSATA box. He ran a program that he got off a torrent and bang, crypto took off on all his drives.
The problem was that he, being an aerospace engineer, had R/W access to almost all the mapped drives on his box (think mounts for you *nix types.) So it hit the main file servers and ran for about four hours before we got notice of it. Yeah we got recov
Re: (Score:2)
Not a problem so long as the ransomware notifies you quickly before you back up.
A good reason to use backups which check file signatures for differences rather than just rely on time/date, unfortunately this is a lot slower.
Versioning Filesystems (Score:5, Informative)
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.
Re: (Score:2)
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.
You more or less have this with Volume Shadow Copy but ransomware will AFAIK delete them. It only works if you have some other user (root, dedicated backup-user/agent) do it that the compromised user can't fuck up. Or if you could make the backup/snapshot then drop your own delete/write privileges so you need admin rights to restore them. Though full compromise is also a risk, but ransomware usually doesn't bother it'll just encrypt your user's files.
Re: Versioning Filesystems (Score:2)
That's the biggest lose with Microsoft dropping their home server OS. It's still available in Windows Server, but it's several hundred dollars versus $100-150 for home server.
It provided automatic daily backups in a way that didn't have a user accessible mounted share. Restores were provided by a read-only network share that would become mounted, as well as a boot able USB key for full restores.
File history included with Windows 8 & 10 does give an automated time machine style backup system. But it b
Tripwire (Score:4, Interesting)
Tripwire (and tripwire-like software such as bit9/Carbon Black) has been a thing for years. What's different about this approach?
Re: (Score:2)
You beat me to it!
This sounds like old-school tech. The larger question is: why hasn't everyone been using tripwire systems for years already?
Sometimes just bad design decisions (Score:1)
Creepy lab (Score:2)
OK, definitely not taking my laptop to the University of Florida.
Re: (Score:2)
I spent years working for a computer security firm who kept live malware for investigation and testing purposes. All live malware was restricted to a single room with very limited access and no network connectivity. Even if you were allowed access, it was forbidden to bring any devices (including any storage devices or even your personal cellphone) into it or to take any such devices out.
Never once has any malware escaped from that lab. I assume that the University of Florida handles this stuff in a simila
Good idea (Score:2)
I like this idea, as it seems practical and fairly hard to fool.
Entropy Canary (Score:2)
I have considered keeping a "Ransomware canary" around. I'm thinking of, say, a Word .doc file on a network drive. A process on some separate computer then checks its entropy on a regular basis, or on file change notification if available, to make sure file entropy has not grown huge.
The idea fails for local files because (as I recall) the more sophisticated ransomware inserts itself as a filesystem driver. That's a likely problem for some of these researchers' heuristics as well.
(Expanding on something I
Let the dog bite you first..? (Score:2)
"...and, counterintuitively, actually letting it lock up a few files before clamping down on it."
Well, this might be better than nothing, but unfortunately this assumes that those "few files" might not still cause a considerable amount of damage.
What this solution doesn't seem to take into account is the fact that ransomware has quickly moved on to commercial targets because the payoff is so much greater than targeting home users. Therefore, actually letting the proverbial dog bite you first may hurt worse than you think.
The best solution to ransomware is still the oldest one; make backups, and make t
not impressed (Score:1)
Is it really that hard to prevent? (Score:2)
This shit pisses me off to no end.
We're running goddam stupid computers and it's our own goddam fault.
Look: How about some predictive algorithms that do practice runs? How hard can that be?
Here's how it should have been done back when Moby Dick was a minnow:
The computer would actually do what I've been trained NOT to do, but do anyway.
When I click on an attachment, the computer examines the future consequences in a "play like," simulation and says to itself, "this mofo set of instructions encrypts files fro
ransomeware (Score:1)
100% ransomeware solution... (Score:1)
Here's a 100% effective ransomeware solution. When you fork out hundreds or thousands of dollars for your computer, fork out a $100 more and get an identical hard drive to what it has inside and a one-button disk cloner off of Ali Express or eBay for a few dollars. Weekly disk cloning kills ranssomeware dead. In the worst case scenario, you clone the drive with the malware on it but before it activates. In that scenario, you can still restore from backup and even if the OS is hopelessly compromised with
Really? (Score:2)
So Ransomware would have to gain Admin rights to disable this system?
ZFS snapshots can mitigate the risk (Score:2)
--Setup a ZFS+Linux+Samba server as a RAID10 network share drive, copy data to it, take a known-good snapshot. Do a zpool scrub afterward to make sure.
--Then implement a cron script that takes a rolling snapshot Mon-Sun. If you're feeling ambitious you can install the zfs-auto-snapshot package but you should really disable the "frequent" snapshots (every 15 minutes? who really needs that?) and possibly "hourly" snapshots since they will prevent your disks from going to sleep.
--As a bonus, you could also ta