Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

Ask Slashdot: Could We Fight Ransomware With 'Unencryptable' Folders? 437

Posted by EditorDavid from the full-disk-unencryption dept.
CaptainDork writes: I'm a retired IT guy and ransomware was not a huge thing 3-5 years ago (at least few victims were self-reporting) and I'm very curious about protection schemes.

In my, now ancient, world we did not encrypt anything -- anywhere. Seems to me the trick would be to mark certain places as "unencryptable," similar to long-time attributes like "hidden," "system," "read-only," etc.

Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?
Leave your best thoughts and suggestions in the comments. Could we fight ransomware with 'unencryptable' folders?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Could We Fight Ransomware With 'Unencryptable' Folders? More

Ask Slashdot: Could We Fight Ransomware With 'Unencryptable' Folders?

Comments Filter:

  • what a stupid question (Score:5, Insightful)

    by Anonymous Coward on Sunday May 12, 2019 @06:36PM (#58579818)
    How can you disallow encryption? Any code that can read/write access a directory certainly can encrypt it.

    • Re:what a stupid question (Score:5, Insightful)

      by ShanghaiBill ( 739463 ) on Sunday May 12, 2019 @06:47PM (#58579888)

      Yes, this is a ridiculous suggestion.

      Here is the solution to ransomware:
      1. Proper security so you don't get hacked
      2. Backups so you can recover

      Anyone who is too negligent to do these isn't going to set up "unencryptable folders" either, even if it was possible.

      • Re: (Score:3, Interesting)

        by lrichardson ( 220639 )

        Yeah ... but no.

        Security can make things harder to hack (or break into or steal), but the concept of perfect security is a fallacy. This is taught in Security 101, at any decent school. Layered security is one of the best approaches - e.g. firewall, TFA, sandboxed systems, encrypted data - but even that will never guarantee 100%.

        And backups are great ... and not 100% either. Once had to assist in picking up the pieces from a company that went under ... the code - probably written by an insider - was writ

      • Re:what a stupid question (Score:5, Informative)

        by ctilsie242 ( 4841247 ) on Sunday May 12, 2019 @07:30PM (#58580098)

        I do agree that backups are important, but I would say that additional measures need to be taken to have ransomware-resistant backups.

        1: You need to save backups for a longer time. Perhaps set aside monthly archives for a few years, and quarterly archives for seven years. This is to counteract ransomware that silently affects backups.

        2: You need to assume all clients are hostile and use "pull" backup clients, ensuring they cannot touch the backup repository. Mainly since some ransomware will search for network shares and eradacate them.

        3: You need some persistence if ($DEITY forbid) a bad guy gets into a cloud account and purges everything. For example, Glacier has Vault Locks which are not removable by the account, and one can set a time delay before stuff can be deleted. The storage provider Wasabi has a compliance mode offering a similar feature, where data once stored, cannot be removed even by the root user.

        As for security, probably the best defense is AppLocker and disabling EFS on Windows. However, the next generation of ransomware will only piggyback off of a signed application and use its own encryption. In my experience, AppLocker and disallowing unsigned macros from being automatically run in Word/Excel seem to be a good line of defense. FRSM, and "canary" files are also useful.

        Windows also is slowly getting there. The latest Windows 10 edition offers Controlled Folder Access which is useful, although may bring issues installing stuff.

        For home/SOHO users, if I had to give one easily followed instruction for dealing with ransomware, I'd tell them to install CrashPlan, BackBlaze, or even Mozy or Carbonite. That way, there are some backups saved off securely.

    • Re: (Score:2)

      by vlad30 ( 44644 )
      Agree with the above comment

      Saw this recently just blocked smb from unknown IP's and added good secure passwords to the dumbass account holders. Problem solved.

      Also went to the backups which were fairly up to date do to hourly incremental copies

    • Re:what a stupid question (Score:5, Interesting)

      by im_thatoneguy ( 819432 ) on Sunday May 12, 2019 @07:38PM (#58580122)

      How can you disallow encryption?

      Actually, I can very easily think of a dozen ways. This isn't a dumb question at all and I'm sure every security company right now is looking at ways to identify write patterns that look like ransomware. For instance, is it reading files from folders all over a drive or sticking to one or two folders? If it's accessing and rewriting lots of files maybe it's safe but this is a great time elevate permission to the user. "This looks like ransomware should I proceed?"

      OneDrive already has this. If you try to change too many files all at once it'll trigger ransomware alerts to the user. I've had it false positive a couple times when I was wholesale transferring tens of thousands of files out. But I appreciated this very simple algorithm.

      There are more ways an OS could identify patterns that look suspicious.

      1) Is this application accessing many files?
      2) Is this application changing more than 90% of the bytes but still resulting in a file the same file size within 10%?

      Antivirus can look deeper. If you inspect the code in memory you could identify fragments of code that contain known encryption algorithms. Flag again to the user.

    • Re:what a stupid question (Score:5, Informative)

      by 0100010001010011 ( 652467 ) on Sunday May 12, 2019 @07:40PM (#58580130)

      By making it a property of the file system. This is more or less what ZFS snapshots are.

      Snapshots are WORM. Once a file is snapshotted you can't go back and edit it without destroying the entire file system, you can edit the 'live' version to your hearts content but the snapshots are there.

      • If the malware is smart enough and has root, it can access of destroy ZFS snapshots. If you run it remotely via the built-in NFS snapshots will remain inaccessible to malware on the remote machine.

        Also you may want to scatter a few canary files around, scan them on a schedule, and force a read-only remount should the canary fail.

    • Re: (Score:2)

      by lcreech ( 1491 )

      Yes, It can be done. Linux supports immutable files/folders. The "chattr +i somefileorfolder" will become unwritable/unencryptable at the os level even as root, until undone.

    • How can you disallow encryption?

      Simple: make the folder read-only. If you can overwrite files so can the ransomware.

      • turning off the read only flag on files owned by the user is as simple as typing "attrib" in cmd. You'd have to make the folder owned by administrators, which can cause issues for regular users interacting with it.

        I'll give you that there is some data that;'s just fie being permanently read-only, but for most it needs to be interacted with., so the admin-owned read-only folder would cause issues for people getting work done.

        But what you're just described is Version Control Software, and it already exists.

  • No malware bit (Score:5, Funny)

    by fgouget ( 925644 ) on Sunday May 12, 2019 @06:36PM (#58579820)
    I think a better idea would be to set a "no malware" bit in the kernel so malware applications know they are not allowed to run on that system.

  • No. That is not how it works (Score:5, Insightful)

    by gweihir ( 88907 ) on Sunday May 12, 2019 @06:42PM (#58579860)

    As soon as an application can read and write a file, it can encrypt it. The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should. Entropy checks (basically the only thing you can do automated to determine whether something is encrypted) fail on compressed data nd on random or random enough binary data. Sure, you could "tag" files with the type of data in there and even provide methods to check whether it is in the format it should be, but that would mean rewriting the OS and basically every application.

    Please stop making suggestions how difficult security problems could be solved when you do not even know the basics of how the relevant computers work.

    • Re:No. That is not how it works (Score:4, Interesting)

      by alvinrod ( 889928 ) on Sunday May 12, 2019 @07:11PM (#58580018)
      You could sort of half-ass such an approach by having write-access to files limited to a single application that is considered to "own" that particular file. It still lets other programs access the file and for a lot of files that's all that's necessary. It may be possible to use the programs that "own" the files to encrypt them, but that's likely to be a much more difficult task. That solves the problem of needing to understand what the files ought to look like, but it's still a hassle for a variety of other reasons.

      Someone will get sick of jumping through the hoops and create a nice little super user work around command to make managing all of this easy, but then the system is only as good as the OS is at stopping privilege escalation. Never mind the the average user will just be duped into clicking a button and authorizing the malware to turn off the protections or change the program that owns every file to the malware program. There are probably ways to make that a little bit harder, but ultimately you can't protect an idiot from their own stupid actions if they're insistent enough, and many of them are.

      Even if you do manage to do all of this and make it workable enough that people will actually use the system, it just shifts the attack vector to something else. There are probably plenty of other ways that people who write ransomware applications could screw with a system to essentially lock out a user and deprive them of their files.

      • Yes and this is how modern OSs built from the ground up with security in mind do it. However OSs with established applications which require and expect such measures to NOT be in place stop existing OSs (eg Windows) from establishing such a model.

        Windows has a shot with the Windows Store but they also adopted all the negative aspects of that model in addition to the positive ones which put a lot of people off.

    • As soon as an application can read and write a file, it can encrypt it. The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should. Entropy checks (basically the only thing you can do automated to determine whether something is encrypted) fail on compressed data nd on random or random enough binary data.

      Actually, encrypted data would be easy to detect, and the combination of an existing file being re-written (encrypted) by a new application (or a browser) could trigger a UAC pop-up, or at least preserve the existing data.

      • Re: (Score:2, Informative)

        by Rockoon ( 1252108 )

        Actually, encrypted data would be easy to detect

        No, and for the exact reasons he already mentioned, for the exact reason you actually fucking quoted him mentioning, while you ignored it and just defiantly said stupid shit that isnt right at all.

    • The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should.

      If an application attempts to dramatically increase the entropy of more than 100 files... flag it and raise a user prompt.

      You clearly explained how an OS or AV system can with minimal false positives flag unusual behavior and then dismissed flagging unusual behavior as nonsense. If what you're suggesting was impossible, no anti-virus application in existence would be of any use.

      There are other ways too. The OS could create files that it hides visually from the user but knows are nonsense. If an applic

    • In theory, you could limit write access to some whitelisted applications. Then $GoodOfficeApp could still overwrite or otherwise change the file, but $Malware would be blocked. Or at least trigger an UAC check or its equivalent on the OS you use.

      I say in theory, because I'm not aware of such a system being commonly in use.

      • Re: (Score:2)

        by dgatwood ( 11270 )

        We used to on classic Mac OS: Gatekeeper [macgui.com]. Basically, there were a certain set of behaviors that were considered interesting, like reading and writing files, opening network connections, etc., and if an app tried to do something expected, it required you to confirm that it should be allowed.

    • Re: (Score:2)

      by guruevi ( 827432 )

      It's rather easy to fix though.

      Some AV's basically see how much a particular program is reading/writing and indeed checking entropy. If a program is maximizing randomness while replacing documents and the like, it blocks it until someone can intervene.

      On the other hand, a good OS would have a filesystem that has immutable snapshots. It's in macOS and Linux, not sure why Windows hasn't natively built-in immutable snapshots yet. Doesn't help against low level (block) encryption but that also requires deeper a

    • As soon as an application can read and write a file, it can encrypt it.

      Which then suggests a no-write setting. Like the immutable bit in Linux. I already set this on important files that I know no one has any business changing. If the malware gets admin/root access, then this is useless. However, more and more malware doesn't have admin access. Just user access. And it's using user access to just encrypt that user's files. So, for important files where you know you never (or seldomly) need to edit them, the immutable bit is an effective tool for file protection.

      Now, the

    • Re: (Score:2)

      by robbak ( 775424 )

      Not too difficult to create an encryption technique that passes an entropy test, especially if you allow it to increase the size of the file. Encrypt, then add something to it. Not to mention that a good compression algorithm yields something that appears to have very low entropy. If you leave some patterns in the output, then those patterns are something you can detect and represent with fewer bits.

  • Better Question (Score:3, Informative)

    by Alexan Kulbashian ( 4438611 ) on Sunday May 12, 2019 @06:42PM (#58579864)
    Can we fight IEDs with bomb-proof underwear?

    • Not if the bomb is inside the underwear. If you know what I mean.

      More on topic, my drive is already encrypted, so I'm 100% safe. It's not like anyone could encrypt something twice, except maybe with ROT13. Besides, my native language has more than 26 letters so even that wouldn't work.

  • Why am I seeing this post? (Score:5, Funny)

    by silverkniveshotmail. ( 713965 ) on Sunday May 12, 2019 @06:47PM (#58579892) Journal
    This reminds me of when I was 11 and I had a great solution to computers crashing all the time: they could just keep working when they have an error instead of rebooting or locking up.

    • Minix3 does that more or less. If it detects and error, it spins up a fresh instance of the server/driver. Quite a few moving parts to get it to work well, you may lose, some state anyways, and crashes in the core micro-kernel, or simultaneous errors in the service watcher and the service watcher watcher will still cause a hard crash.

  • Boot from ROM and mount a physically segregated device as read only. Read only memory, or unalterable memory (CD-ROM).

    Or just write it to CD ROM. It's literally in the name. It cannot be encrypted.

  • Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?

    Just make sure your backup system pulls data from the systems to be backed up.
    That is, never let the systems to be backed up push their data out or do the copy of the files, and never allow them to reach the backup system directly at a network level.

    Ransomware infects a computer, inserts into the filesystem driver, and silently encrypts data on the disks/volumes in the background, all while re-decrypting it to give it to the OS when asked for.
    This way you and the OS doesn't notice anything amiss.

    After it is

    • Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?

      Ransomware infects a computer, inserts into the filesystem driver, and silently encrypts data on the disks/volumes in the background, all while re-decrypting it to give it to the OS when asked for. This way you and the OS doesn't notice anything amiss.

      It's possible to mostly detect this sort of tomfoolery with forensic file access techniques but you are correct as far as I can see about preemptively blocking it.

  • Fight ransomware with regular backups. That's all.
  • This might be the stupidest question ever asked here.

    It's clear CaptainDork is a Windows user as he mentions the "hidden" file attribute. The solution is obvious to all *nix users however - just check for the evil bit on all downloads before executing them. Then you don't get ransomwared.

    <DING> next question please...

  • Now, it's easy to dismiss the question right away as being fooling given how computers, directories and files work.

    However, how about simply setting flags to every damn files and folders?

    "Program Microsoft Word is trying to read file my-document.doc, allow? [Yes/No]"
    Yes

    "Program randomware1337 is trying to read file my-document.doc, allow? [Yes/No]"
    No

  • Already exists (Score:5, Insightful)

    by Solandri ( 704621 ) on Sunday May 12, 2019 @06:58PM (#58579952)
    WORM - write once, read many. Most of you are probably familiar with it in the form of the writeable CDs, DVDs, and Blu-Ray disks. You can only write to them - they can't be erased. Even though they create the illusion that you can erase or overwrite the data on them, that's only the case for software which can read only the oldest session. The original data for all sessions is still accessible by programs which can read previous write sessions [isobuster.com].

    The problem was never safeguarding data against ransomware. That problem was solved back in the 1960s decades before ransomware first appeared. The problem has always been that people are lazy. They either don't bother making backups; or if they do they'd rather use a "set it and forget it" system by leaving a backup hard drive always plugged in, or don't want to be bothered with shuffling multiple optical discs to backup their multi-TB drive.
  • Solutions already exist, versioned filesystems, shadow copy, backup etc. The concept of trying to determine if a write operation is somehow magically encryption is idiotic. People that get hit with ransomware and damaged by it are already failing at basic IT operations or backups and any new concept they would also fail at.

  • You could write all your changes for that folder to a physically write-once medium, such as burning to a CD. Then you'd virtualize that as an "unencryptable" folder. It's really just backing up to a write-once device. You couldn't do it for a lot of data, because AFAIK write-once media still don't have particularly high capacity. Recovery from attack would involve running through all the changes on the CD, applying them until you had the latest revision. One broken file could make recovery difficult, s

  • backups (Score:4, Insightful)

    by gbjbaanb ( 229885 ) on Sunday May 12, 2019 @07:24PM (#58580076)

    Sorry to say it but its easy: backup your stuff on a incremental basis. Usually you'll see a few files change.

    The day that every file changes, you'll know something has changed your system, you can check to see if its not something you did that updated them all (some service that updates metadata for example) but if its not, you can wipe and restore from the last backup. Preferably the backup software would notify you that an unexpectedly large number of files were changed (ie encrypted) and let you stop further backups to retain the good versions.

    Detection is the key, if you can detect that your files have been hit with ransomware, yiou can restore them.

  • Unenforceable (Score:3)

    by richardtallent ( 309050 ) on Sunday May 12, 2019 @07:24PM (#58580078) Homepage

    Malware doesn't use the transparent file system encryption tools provided by the OS. It simply overwrites the files with encrypted versions of themselves using its own encryption scheme, silently, until it has enough leverage over the end user to display a message holding the files hostage. The OS can't tell the difference between malware and any other sort of normal write activity.

    That said, a smarter OS *could* notice that user files are being read or written at a pace or breadth that is inconsistent with the user's normal activity, and it could then quarantine the processes involved until the user or administrator confirms that the activity is expected. That would of course create the usual issues of needing to whitelist certain processes, and if that is something the user can do, it's also presumably something the malware can do running under the user's privilege.

    Honestly, the best *final*-tier protection is the same as it's always been -- good backups. Preferably, backups that are automatic, preserved for some reasonable period of time, and are logged and verified by someone other than the user. The vast majority of these ransomeware attacks did nothing that wouldn't have happened eventually when the users' hard drives wore out.

  • First of all if the malware "roots you" you are mostly out of luck.

    However a back up system, that runs as a different user, and only has read access to your files, could write back ups on a different partition, even with versions, aka simply hold a git repository or something similar on that other partition. Actually it could simply be a folder on the main partition.

    Background is: the malware running as YOU can not access or write to the folder/partition that belongs to the backup software. Should be nearly

  • Only on read-only or offline media.

  • It's a naive question, but it's great that he asked.

    A 'do not encrypt' bit in the OS wouldn't stop an attacker from encrypting files, because the OS can only prevent the OS itself from encrypting files, it can't prevent some other code from doing so, because all the OS would know is that a file is rewritten with a new version of the file.

    The only way to protect youself from an attacker encrypting files is to make backups, and to keep archives that go back long enough that you can recover if a file is encryp

  • Simply write all your folders to read only media so that they can't be modified or encrypted. Easy peasy!

  • Suggestion made by covert NSA operative #31.
  • If we ask nicely, do you think the h@ck3rz will respect our flags?

  • They don't need to be "encrypted". In fact, your "not unencryptable" wouldn't stop someone from overwriting them.

    They just need to be protected. It doesn't matter how.

    Windows already has a feature called "Controlled Folder Access". That's exactly what it does. You specify the folders. Nothing can write to them. If anything tries, you'll get a notification saying that it was blocked.

    And then you can white-list programs that can access them. It's not [yet?] fine-grained, but that's okay today.

    • Re: (Score:2)

      by Skapare ( 16644 )
      and what if they bypass the OS and encrypt your whole drive?

      • Then didn't you kind of authorize them to do so? Bypassing the OS isn't something that is (realistically) going to happen from just receiving a random spam e-mail. Truth is that I have no idea how far controlled folder access goes, or could go.

        I'm fine with the chaos that comes from opening a strange attachment, downloading a strange executable, or intentionally visiting a strange web-site. Those are no different from accepting a package on your doorstep from some guy in a hoodie, walking into a stranger

      • he will claim that that should be impossible, and then rant later about microsofts unfair practices because now only microsoft software gets low level access to drives
  • my encryption software could be modified to check for the "do not encrpt these files" flag. then it would be safe for hackers to use. just download the source code and make the changes.

  • because you made so much money off your algorithm that can detect encrypted files?

  • There are already well known standards to keep this sort of attacker out of your system long before folder access becomes relevant.
    See rfc-3514 for the pertinent specification.

  • Canaries (Score:5, Interesting)

    by Beeftopia ( 1846720 ) on Sunday May 12, 2019 @10:04PM (#58580746)

    Encryption is manipulation of bytes. Think of it as scrambling the bytes. Whether MS Word is doing it in a wanted fashion or hotAsianPr0n.jpg.exe is doing it in an unwanted fashion - that's a hard problem to solve. Bytes are changing on the filesystem - innocuous or malicious?

    One way to detect it perhaps are maybe "canaries". Sections on disk monitored by say the kernel, that are supposed to be immutable. If one of those changes - it should never change - the system goes on lockdown. All reads and writes are halted.

    Ransomware doesn't attack the OS - the system wouldn't be able to boot. They need the OS to relay instructions to the user about what is going on and where to send the bitcoin. So there's a bit of a fortress in the OS.

    So... canaries. Section of the disk or memory that are supposed to be immutable. If they change - system halt until someone takes a look with a forensic tool. It won't save all your data but it'll save a chunk of it. And it could limit propagation of the malware.

    If you kill the canary, the OS kills you.

    The canaries would be set randomly every time at startup, so a malware writer wouldn't know where they are. There could be an encrypted section of memory or disk that contains pointers to the canaries.

    One angle to consider.

  • No

  • Yes (Score:2)

    by reanjr ( 588767 )

    Mount the drive read-only.

  • Backup your important data to a WORM (Write Once Read Many) device like a BD-R.

  • "Could We Fight Ransomware With 'Unencryptable' Folders?"

    The short answer is no.

    I actually just went through a bad ransomware attack.

    First, suppose a file contained: "Hello wurld."
    If I wanted to correct it... "Hello world." that requires changing a character, and saving the new file. If I decide I want to save it as "Hello Mom" instead. I've rewritten half the file. Maybe I want to change it to "Goodbye Mom". And now I've changed everything.

    There is no technical difference between "Goodbye Mom" and encrypting it: "kfjq3fk4 a9a23kkj.alkrjm34kl1jcfakdjfakjn32". And

  • If the data can be READ and DELETED by the attackers, then they can just encrypt it after they copy it. Or hold it ransom without encrypting it for that matter. This is the same effect as encrypting it in-place.

  • This makes me so sad.

Slashdot Top Deals

Elliptic paraboloids for sale.

Close