Can malware in the guest access NON-shared folders?

[UlyssesOfEpirus]

I do not mind if shared folders are written to by any malware running in the guest, but is it possible that malware can also access folders other than the shared ones?

Can malware running in the guest do anything else to harm the host, other than messing with the contents of the shared folders?

[AntonVZhbankov]

If you mean HGFS shared folders then there is some other possibility. Standard Windows shares, including hidden - if guest can access then then malware have access to them.

---

MCSA, MCTS, VCP, VMware vExpert '2009

http://blog.vadmin.ru

[wila]

Hi,

It is best to NOT give a test virtual machine that runs malware direct access to your network.

Are you sure that all your network machines are 100% patched?

If your test VM needs network access, then do so by using a separate network segment for the VM.

Also make sure that you are running the latest VMware products completely patched is a must in this type of case.

The HGFS shares are probably the safest to use, but there have been several directory traversal exploits in the past and I'm not sure if I would want to risk my host on that part.

If you need to share files to your malware guest then consider putting those files on a virtual CD Image.

If you need to get files from your malware guest, then you can always attach the disk to another VM when the guest has been shut down.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[UlyssesOfEpirus]

1. Hidden shares are C$, IPC$ and ADMIN$ ? Will windows still function properly if these hidden shares are removed? If yes, how do I remove them?

2. Would HGFS shares be any faster than normal windows networking shares over a virtual ethernet adapter?

[UlyssesOfEpirus]

Thanks wila, I only use virtual machines for secure browsing, and occasional access to the host is only for saving downloaded files and bookmarks. This file access is done through a separate network segment as you are suggesting, using the host-only network and netbeui instead of tcp/ip.

You said "If you need to get files from your malware guest, then you can always attach the disk to another VM". I'm not sure I understand this. How do I get files from the malware guest and write them onto a CD .iso image without using shared folders?

[UlyssesOfEpirus]

Instead of HGFS shared folders, would it be more secure to use "hot-pluggable" SCSI virtual drives and read them from the host using the vmdk mount tool?

Anyone know how to hot-plug/unplug SCSI virtual drives without switching off the VM?

[Texiwill]

Hello,

If you are using ESX/ESXi (Type 1 Hypervisors) then hgfs is NOT possible to be used and actions within a VM have very little chance of infecting the ESX OS.

If you are using Workstation, Fusion, Player, or Server (Type 2 Hypervisors) then hgfs may be used and yes it would infect the host. If you use hot plugged virtual disks and then open then on the host, then yes there is a chance to infect the host. Basically, your 'host' should never open a virtual disk directly, or allow direct access from a VM for better security. Actually all the guides say to disable this type of ability.

The act of opening a virtual disk could infect depending on how it was opened. Forensic scientists have this same problem, when they open a hard drive for analysis they do so on a completely reinstalled forensic workstation. They may reinstall between each analysis in order to cut down on cross contamination. It is just not safe to open virtual disks or hard drives if you know there is malware using critical systems. The critical systems are virtualization hosts, backup servers, management nodes, etc.... I would use a forensic workstation only, or perhaps a forensic virtual machine.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[UlyssesOfEpirus]

Thank you very much. ESXi seems to be the way to go then, I hope the ESX OS works on my hardware.

If I understand you correctly, even just the act of reading an infected hard disk can execute malicious code.

Hasn't anyone thought of a workaround so they can save data from the browsing VM onto the host without executing anything? What about saving the data onto a physical CD and disabling autorun, would that work?

[UlyssesOfEpirus]

Is there any filing system that makes it impossible to execute anything that resides on it, for example if there is no MBR or partitions and data is written to every single sector?

[Texiwill]

Hello,

There are virus' that infect the fielsystem not a specific program, opening a file system infects the machine. There are virus' that infect a program, executing said program infects the machine. THere are virus' that live in 'data', opening the data infects the machine.

Read-only media may work if what you write is virus free at time of write. Not it can not be infected, but there are virus' that could live in data on the CD and still infect a machine.

ESX/ESXi is safer than others, but also is good management. If you are unsure of WHAT is in a VM, then do not do analysis on the host, use a VM to do the analysis or another host.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[UlyssesOfEpirus]

