9

I generally do all of my web browsing in a VM. I have one "safe" VM running Ubuntu that has guest services installed. I generally only go to sites I deem are trustworthy here.

I also have an "unsafe" VM with Ubuntu that does not have the guest services installed.

Tonight I was using the unsafe VM to browse some less than savory areas of the internet when one of the annoying FBI popups occured. No big deal...and then I see Norton from my host machine pop up with a blocked action on C:\Windows\SysWOW64\vmnat.exe. The alert name was "Web Attack: Ransomlock Website 7" and it came from the fake fbi website in the popup. This may not be important...but as an FYI I was using Chrome to surf.

I don't fully understand the VMware NAT system, but does this sound like malware could have leaked from the VM onto my host, or does Norton have insight into what vmnat.exe may have been calling and sending back to the VM.

I mainly just want to make sure my host is "safe", but I am also curious as to how this works.

Improve this question
1
  • It's as secure as the hypervisor/virtual machine software that you use. If there's a flaw in it, it can be exploited by malware running in the VM to break out of it and execute malicious code on the host. – user42178 Jun 19 '14 at 19:00
6

vmnat.exe is VMware's virtual networking service: all network data going to or from a guest OS using NAT networking passes through it.

Norton can't see inside your VM. Instead, when a program inside the VM does something, Norton sees the virtualization software performing that action. In this case, when your virtualized browser tried to download the "Ransomlock Website 7" malware, Norton saw vmnat.exe downloading it, but didn't see that the data would then be handed off to a virtualized OS that couldn't be harmed by it, so it blocked the download.

Yes, it's possible for an attack to break out of a virtual machine, but it's very, very rare.

Improve this answer
1
  • 1
    I find it disturbing that there are so few disclosures of VMware vulnerabilities that allow allow an attacker to gain access to the host, or other guests. Either the vulnerabilities are kept secret, fixed in silence or there are none. I put my coin on the first option. – Dog eat cat world Jun 19 '14 at 8:56
2

Let us first tackle the VM network. An external address, usually routable, is the "outside" of the NAT. The machines behind the NAT have an "inside" address that is usually non-routable.

Bridged mode acts just like the interface you're bridging with is now a switch and the VM is plugged into a port on it. Everything acts the same as if it were another regular machine attached to that network.

If you are in a bridged mode and a malware infects it then it can read your routing table and can identify your network range to pivot into other machines. Now coming to the infection. Ransomeware is a typical malware that locks your machine upon infection. The images you saw on your screen were all fake. If you had noticed it must be asking you to pay some fine to unlock your computer. This is a trick that ransomware applies to steal money. One of the ways ransomeware reached your machine was that the website you were browsing was hacked and an invisible iframe must be injected that redirects you to a browser exploit thus dropping and executing the malware onto your system. Its a good move that you have separate vm for different browsing activities. If you keep them in a NAT network mode then the infection will only stay inside the VM. You can imagine what would have happened if ransomeware have had locked your host os .

Improve this answer
0

Also note that [for instance with VirtualBox (on Win)] the "default" image for docker-machine typically creates a Share folder with all of /Users so that would also be bad (and something to make sure is not happening), NAT or not. Still that mounted write by an infection would potentially be stopped by anti-virus as mentioned earlier.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy