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

 



Forgot your password?
typodupeerror
×
Crime Security Virtualization Linux

New Linux-Based Ransomware Targets VMware Servers (csoonline.com) 36

"Researchers at Trend Micro have discovered some new Linux-based ransomware that's being used to attack VMware ESXi servers," reports CSO Online. (They describe the ESXi servers as "a bare-metal hypervisor for creating and running several virtual machines that share the same hard drive storage.") Called Cheerscrypt, the bad app is following in the footsteps of other ransomware programs — such as LockBit, Hive and RansomEXX — that have found ESXi an efficient way to infect many computers at once with malicious payloads.

Roger Grimes, a defense evangelist with security awareness training provider KnowBe4, explains that most of the world's organizations operate using VMware virtual machines. "It makes the job of ransomware attackers far easier because they can encrypt one server — the VMware server — and then encrypt every guest VM it contains. One compromise and encryption command can easily encrypt dozens to hundreds of other virtually run computers all at once."

"Most VM shops use some sort of VM backup product to back up all guest servers, so finding and deleting or corrupting one backup repository kills the backup image for all the hosted guest servers all at once," Grimes adds....

The gang behind Cheerscrypt uses a "double extortion" technique to extract money from its targets, the researchers explain. "Security Alert!!!" the attackers' ransom message declares. "We hacked your company successfully. All files have been stolen and encrypted by us. If you want to restore your files or avoid file leaks, please contact us."

This discussion has been archived. No new comments can be posted.

New Linux-Based Ransomware Targets VMware Servers

