Wednesday, July 8, 2015

Do VMs Provide a False Sense of Security?

I think I finally figured out how my computers keep getting hacked. This past year it's happened three or four times, forcing me to completely reinstall my system, and frustrating me to no end because I could not figure out what I was doing wrong, or not doing right. I'd like to think my security practices are pretty good. My friends consider them excessive and totally unnecessary (like when a guest needs the WiFi password and I'm like "ughhhh.... yeah....hold on.")

Until recently I never gave much though to the idea of securing Virtualbox. After all, the main reason I use VM's to begin with is so that I can run an insecure O.S. like Windows securely, inside a contained environment. Than I started playing around with Metasploit, and after a while I started to wonder what would happen if I migrated a meterpreter process to the vbox guest additions process on the guest. What would I be able to do from there? I don't know because I have not actually tried it, but it seems like that would be a good entry point for a hacker to break out of the VM and wreak havoc on the host. I started to think about how the vbox guest additions package works, and what it's capabilities are. It allows the guest machine to access 'shared folders' on the host, allows 'mouse integration', allows the guest to take advantage of the host system's GPU to improve graphics, and a lot of other things.

When you install it inside a VM, Virtualbox does not ask the user of the host computer for permission to access the resources provided. It does warn you that bad things could happen if you install the package, but if you import a VM that already has the guest additions package installed, than you won't even see that warning. So what is to prevent rogue software from interfacing with whatever server interprets commands from that package? Or what prevents a piece of malware present on the guest system from interfacing with the host system through a preinstalled guest additions package? What kind of safegaurds are in place to protect the host during a scenario like that? Virtualbox runs as root, and the program even has the setuid bit enabled by default.

Even without the guest add-ons program, Virtualbox can do a lot of interesting things with the host system, as is. It can create virtual network adapters that will grab their own IP address's from the host systems router, completely bypassing any NAT safeguards present on the host, allowing them direct access to your LAN. If you enable the USB integration feature and set the permissions, than Virtualbox can be configured to interact with any USB device connected to the host. On my computer, the webcam is actually connected through a USB controller, so that could be a scary situation indeed! These are just a couple hypothetical scenarios, but when I put all this together it seriously makes me wonder if Virtualbox is anything close to the safe sandbox for insecure systems that it's perceived to be. Than consider that if you are running Windows in a VM, you probably pirated it, as Windows does not officially support virtualization (afaik).

So what can be done about this pickle? Well, I am a big fan of chrooting untrustworthy software. For example, even though Firefox is an awesome browser, and one of the more secure ones, I still run it in a chroot because otherwise, the browser has access to anything that the user it's running as does. That means a compromised browser=a compromised system. Since client side web exploits are very common these days, I always run my browser in a chroot. I've been doing that a while now, and it's worked quite well, which brings me to the point... From now on I will only run VM's from inside a chroot, on a separate partition, and without the guest additions. A good App Armor policy should be able to prevent malware from talking to Virtualbox through the guest additions server.

If anyone has written or knows of a really good Virtualbox AA policy, please do comment and share it with me. That's all for now.

No comments:

Post a Comment