Are Servers on VMs are Safe from Ransomware ?
-
It's also possible that he is actually referring to thin clients and not VM's
-
I take the stance of if it is a computer, and has an operating system, then yes, it can be affected by ransomware and I protect it as such.
-
In the case that someone shared from reddit yesterday, the hacker got on one system and then installed a password cracking tool on the VM to scan for other passwords on the network. To answer @openit 's question, it makes no difference physical or virtual.
So far we haven't seen a case where if a VM gets hacked the attacker gains access to the hyper visor unless passwords are shared, etc.
-
@dafyre Yeah of course. My point is that is doesn't make it MORE susceptible to ransomware because it's sharing hardware. It is for all intents and purposes (ransomware wise) a standalone machine.
-
There have been exploits in Xen & VMWare & Hyper-v where if a guest VM is breached, the attacker can get to the host and therefore, other VMs. @Mike-Davis
-
@Breffni-Potter said in Are Servers on VMs are Safe from Ransomware ?:
There have been exploits in Xen & VMWare & Hyper-v where if a guest VM is breached, the attacker can get to the host and therefore, other VMs. @Mike-Davis
Interesting. I'll have to look that up.
-
@Breffni-Potter Can you show some examples? I would have thought there would have been all out data center panic. Can you imagine one Azure VM having access to all the VMs on that host? I'm thinking that would be front page news.
-
Different alerts have been posted on this site guys, This is why we update and patch and watch for notices from vendors.
Exploits have and are found on a regular basis, the vendors then patch like lightning to prevent it.
You can do your research and google your hypervisor of choice to see previous patched vulnerabilities.
-
@Breffni-Potter said in Are Servers on VMs are Safe from Ransomware ?:
Different alerts have been posted on this site guys, This is why we update and patch and watch for notices from vendors.
Exploits have and are found on a regular basis, the vendors then patch like lightning to prevent it.
You can do your research and google your hypervisor of choice to see previous patched vulnerabilities.
Thanks for sharing that. It seems an unpatched system is a vulnerability no matter where it is.
-
@wirestyle22 said in Are Servers on VMs are Safe from Ransomware ?:
@Breffni-Potter said in Are Servers on VMs are Safe from Ransomware ?:
There have been exploits in Xen & VMWare & Hyper-v where if a guest VM is breached, the attacker can get to the host and therefore, other VMs. @Mike-Davis
Interesting. I'll have to look that up.
VMware had one happen just this past week.
-
@Mike-Davis said in Are Servers on VMs are Safe from Ransomware ?:
@Breffni-Potter Can you show some examples? I would have thought there would have been all out data center panic. Can you imagine one Azure VM having access to all the VMs on that host? I'm thinking that would be front page news.
It was pretty big news last week when it was demonstrated on VMware. I've not heard of it on Xen.
-
@Mike-Davis said in Are Servers on VMs are Safe from Ransomware ?:
Thanks for sharing that. It seems an unpatched system is a vulnerability no matter where it is.
That has always and will always be the case.
-
@Breffni-Potter said in Are Servers on VMs are Safe from Ransomware ?:
Different alerts have been posted on this site guys, This is why we update and patch and watch for notices from vendors.
Exploits have and are found on a regular basis, the vendors then patch like lightning to prevent it.
You can do your research and google your hypervisor of choice to see previous patched vulnerabilities.
Important to note that in this example, it was not the VMs or the hypervisors that were compromised. It was a shared storage device that was hit through the driver. It's a risk of loaded drivers and it was a floppy driver, so not expected to be seen in production.
-
Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened. An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, possibly, the hardware features on which the VM builds on. There are few exit routes for data out of the VM; e.g., for Internet access, the VM is emulating a virtual network card, which deals only with the lowest level packets, not full TCP/IP -- thus, most IP-stack issues remain confined within the VM itself. So bugs leading to breakout from VM tend to remain rare occurrences.
There are some kinds of attacks against which VM are very effective, e.g. fork bombs. From the point of view of the host system, the VM is a single process. A fork bomb in the guest will bring to its knees the scheduler in the guest OS, but for the host this will be totally harmless. Similarly for memory: the VM emulates a physical machine with a given amount of RAM, and will need about that amount of "real" RAM to back it up efficiently. Regardless of what the guest does, the VM will never monopolize more RAM than that. (You still want to limit VM RAM size to, say, at most 1/2 of your physical RAM size, because the extra "real" RAM is handy for disk caching; and the host OS will want to use some, too.)
Taken into account that malware/ransomware is implemented on the file level, the best method of protection would be based on a block level recovery tool.
In addition, the best way to overlook the possibility of loosing your data would be the implementation of the the 3-2-1 rule. Its a quite common safety measure in the data infrastructure. We actually implement it quite often, it is based on the replication of your data between 3 nodes as well as creating 2 real-time replication copies of the data between the nodes and storing a single copy of your data in a VTL on the cloud.
For any other additional information, I would like to suggest you to take a look at the following article - https://knowledgebase.starwindsoftware.com/explanation/the-3-2-1-backup-rule/
