VPS security in the wake of the Virtualizor ransomware attacks

lowendmeow · January 31

I have been reading about the ransomware attacks that hit Cloudcone and now maybe Hostslick. Seems like there is some exploit in Virtualizor now as it's hitting different providers and not just Cloudcone's custom backend like someone said here.

It looks like all these hackers wanted was to ransom the data, but this presents a security issue, like what if they were able to access and leak the personal data (edit, lol sorry forgot to finish this thought!)

There was previously a thread on setting up LUKS encryption on my VPS which I have done. However I am now feeling quite dismayed seeing that anyone with hypervisor access can trivially decrypt the key from the running ram of the machine, I would assume also the ransomware hackers would have access to this if they had hypervisor access.

The only mitigation against being able to pull the RAM key if I understand correctly is if the VPS provider has a CPU that supports encrypted RAM and also enables this CPU flag in the VPS themselves. I don't think it is very common for VPS providers to support encrypted ram but if anyone has a list let me know.

I was recently playing around with systemd-homed on my home machines which keeps the home dir encrypted, even to root. I haven't tried it on VPS but I wonder if that would provide an additional layer of security against something like this attack, as maybe they would grab the ram key, but my user's home directory would still be encrypted inside that image. Actually I wonder if that's the case and systemd-homed works to encrypt the user directory would there be any benefits in using LUKS for the full drive over systemd-homed on the user's home?

Just feeling a little bummed right now that we don't have more protection for our data being leaked against these types of attacks even if we did everything right. Maybe this could push more providers to move towards encrypted ram, etc.

I don't know a bunch about this area and I'm still learning so please let me know if there's anything else I'm missing about how to further secure private data on a VPS if an adversary got hypervisor access.

MikeA · January 31

@lowendmeow said: However I am now feeling quite dismayed seeing that anyone with hypervisor access can trivially decrypt the key from the running ram of the machine, I would assume also the ransomware hackers would have access to this if they had hypervisor access.

Honestly actors compromising systems are probably not going to go through the hassle to do that on an individual VM basis. They just want money. Or to screw companies that made them mad.

lowendmeow · January 31

@MikeA said:

@lowendmeow said: However I am now feeling quite dismayed seeing that anyone with hypervisor access can trivially decrypt the key from the running ram of the machine, I would assume also the ransomware hackers would have access to this if they had hypervisor access.

Honestly actors compromising systems are probably not going to go through the hassle to do that on an individual VM basis. They just want money. Or to screw companies that made them mad.

Yes, I understand that realistically but it still makes me nervous if I had sensitive data on the VPS and was wondering how much LUKS/systemd-homed could help in this case. Also just because I'm interested in privacy and understanding and being informed about the realistic privacy limits I'd face using a VPS vs a dedicated server and what ways could I theoretically mitigate this. There's also scenarios for example where say a client decided to hold me liable for their data being accessed by a bad actor. If I could say, well I did LUKS encyption, also encrypted home directory, did X Y Z hardening, but at the end of the day if a bad actor accesses the VPS provider and hypervisor there's only so much I can protect against, it seems like I'd be positioned better legally. Probably above my paygrade but I'm wondering what the answer would be

somik · January 31

@lowendmeow said:
It looks like all these hackers wanted was to ransom the data, but this presents a security issue, like what if they

What if they what?!?

lowendmeow · January 31

@somik said:

@lowendmeow said:
It looks like all these hackers wanted was to ransom the data, but this presents a security issue, like what if they

What if they what?!?

Lol sorry to keep you hanging it's been a long day. Meant to say what if they were able to access and leak the personal data

tentor · January 31

If you are that much concerned about your data, I would recommend considering getting a physical server, doing LUKS here and never again thinking about malicious hypervisors.

If you want to complicate your life and use VM, you might want to look into confidential computing. Good starting point: https://virtee.io/

lowendmeow · January 31

@tentor said:
If you are that much concerned about your data, I would recommend considering getting a physical server, doing LUKS here and never again thinking about malicious hypervisors.

If you want to complicate your life and use VM, you might want to look into confidential computing. Good starting point: https://virtee.io/

Honestly it's more of just a thought experiment for me! Because I want to understand the technology and its limits.

Whoa thanks so much for this link! So this could be the future of truly secure VPS? Is it in a usable state? Do any providers provide this? What a cool idea! I hope it takes off

somik · January 31

@lowendmeow said:

@tentor said:
If you are that much concerned about your data, I would recommend considering getting a physical server, doing LUKS here and never again thinking about malicious hypervisors.

If you want to complicate your life and use VM, you might want to look into confidential computing. Good starting point: https://virtee.io/

Honestly it's more of just a thought experiment for me! Because I want to understand the technology and its limits.

Whoa thanks so much for this link! So this could be the future of truly secure VPS? Is it in a usable state? Do any providers provide this? What a cool idea! I hope it takes off

If it's a VPS, at minimum, there are 3 possible attack targets; the VPS control panel, the provider and your setup.

If it's a dedicated server, the possible attack target comes down to your provider (if they offer kvm over ip), and your setup. So if it's a server without kvm over ip, the only attack target is your setup. So always better to go with a dedicated server for better security. Use a VPS only for development or testing things.

skorous · January 31

(if they offer kvm over ip)

Or an interface has IPMI (mis)configured.

