Hive Ransomware Now Encrypts Linux and FreeBSD Systems (bleepingcomputer.com) 26
Hive, a ransomware group that has hit over 30 organizations since June 2021, now also encrypts Linux and FreeBSD using new malware variants specifically developed to target these platforms. BleepingComputer reports: However, as Slovak internet security firm ESET discovered, Hive's new encryptors are still in development and still lack functionality. The Linux variant also proved to be quite buggy during ESET's analysis, with the encryption completely failing when the malware was executed with an explicit path. It also comes with support for a single command line parameter (-no-wipe). In contrast, Hive's Windows ransomware comes with up to 5 execution options, including killing processes and skipping disk cleaning, uninteresting files, and older files. The ransomware's Linux version also fails to trigger the encryption if executed without root privileges because it attempts to drop the ransom note on compromised devices' root file systems.
Fix (Score:2, Funny)
Run the Windows version in WINE. Done.
The Linux variant also proved to be quite buggy (Score:5, Funny)
FreeBSD (Score:3)
FreeBSD's base filesystem is ZFS. If you routinely have snapshots taken, just revert either the full filesystem or individual files from the snapshot. DONE! (also, PLEASE replicate your snapshots to another machine, preferably in another geographical location! snapshots alone are not a complete backup solution)
Re: (Score:2)
Re:FreeBSD (Score:5, Informative)
What keeps the ransomware from doing a 'zfs list -t snapshot -o name' then cycling through all the snapshots and destroying them? If ransomware has root, it can do anything, maybe even go through a shell history or look for crons/ZFS sends in order to try to expand/nuke those. Once ransomware gets unconstrained root on a UNIX system, it is a cat and mouse game.
The good thing about UNIX variants is that it is fairly hard to get unconstrained root access. This means that ZFS snapshots, or a mechanism that pops snapshots, then used Borg Backup to either send the ZFS images, or does a temporary mount and backs up via files, will give adequate protection, especially if the append only flag is set on the server side, and Borg backups are done through SSH with a limited shell the client can access.
Even better news is the threshold of how things get fixed on Linux or BSDs... A bug fix comes out when someone finds a potential issue, as opposed to the issue being widely exploited in the wild, so the window of when a zero day can strike can be significantly narrower than Windows.
It will be interesting to see how Linux based ransomware spreads. With internal stuff like firejail or BSD's jail(), just jumping out of the web browser becomes a non-starter. It can require finding a CPU exploit like Meltdown in order to escape out of the context it runs in. Trojans are doable, but a lot less common, since there is a lot more work in downloading an executable. However, with many people used to "curl site.com/foo.sh| sudo bash" as a means of installing a package, that might result in an infection vector that Windows does not have.
In any case, ZFS or btrfs (Yes, btrfs has its issues, but it has snapshot functionality which can help in cases like this) are something to consider for building new machines.
Re: FreeBSD (Score:3)
As you point out snapshots are a useless defence against ransomware. The only true defence is an offline backup. They are however a huge hassle. The next best defence is tape because wiping tapes in a library is a slow process. Further any decent tape library and any decent backup software will produce logs of tape volume mounts. Any discrepancy and you drop the power to the fibre channel switches connecting the library in a manner that requires physical intervention to restore the power.
Re: (Score:3)
I wish tape were more available. We have a lot of useful primary storage, be it SSDs, decent sized hard drives, cloud, etc. However, archival grade, offline storage with a capacity of relevant size is hard to come by, unless one spends the 5000+ bones for a USB LTO-8 drive, or an SAS or FC LTO autochanger. It would be nice if some company could make a tape drive for $1000 or so, with 2-3 TB of capacity native, built in compression, encryption, and had it usable with USB-C or Thunderbolt. Not a back leve
Re: FreeBSD (Score:2)
Its a vicious circle. Not enough people care about backups partly because tapes are expensive, so the volume remains low so the price remains high. As the price is high people shy away from backup to tape and so the circle goes on. The reality is the tapes themselves are really quite cheap. Its just the drives and libraries. Mind you a decent library will last decades, IBM are just now dropping support for the TS3500 library which must be about 20 years after its introduction and I believe you can reuse the
Typical. (Score:4, Funny)
So some idiots decided they could bring their closed source software to Linux and completely half-assed the port? Typical! If they really cared about Linux then they would GPL their ransomware code so that people could submit fixes for them to upstream. By doing this, we can finally get some mainstream support for ransomware on Linux but no, just more closed source fools pumping out shitty Linux ransomware!
Re: (Score:3)
Devil's advocate:
This is a version 1.0 program. Generally, ransomware is the best quality software you will ever see, because it is made by organizations that care about software quality, and ransomware support tends to be better than many companies' support divisions.
This will definitely improve. Things like nuking stored snapshots, hunting down mounted backup directories and encrypting/nuking them, rootkits, stealth kernel modules that are sucked in, which can do the encryption out of view of the operat
Self serving MICROS~1 cyber BS .. (Score:2)
How (Score:2)
It does not explain how it get on these systems or how it works. I doubt (or hope) no Linux/FreeBSD person would execute this as root or does a suid on it. Without that it is DOA.
The only other possibility is it targets Windows Linux "sub-system", which would make since because I would expect there are plenty of holes in that. Plus any idiot executing Linux inside Windows to serve critical data gets what the deserve.
Re: (Score:2)
The method of propagation is left for the reader to guess. I can think of a few ways:
* A Trojan. Running a Trojan on Linux or FreeBSD is a lot harder than Windows. It takes popping terminal window, adding an executable flag to permissions, and running it from there. This also assumes the /home filesystem is not flagged with "noexec" or "nosuid", which a number of machines might have enabled, and if Trojans become more common, making /home a noexec filesystem with executables run in a sub-context on ano
Re: How (Score:2)
Re: (Score:3)
That is one I forgot about. With the average dev including so many packages, most of them likely unmaintained and definitely unvetted, in order to get their deliverables in faster, supply chain attacks are going to be more common, as bad guys go after npm or other libraries... which are easy to compromise, as many are not written with security in mind... and it only takes one weak link.
Re: How (Score:1)
Thatâ(TM)s why I recommend to build Docker packages for those kind of languages. You at least contain the problem to a very limited dataset. And then externally, you handle it with snapshots that are invisible to the software.
Re: (Score:2)
Nonsense. There's nothing stopping them from distributing a .deb or .rpm that idiots can install by double-clicking the file and typing their root password when prompted. The problem for Linux trojans is that most Linux users aren't idiots.
Re: (Score:3)
It does not explain how it get on these systems or how it works.
Same way it does on Windows, ask the user to execute it.
I doubt (or hope) no Linux/FreeBSD person would execute this as root or does a suid on it. Without that it is DOA.
As long as we agree that Linux is a niche product not ready for mass consumption and difficult enough only to be used by the most expert of hackers. But it's not 1993 anymore. We're not manually compiling kernels for hardware support. The reality is as Linux grows in popularity it picks up stupid users. Either Linux is a modern capable OS and thus susceptible to PEBCAK, or it's not ready as a desktop OS.
The only other possibility is it targets Windows Linux "sub-system",
While it doesn't do that, the fact that you think
Title should be "tries to encrypt Linux" (Score:1)
What are the common ways of infecting a Linux sys? (Score:2)
I wonder what is known about how the Linux systems actually get infected with that. I am using dozens of Linux computers privately and for work and TBH was not too worried about this kind of thing so far, but I am getting a bit more scared now. I am not sure I would know how to best protect against getting infected.
Re: (Score:1)
Re: (Score:2)
The defense against ransomware is the same on Linux as on every other platform: good backups.
Any user that can run downloaded code and can write to files (both desirable features) is suspectible to ransomware.
Re: (Score:3)
The difference is that downloading and installing software from random websites you know little about has been normal operating procedure in Windows for decades. Whereas in Linux, users are used to getting their software from standard repositories and instances of downloading and installing from a website are rare enough that they prompt serious consideration and skepticism.
Of course ... (Score:2)
but I wonder which attack vectors are actually used for Linux and how: for example if they try to make users download code, is this done via email as on Windows? Have they tried to infect OSS releases? Are they trying to hack into insecure public logins (ssh or console logins), do they attack apache servers, public databases?
The whole ransomware thing can only be successful if they specifically target Linux users where any of these attacks can be successful at least a certain number of times. So there shoul
Judging by counting command line options? (Score:1)