Isolating Untrusted Virtual Machines — 1
I have used VirtualBox since the original Innotek days. Each release provides additional features, several of which I have yet to explore. Throughout those years, the VirtualBox developers never provided a way to keep untrusted virtual machines (VMs) truly isolated from the host while concurrently providing access to the web. Access to the web is necessary to keep systems updated. Isolation is a basic security layer.
Let’s get the political incorrectness out of the way. For me untrusted means Windows. This is especially true with Windows 10 where a lot of telemetry information is transmitted to the mother ship. End users do not know what information is being transmitted.
By design virtualization platforms isolate guest systems. Yet detecting that an operating system is running inside a virtual environment is common nowadays. Detecting a virtual environment does not in itself reveal anything about the host, but opens the door to old-fashioned curiosity. Especially when that curiosity is malicious.
VirtualBox NAT mode seems to isolate the guest system because the guest IP subnet is different from the host machine. Yet the guest has access to the host. This is easy to verify. Despite being on a different subnet, run the ping command against the host machine IP address. The VirtualBox networking engine internally routes the guest subnet through the host subnet.
Another challenge is using a local DNS name caching server. Running ipconfig /all in a Windows VM exposes the local DNS server, which exposes the subnet of the host.
Malware authors could port scan all private subnets to discover the host and LAN.
VMs do not isolate disk partitions when using raw disk mode. VMs can see all partitions although non assigned partitions are restricted to read-only access. That provides another possible avenue for discovering information about the host or LAN.
How much of a security threat is an ability discover the host’s IP address? Probably zilch. While occasionally exploits are discovered, the flaws are promptly patched. Virtual machines are big business. Not patching such flaws would kill business.
Yet the bottom line is the host is discoverable.
Despite being a Linux based household, despite the unlikelihood of exploits, I have several seldom used Windows systems. All running inside virtual machines.
Three systems are pre XP. I am not worried about these VMs being untrusted or hostile.
Other Windows systems include two XP systems, one of which came preinstalled on my Lenovo Thinkpad T400 laptop. As soon as I bought the laptop I shrunk the XP partition and installed Linux based systems. Last year I copied the laptop XP partition into a VirtualBox VM.
I have Windows 7 and Windows 10 installed on a refurbished HP system. Also installed on that HP system is Ubuntu MATE 16.04. The HP machine is isolated from my LAN through a router VLAN port. Thus even if the proverbial Hell broke loose on this machine, nothing on my LAN should be affected.
I access the HP and laptop XP Windows systems only through a VirtualBox interface using raw disk access. None of these Windows systems are available through the GRUB boot loader. I use the default VirtualBox NAT network configuration to allow the systems to update from the web.
Access to the laptop XP system is for show-and-tell when others want to see an example of virtualization. While I disconnected the virtual network cable on the laptop virtual XP, I cannot do the same for the Windows 7 and 10 systems as long as I want to receive updates.
I do not run the HP system often. I have no need or desire to run Windows 7 and 10 other than as curiosities. In addition to the VLAN port, the Ubuntu MATE system on the box is a prophylactic to keep the two Windows systems isolated. I keep the Ubuntu MATE system updated but only about twice a month do I bother with the exercise. At that time I then update Windows 7 and 10.
The Microsoft folks started spying on customers at least as far back as XP. The XP file manager and media player maintain contact with the Microsoft mother ship. Not to forget a slew of third-party apps. I consider the two XP systems and the 7 and 10 systems as untrusted and hostile. Not to forget malware magnets — although I rarely install third party software outside of free/libre apps.
The VirtualBox security challenge is when an untrusted system is infected with malware the host machine is discoverable as would any LAN the host is a member. Ransomware comes to mind as a threat example. Ransomware is designed to encrypt all accessible data files. While a Linux based host probably provides more safeguards than a Windows host, the day will come when such malware is designed to target Linux users too. Thinking ahead proactively is healthy security. Skilled ransomware authors are not stupid. They know people might run untrusted systems in VMs. I fully expect ransomware authors to one day to attack host systems.
I am not interested in testing malware or running a malware lab. I only want to isolate untrusted operating systems. There is a simple argument that an untrusted system should not be installed or used. Point taken, but sadly Windows is a requirement for many professionals. The design of Windows 10 has exasperated the topic of trust. My effort to isolate Windows 7 and 10 by running in a VM and through a VLAN is a start. I am only focused on whether I can further isolate these systems.
According to the VirtualBox user manual, improved isolation from the host requires using other network modes, but those modes do not allow concurrent access to the web to perform updates.
One possible option is using Host Networking, then adding iptables firewall rules in the host. This method might prevent discovering the host, but not from discovering the subnet router. Thus an untrusted guest can discover the subnet used.
NAT Networking Services fails to fully isolate because NAT in the VirtualBox environment always exposes the host IP address.
That leaves the Internal Network option. By design the Internal Network option is intentionally crippled. The design presumption of the Internal Network is complete isolation from the host. There are no built-in VirtualBox DHCP, DNS, or routing servers.
To provide access to the web for systems on an Internal Network requires creating a separate VM on the same internal network to act as a gateway and router. The gateway VM would have two network cards, one for the internal network (LAN) and the other to interface with the host (WAN). The host WAN adapter could use VirtualBox NAT or Bridge mode. IP forwarding would allow the internal network VMs web access.
Some administrative challenges arise because I seldom run these untrusted VMs. After configuring an untrusted Windows system for an internal network, providing web access on these systems means concurrently running the trusted gateway VM. A script wrapper would allow me to query a text file for a list of untrusted VMs. When a VM is tagged as untrusted, the script wrapper first starts the gateway VM before starting the untrusted VM. Or the trusted gateway VM could be configured to autostart with the host system. Either option is doable.
More administrative trickery is needed when powering down a physical machine using these VMs. VirtualBox drivers on the host are designed to intercept calls to log off or power down a system. VMs need to gracefully power down before powering down the physical machine.
A second script would provide me a graceful way power down VMs. Thankfully, I have already resolved the graceful power down challenge when I configured an apt proxy server VM on my LAN server.
Whether there is a return on investment with trying to isolate untrusted operating systems with VirtualBox remains to be seen. A likely caveat with isolation is the VirtualBox Guest Additions should not be installed. That means reduced video resolution for desktop systems at 1024x768 at best, no shared folders, or bidirectional clipboard. As the versions of Windows 7 and 10 I am using are desktop systems, this lack likely would be frustrating if I actually had to use either system for production.
This all sounds plausible and doable, but questions remain. Does a gateway VM truly isolate the host or the LAN the host is connected? Can an untrusted VM operating system still discover anything about the host or underlying LAN? To what extent can Guest Additions be used without exposing the host or host’s LAN?
Seems that for this to be successful requires two objectives:
- The guest VM cannot ping or port scan the host or any IP address on the host’s subnet.
- The guest VM does not find any local DNS server.
More to follow.
Posted: Category: Tutorial Tagged: General, Ubuntu, Windows
Next: Isolating Untrusted Virtual Machines — 2
Previous: Struggling with Thunderbird