Of course an .exe can contain malware so you won't execute it, and of course a filing system can hold malware in its boot record, so I wonder, hasn't any of those bright sparks at VMWare thought of a way to transfer data to the host safely? In other words without anything infected executing itself automatically, but only when the user explicitly executes it? Why is a boot record needed anyway, cd's don't have a boot record and I thought the boot record is where the automatically executed malware lives, or in .doc files with macros (that you can disable). Where else, what other data can malware live in so it can execute itself automatically without the user's consent?

[Texiwill]

Hello,

This is not really a VMware issue, it is an Operating System issue and how it reads the file system, virtual disk, or a file.  This is why there exists physical write-block devices as well as write-blocking software for an operating system. Forensic scientists use them as well. With a VM you can mark a virtual disk read-only. However virus' can infect memory and whatever is writable could be written to. SO extreme care should be taken when investigating virus' laden virtual machines/physical disks.

I would just NOT use the virtualization host's operating system as a Forensic workstation, use something entirely different on a private firewalled network and you should be fine.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[UlyssesOfEpirus]

So are you recommending to do forensic analysis on the entire VM every time I want to save a picture or video from the browser appliance to the host?

No way to isolate the picture and save it without anything being executed?

We do not mind if a picture is holding the data of a secret message or virus executable bytes by means of steganography, as long as the code does not ever get executed we can live happily with it.

[Texiwill]

Hello,

If you save a file to the desktop of a VM and are not using a 'shared folder' as seen by the host and the VM (whether network, or vmhgfs) then you should be just fine. The key is to never share a disk between a host and a VM.  You did state a VM with known malware in it.... Which if you opened that VMs disk within the host using standard tools and made that file system available to the host either via vmhgfs, network means, or direct writes to a USB stick, which you then attach to the host, then yes you can infect the host.

The standard 'download' and save to the VMDK will NOT infect the host. The rules of 'infection' do not really change all that much. A guest cannot directly infect a host unless you are 'sharing' data/filesystems with the host, which is not the default configuration.

Also, run a virus/malware scanner on any media you do share anything between a VM and a Virtualization Host.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[UlyssesOfEpirus]

I guess doing everything in a browser appliance is not so bad after all, you can still run all your applications like video editors and Ms Office in the VM, even if it's infected. And if you get a nasty infection that formats your virtual drives, you dump the VM and get a new one.

Except then you lose your data, and all work done. Which brings us back to the previous problem, how do you isolate your data and back up just your data onto external media.

Backing up the .vmdk of the entire VM with all apps installed is not an option for me, it would take 6 GB just for the system drive and a gig or two or more for data like videos. And it's just not sound practise to keep backups of infected VM's.

[wila]

Hi,

>Which brings us back to the previous problem, how do you isolate your data and back up just your data onto external media.

You can treat a VM like a real machine and create a data disk and save all of your data on that disk. Then you only have to backup that particular disk.

--

Wil

_____________________________________________________

VI-Toolkit & scripts wiki at http://www.vi-toolkit.com

[UlyssesOfEpirus]

This may be the most secure thing to do. And it represents such a deviation from my habit of mind ("data in physical drives, internet functionality in VM's"), that it would take some getting used to.

Can someone tell me why the vmdk mount tool would make a drive that will automatically execute any code in the master boot record of the vmdk? After 20 years of boot sector viruses, hasn't anyone thought of a way to delete them before reading the partition table?

[Texiwill]

Hello,

Can someone tell me why the vmdk mount tool would make a drive that will automatically execute any code in the master boot record of the vmdk?

You are 'mounting' the virtual disk as if it was a regular disk. Consider the VMDK just like it was a USB stick, you insert the stick with a virus on it and you may have infected your host as well.

After 20 years of boot sector viruses, hasn't anyone thought of a way to delete them before reading the partition table?

Before mounting anything run AV on the VMDK and see what shows up. Some of the AV tools can look inside a VMDK using the vDDK. TrendMicro does this for ESX, should be able to do it for other VMDKs, but you would have to contact them.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[UlyssesOfEpirus]

But still it makes no sense that MBR code is executed for a disk that is not the boot disk of an operating system being booted up. No operating system is being booted when you mount a usb drive, no operating system is being booted when you a mount a vmdk. Why do you believe malware in the MBR would be executed when you just mount a vmdk?

[oreeh]

Because that's the way some operating systems are designed ...