Hardening VBox for high risk scenarios.

[lopope]

Dear forum,

I am currently in process of designing a template which will be used extensively in high risk situations by some of our employees (malware research, journalism in certain countries, other adversaries).

If you already read about Whonix, that's basically the same thing - just with more bloat attached to it.

1.) Gateway VM with two NIC's, one connected to the isolated internal network, one bridged to the host network interface, running a Tor client.
2.) Workstation VM with a single NIC connected to the isolated internal network, forcing all traffic over the gateway VM.

My goal is to prevent the discovery the users real IP address, at any cost.

By default, this should work fine - since all work will happen within a VM only connected to a virtual isolated network.

Regarding my setup (Windows Host, Linux guest) , I have a few questions:

a.) What are the risks of running Guest Additions, considering I am only loading the vboxuser and vboxvideo kernel modules?

I am aware of the /dev/vbox{guest,user} character devices - I already added a udev rule to prevent access to either as non-root user as I don't run any of the functionality which would require them.

I didn't actually look at the callbacks registered in the driver, but surely a compromised virtual machine (up to the point of gaining root priviliges) could send spurious requests causing the host to trip over and possibly allow compromising such through unknown vulnerabilities.

b.) According to my knowledge, the guest additions side channel is always exposed to a virtual machine.

If I decide to drop the guest additions completely, is there some config option to close / disable said side channel for the sake of hardening my virtual machines?

I might be completely wrong here so feel free to correct me on any mistakes I did.

c.) Is there any guest-to-host backdoor / sidechannel which somehow could enable a VM to do network config changes on-the-fly?

All replies are greatly appreciated

Best Regards,

John

[xahare]

This is what qubes os is for.

It comes with whonix already integrated, along with its own linux templates. you can also make windows templates or stand alone vms.

[lopope]

...

I am afraid but your reply is completely useless, my thread title clearly says "VBox" and I'm not able to use any other hypervisor.

Refrain from posting if you have nothing on-topic to contribute, thanks.

Regards,
John

[mpack]

If I decide to drop the guest additions completely, is there some config option to close / disable said side channel for the sake of hardening my virtual machines?

Quick answer: not that I know of.

However, let's back up a step. Presuppose that someone has written malware specifically designed to exploit a VirtualBox VM. Which vulnerability in the GAs API did you have in mind for this hypothetical malware to use? Because if there isn't a vulnerability then there no point in turning the API off.

Set that aside.

Next question. How did that malware get into the VM? I appreciate that in your scenario you introduced it on purpose, but I don't think the devs would consider intentional sabotage by the VM user as being worthy of high priority attention. For the non-intentional case the vector would have to be via the host, meaning the host is already infected, meaning the question of how VM malware can infect the host is somewhat moot? I guess that if you assume a network connection then infection of the VM is possible, but if you have a network connection then I'd worry about that before I worried about the GAs API.

[lopope]

Now, I am not aware of any unfixed vulnerabilities in the GA API's and I'm unfamiliar with the actual implementation of such - however, having them enabled with no intended use case seems like overhead to me (the Venom vulnerability comes to mind, even though that did affect a completely different component) - a custom compile disabling unwanted features will do probably, once I had time to actually look at the the code and implementation.

Non-intentional infection of a VM not used for malware research might happen due to all kind of targetted or non-targetted attacks - it has full internet connectivity after all, the only difference is that all traffic is forced through second gateway VM on an internal network which in turn forces it over the Tor Network, preventing direct WAN connections.

Now for that use case this would first require a vulnerability in some piece of software connecting to the internet allowing possible adversaries to compromise the virtual machine at all, and then a working exploit to gain root privileges - after gaining access and root priviliges, they would be free to hack away at the hypervisor and attempt breaking-out of the virtual machine.

[scottgus1]

...

I am afraid but your reply is completely useless, my thread title clearly says "VBox" and I'm not able to use any other hypervisor.

Refrain from posting if you have nothing on-topic to contribute, thanks.

Regards,
John

A person who asks for help and has only three posts should be more polite with folks who try to help, even if the help is off topic. That door-slam was far too unnecessary, Lop. After all you did say:

All replies are greatly appreciated

A nicer way to put that would have been, "Thanks, xahare, for the info. Unfortunately I can only use Virtualbox (maybe I should have written that in my huge first post )"

As for your subject, I also have been curious about using Tor and avoiding leaked IP addresses. You seem to have much more a grasp on the malware types, and I have just been reading up on the subject. What I have read has shown me that Tor can't block everything. At least torrent clients can get around it in certain circumstances and reveal the real IP address of the user. The Tor browser itself says not to install any add-ins or the real IP address can be leaked.

As for Virtualbox & Guest Additions, the only way you can know if there will be a leak is to only use the parts of the program that have open source code, and go through the source code line by line looking for possible IP leaks. Even then you may not be able to see the nuances of the running code. And as Mpack has stated, injected malware can do things that have not been planned for (Just look at the Windows security-hardening issue that cropped up around VB 4.3.12: it had been there all the time and only by 4.3.12 did some eagle-eyed individual spot it.)

I would simply set up a test lab and Wireshark it (or some other such tool) under the circumstances I expect to take place. And get peer reviews of my setup, too; that's where the eagle-eyed folks are. And never expect the complete 100% ain't-never-gonna-happen revealing of the real IP address - the only way to do that is to not have a real IP address, and the only way to do that is to not be connected.

In fact, thinking about it a bit more, I would say that the best way to give your employees a Tor-enabled pathway to your desired information is to just put Tor on their machines (or in a VM if you want) then make a website/server/RDP-source at your workplace that is usable within a web browser. Have your employees contact your servers only within the Tor browser <- this is the key. Any other software you stick into the mix may compromise the real IP address.

[lopope]

Scott,

the dangers with torrenting you talk about don't apply here - the only interface exposed to the virtual machine used for work is an internal one, providing connectivity to a virtual network on which the Tor client sits, accepting connections ONLY on the socks port - everything else is firewalled even if it shouldn't matter. TCP traffic is redirected through Tor's socks port (IPTables and certain tools available on most distros required), everything else flows through a random OpenVPN server which supports TCP connections (once again through Tor).

That setup will, by default, completely prevent by IP leaks, the system doesn't know it's public IP address and has no way to acquire it - the only network connection it can make, to the outside world, is through Tor's SocksPort.

Now, regarding the guest additions I did partially look at the implementation, there is no functionality which would allow IP leaks per se. Undiscovered vulnerabilities are a different story but as long as you only use the video component and maintain a healthy, secure guest OS the risk seems minimal.