Comments Filter:
  • by saloomy ( 2817221 ) on Sunday May 29, 2022 @11:44AM (#62574842)
    We use the storage system for backups and replication. VMware is out-of-band managed and so is our storage servers. The only protocol that works between both is NFS. It just makes sense to isolate your systems from each other to contain compromises. Backups should ABSOLUTELY be managed out of band and beyond reach of the servers or hypervisors.
    • Learn it. Love it. Live it.
    • backups need to link into VMware to do snapshots / diff backups. You don't want to do FULL IMAGE BACKUP's each night.

      • It sounds like GP's storage assets are not in the VMWare realm, and presumably snapshotted from the storage realm. I always thought that had risks compared to the hypervisor snapshots.

        • by saloomy ( 2817221 ) on Sunday May 29, 2022 @01:16PM (#62575092)
          Our storage backups are incremental-forever. We have a separate process that takes a snapshot of the VMs every few minutes. It doesnt have nearly the impact on performance as you would think. When we recover from storage a VM directory, we can see our VMs snapshots which we *could* revert to, but actually I have found that in most cases, it is unnecessary. VMs seem to boot back up fine, occasionally with a filesystem repair operation, but the files are fine most of the time.

          The only think we really treat differently is databases. Those are snapshotted in a consistent way with all servers across an application, so we can recover the entire stack as needed. To do the snapshots, we have a small server that curls the MOB in vCenter to get all VMs and in a foreach, we call the snapshot feature, without memory. This kicks off a task that is non-blocking, so we can call for a lot of snapshots very quick (200 or so VMs in under a minute). For most VMs we just delete the snapshots the following day, and that seems to work just fine. There are handful where we have custom timers to delete the snapshots during known luls in activity, but we only did that in a precaution against merge operations that can be intense on disk iops at times. Overall, it works really well, and the replica that the entire system syncs to in a remote location is totally isolated, save for the port needed to ncat send / receive the storage systems' incremental snapshots. Those we consider sacred because all else can be recreated, but that is our last-line of defense before having to go to its' tape copy, at the remote location.

          This scheme has saved us a lot of grief and heartache. Ransomware attacks on VMs that users dial into are easily recovered and then mitigated. So are malicious file deletions by exiting employees.
        • You can use rest API with a non-privileged account and the specific rights to pull CBT (changed block tracking). That's the way most backup solutions work anyway: snapshot, CBT, then they either hotadd a datamover VM with the snapshot or pull it via NBD.
    • by gweihir ( 88907 )

      Unless your backups are WORM or offline, you are at risk here.

      • Our backups are Primary >> Secondary >> Tape. Tape is the offline copy, but by the way we isolated the primary and secondary sites which only allows the port to receive the data without any ability to manage the box from primary, we feel this level of protection is sufficient to all but guarantee we wont be having to restore from Tape which would have a brutal timeline for recovery (as we all know). Our only risk would be from rogue internal management, but the number of people who have access
        • by gweihir ( 88907 )

          A server that does not allow changes or overwrites once a file has been transferred qualifies as WORM in my book.

      • I've learned the hard way that nothing is really "backed up" unless there are 3 copies and at least of those is offsite (preferably two).

  • Linux in my book is just about mainstream. I've been using it just about exclusively for anything mission-critical for about 2 decades now. However, 10-12 years ago there was a nice little fight/competition going on between BSD and Linux about who's the coolest kid on the block. Ever since Linux got into the epic SystemD controversy I haven't heard much from BSD. With Linux becoming more mainstream and perhaps an easyer target for stacks built around it, I'm always tracking alternatives.

    Which has me wonderi

    • by mmell ( 832646 ) on Sunday May 29, 2022 @12:06PM (#62574910)

      Microsoft: "Where do you wan to go today?"
      Apple: "Where do you want to go tomorrow?"
      Linux: "Are you guys coming, or what?"

      --

      Berkeley had two exports back in the seventies - BSD and LSD. Coincidence? I think not.

    • Can’t speak on a professional level but my personal firewall/server has always been OpenBSD. Disk i/o isn’t great but I love how minimal the install is. You only add what you need. The documentation is top notch and always up to date. Stable as ever and only ever reboot for updates.

    • by gweihir ( 88907 )

      The xBSDs are sort-of low-key but they are far from gone or dying. They are dependent on donations AFAIK, but this seems to work. Also, by now with some of the mess going on with Linux, they provide a fallback in case we have to abandon Linux. Does not seem to be very likely, but definitely possible.

    • Could I switch from my webdev system of choice - LAMP - to BAMP and not miss anything?

      This I can answer, and the answer is yes. Frankly you don't miss much even moving to WAMP as far as the server stuff goes.

      However FreeBSD doesn't actually have anything over Linux any more really, so it's hard to make a case for it. OpenBSD may be more secure, so if what you want is a very classic server you might think about that and see if it supports your hardware. Linux is however the modern feature and performance champ in pretty much all areas.

      If all you care about is to avoid systemd on a server, ins

      • by MeNeXT ( 200840 )

        However FreeBSD doesn't actually have anything over Linux any more really, so it's hard to make a case for it.

        So it's your opinion that Linux has finally caught up to FreeBSD so drop FreeBSD?

        I've used both for around 30 years so far so I don't particularly favor one over the other in general. Each has it's pluses and minuses. One thing about the BSDs is that they are consistent. Many an upgrade has broken some of my Linux installations. I haven't had one BSD upgrade that broke. I moved one system from bare metal to a VM then to a jail and then back to bare metal. This system has been upgraded since 2004. I haven't

        • I've done lots of successful upgrades of Debian and Ubuntu, not so much others. I had one Ubuntu system go through around five or six successful successive upgrades.

          I do think systemd is crap. I find it usually doesn't cause too many problems when the use case is very simple, but that's not much comfort as the whole point of it was supposed to be to make the complex stuff simple.

        • by ebvwfbw ( 864834 )

          However FreeBSD doesn't actually have anything over Linux any more really, so it's hard to make a case for it.

          So it's your opinion that Linux has finally caught up to FreeBSD so drop FreeBSD?

          I've used both for around 30 years so far so I don't particularly favor one over the other in general. Each has it's pluses and minuses. One thing about the BSDs is that they are consistent. Many an upgrade has broken some of my Linux installations. I haven't had one BSD upgrade that broke. I moved one system from bare metal to a VM then to a jail and then back to bare metal. This system has been upgraded since 2004. I haven't had a linux distro upgrade successfully past the lifespan of the hardware.

          One negative thing about Linux is systemd. You never know if an upgrade will break something. Every time I start getting comfortable along comes an update and services fails to start. But that's just my $.02.

          BSD has to catch up to Linux, not the other way around. It's almost two decades behind now. Just consider mandatory access controls. That's selinux. BSD has nothing like that. That's a major problem for BSD and one I don't think they'll ever catch up on.

          Let me be to the point. BSD is still a nice operating system for beginners. I learned a lot from it back when it was released in the late 1980s. Someone that wants to hack around with the kernel. Create a new driver. Things like that. It allows you to do thi

  • Just in case anybody was wondering. There is basically no actual "bare metal" Hypervisor out there these days.

    That said, backup needs to be ransomware-proof these days. That means WORM functionality and 2FA and a separate credential for logging into the backup storage servers. Professional backup software should support WORM these days and you can also roll your own, e.g. by using sftp and a demon that moves files after transfer or changes user and sets them read-only. Not that hard. Does save your beacon w

    • Well, you hope your backups are "write once, readABLE many times but in actual practice, never read.*"

      In other words, you hope you never need to use your backups.

      * except of course for the mandatory read-after-write verification(s).

    • This is a common misconception, but ESXi is NOT Linux [blogspot.com]. You are confusing ESXi with ESX - an earlier hypervisor from VMware that at one time used bits of Red Hat Enterprise Linux.
      • Seems wrong to me. Never looked at ESX but EXSi sure looks Linuxy to me under the hood. Never been a big ESXi fan.
        • by tbuskey ( 135499 )

          Not linux. If it was, Linux is GPL licensed and would require release of the ESXi source code. And ESXi source is not out there.

          The drivers are based on Linux drivers. They had to be modified to work with ESXi. That makes them derivative of the GPL drivers and the code is out there.

          If ESXi seems Linuxy to you, so would Cygwin and MacOSX which run on Windows and a BSD kernel on top of MACH.

          • by kriston ( 7886 )

            ESXi had been using the Linux kernel and VMware was sued over it [slashdot.org].

            Today VMware claims a project is underway to create a bespoke kernel. It sure still seems to look and feel like Linux thus far.

    • by kriston ( 7886 )

      There is basically no actual "bare metal" Hypervisor out there these days.

      Microsoft Hyper-V Server has entered the chat.

  • by StormReaver ( 59959 ) on Sunday May 29, 2022 @01:42PM (#62575154)

    I was in a hurry, so maybe I missed it, but there seems to be no indicator of how an attacker gets into the Linux system to begin with. The article strongly implies that an attacker has to already have shell access, and that the encryption program runs with the permissions of the user that owns the shell. But there is no mention of any exploit that gets the initial required shell access to begin with.

    That's the only interesting part of the entire story, and there seems to be zero information about it. Barring that, the entire story can be summed as as: local user runs program.

  • by drfuchs ( 599179 ) on Sunday May 29, 2022 @03:04PM (#62575326)
    And in related news, Broadcom has now put its purchase of VMware "on hold". "Oopsie, we forgot to do our due diligence before we made the $61b offer. Our bad! Give us a few days and we'll offer, oh, maybe $44b?"
  • These VMWARE instances, which are running Linux, are hosted on Microsoft Windows?

    Or is it just that VMWARE or the backup system for it, while hosted on Linux, are Swiss cheese?

  • "Researchers at Trend Micro have discovered some new Linux-based ransomware that's being used to attack VMware ESXi servers"

    How does this Linux-based ransomware get onto the computer in the first place.

    link [trendmicro.com]: “The ransomware requires an input parameter specifying the path to encrypt so that it can proceed to its Infection routine.

    Nope, still not any wiser.
  • Roger Grimes, a defense evangelist

    hehe, grrimey

  • ...Then it can be by this, if not then you are OK ...

    In other news if it can be compromised then it can be compromised by a long list of ransomware and other hackware so....perhaps you should secure it anyway

  • They talk about 2FA as being the solution to this. As usual I'm not finding any remote vulnerability for this problem other than a password that was compromised and that allowed access to the esxi host. So no hack, it's a normal authenticated access. Did I miss the wide open door?

Remember to say hello to your bank teller.

Working...