somik · January 31

@skorous said:

(if they offer kvm over ip)

Or an interface has IPMI (mis)configured.

Well, you'll probably be fine with top cloud providers. Go with AWS or OCI or GC or something like that.

ascicode · January 31

208.92.227.181:443
Possibel this

lowendmeow · January 31

@skorous said:

(if they offer kvm over ip)

Or an interface has IPMI (mis)configured.

What is the attack vector on dedicated devices if they have bad IPMI or KVM over IP? Would that be interfering with my unencrypted boot partition to keylog luks password etc?

somik · 11:23AM

@lowendmeow said:

@skorous said:

(if they offer kvm over ip)

Or an interface has IPMI (mis)configured.

What is the attack vector on dedicated devices if they have bad IPMI or KVM over IP? Would that be interfering with my unencrypted boot partition to keylog luks password etc?

If IPMI / BMC / KVM-over-IP is compromised or malicious, you should assume full physical-equivalent access to the machine.

That includes:

Pre-boot control: IPMI sits below the OS. A malicious BMC can tamper with the boot process before your kernel or initramfs ever runs.
LUKS password capture: KVM-over-IP literally sees (and can inject) keyboard input. Capturing the LUKS passphrase at boot is trivial.
Boot chain modification:
- Modify the unencrypted /boot partition (kernel, initramfs, cmdline)
- Inject a malicious initramfs that exfiltrates keys after unlock
- Persist rootkits that survive reboots
Virtual media attacks: IPMI can mount “virtual CD/USB” and boot arbitrary images without you noticing.
DMA-style attacks: Some BMCs can read/write system memory directly.
Firmware persistence: A compromised BMC can re-infect the host OS even after a clean reinstall.

Even if /boot is encrypted (or Secure Boot is enabled), a malicious BMC can still keylog or screen-scrape the passphrase during unlock unless you have a trusted input path—which you don’t over KVM-IP.

If the IPMI is bad, assume the box is owned. LUKS protects against lost disks, not malicious out-of-band management.

Edit: Post reformatted with LLM to make it easier to understand.

Shot² · 11:55AM

Using someone else's computer is okay-ish to store_ sensitive data_ (as in "life threatening"), as long as it's 1/ encrypted (efficiently, beforehand) and 2/ as backup (i.e. never to be decrypted there). Then, nasty guys can wipe/leak/ransomware/screw the data any way they want: you couldn't care less.

Otherwise it's simply a disaster waiting to happen...

lowendmeow · 9:39PM

@Shot² said:
Using someone else's computer is okay-ish to store_ sensitive data_ (as in "life threatening"), as long as it's 1/ encrypted (efficiently, beforehand) and 2/ as backup (i.e. never to be decrypted there). Then, nasty guys can wipe/leak/ransomware/screw the data any way they want: you couldn't care less.

Otherwise it's simply a disaster waiting to happen...

You mean e2e only? Because what I'm learning is that LUKS on a VPS provider that doesn't have non encrypted ram, as long as it's powered on could theoretically have VPS imaged, ram dumped and then LUKS is trivial to unlock

lowendmeow · 9:45PM

@somik said:

@lowendmeow said:

@skorous said:

(if they offer kvm over ip)

Or an interface has IPMI (mis)configured.

What is the attack vector on dedicated devices if they have bad IPMI or KVM over IP? Would that be interfering with my unencrypted boot partition to keylog luks password etc?

If IPMI / BMC / KVM-over-IP is compromised or malicious, you should assume full physical-equivalent access to the machine.

That includes:

Pre-boot control: IPMI sits below the OS. A malicious BMC can tamper with the boot process before your kernel or initramfs ever runs.

LUKS password capture: KVM-over-IP literally sees (and can inject) keyboard input. Capturing the LUKS passphrase at boot is trivial.

Boot chain modification:

Modify the unencrypted /boot partition (kernel, initramfs, cmdline)

Inject a malicious initramfs that exfiltrates keys after unlock

Persist rootkits that survive reboots

Virtual media attacks: IPMI can mount “virtual CD/USB” and boot arbitrary images without you noticing.

DMA-style attacks: Some BMCs can read/write system memory directly.

Firmware persistence: A compromised BMC can re-infect the host OS even after a clean reinstall.

Even if /boot is encrypted (or Secure Boot is enabled), a malicious BMC can still keylog or screen-scrape the passphrase during unlock unless you have a trusted input path—which you don’t over KVM-IP.

If the IPMI is bad, assume the box is owned. LUKS protects against lost disks, not malicious out-of-band management.

Edit: Post reformatted with LLM to make it easier to understand.

Good reminder about IPMI I don't expect it's bad on any of my providers but I do go in and change the LUKS password after I need to use it to set up or log in.

I don't know much about this but when doing some research with AI it was suggesting ukify and sbctl. I don't know much about using secure boot on VPS and honestly skip it on my personal computers because I've been installing linux on PCs long enough that I knew it would interfere with boot, I guess now some OS do have signatures that can work with secure boot and not all. I guess the idea sounds like you do encrypt boot and then it would let you know if something was tampered with in this case? No idea if this can be done in a VPS environment and especially since I don't know how the setup with dropbear unlock works if boot is encrypted

VPS security in the wake of the Virtualizor ransomware attacks

Comments