How can data from VirtualBox leak to the host and how to avoid it?

Question

I used a virtual machine (Windows host/Linux mint guest) to store some very sensitive and private data (it shouldn't be uncovered by state-level actors). Today I decided to check how much deleted files can be recovered from my host system using a popular disk drill software. After just few minutes of scanning I found out some recovered pictures from the guest machine! There were thumbnails (usually 256x124) of screenshots and telegram messenger pictures. All these compromising pictures had names starting with "GNOMEThumbnailFactory". There were also default wallpapers of my machine, that compromise plausible deniability I am trying to achieve.

How is this possible? Maybe these files leaked to swap file when Virtualbox used it, or Virtualbox loaded these files into some sort of cache? Also I used shared folder and guest additions (yes, I know that this is bad for security...), but I am sure that I didn't put all these images in shared folder and never sent them to host in any way. And is there any way to stop these leaks?

P.S. I also want to add that I had erased all free space on all disks with windows Eraser tool before I launched disk drill.

UPDATE: Thank everyone! I understood that I just forgot to remove the unencrypted copy of my virtual machine disk image. After removing it and leaving only the copy on the VeraCrypt encrypted partition my files recovering tool stopped to see VM's files.

Answer 1

You are doing it the wrong way around: you have an untrusted host system running a hypervisor and you are trying to run a trusted environment inside this untrusted host. But, the untrusted host system has more privileges than the untrusted VM - which means that access from the host to the VM is possible and also manipulation of the VM can be done from the host.

This includes access to the disk image of the VM, which is residing on the host system. Also the RAM of the VM is accessible from the hypervisor on the host system and might be inspected. In your specific case it probably just scanned the disk image.

There is not much you can do about this. While you could encrypt the disk image (i.e. full disk encryption in the VM), the key for decryption is in the RAM of the VM and thus can be extracted from the host.

The host/hypervisor is meant to protect itself from the VMs. And the VMs are meant to be protected from one another by the host. They are not meant to be protected against the host itself (there are some trends like confidential computing, which try to rely on less trust in the host). If you want to have a trusted and an untrusted system on the same hardware you could install a minimal trusted hypervisor which then runs both of these systems as a VM. Or you could run the trusted system on the host and the untrusted system inside the host as VM. But you should not run the trusted system inside the untrusted one like you currently attempt.

Answer 2

The data didn't "leak" onto the host. The data always was on the host to begin with. The files inside the guest are stored in the virtual hard drive file, and the virtual hard drive file is stored on the host's hard drive. Therefore, the files inside the guest are stored on the host's hard drive.

By analogy, if you have some cookies in a jar, and the jar is inside your kitchen, then the cookies are inside your kitchen. If somebody searches your kitchen, then they're going to find the cookies. You wouldn't ask "How did the cookies leak from the jar into my kitchen?" because the cookies always were in your kitchen to begin with.

There's no way to prevent this. The guest is part of the host; all of the data stored on the guest is stored on the host, and all of the computation performed by the guest is actually performed by the host. You could use whole-disk encryption on the guest, but that wouldn't help very much, because you would still need to type the password into the host in order to use the guest.

Answer 3

You don't give much details about the tool you used to discover the sensitive files, but many commercially available data recovery utilities can do much the same. The virtual machine disks are just files on the host system's hard drive, and the content in them can show up in such a tool when a "full disk scan" is run against the host drive. Being designed to help in case a disk was accidentally formatted and then reused, these tools typically read every sector of the physical disk and parse any file system structures they recognize, even if there appears to be multiple nested file systems, which would be the case with a non-securely re-formatted drive – or a virtual disk image occupying part of the host volume. Because of this file system reconstruction, the tool may be able to pull off files complete with their names from virtual disk images or "contained filesystems", as it has likely happened in your example. This explanation is consistent with your mention that you sanitized the unused disk space before performing the scan.

Using full disk encryption in the guest VM, this type of leak is prevented, as the virtual disk image will then consist of random-looking data from which no meaningful information can be extracted. However, while the VM is running, the encryption key will be present in the host's RAM, where it can be accessed by a determined opponent (such as a state-level actor you mentioned) if the computer is forcibly seized from you while powered on, or if the opponent manages to infect it with suitable data collecting malware. It should also be noted that if the guest VM's memory is allowed to be swapped, some of its contents may end up unencrypted in the host OS's swap file / partition, where it may remain to be discovered in a forensic examination even if both the VM and the host have been shut down. For this reason, full disk encryption should also be used on the host.

If you're under threat to have your equipment confiscated or tampered with, and possibly be personally coerced to give up your login details, a fully separated "hidden" operating system that you only use for the activities that might get you in trouble might be a better solution than the use of a virtual machine whose data could be observed from the outside (host) by means discussed above. VeraCrypt is one product that offers such feature; there may be others. Put in a concise way, the idea is that you can have different startup passwords for booting a "decoy" or a "hidden" OS, and if you're forced to reveal the password, you'll just give them the one for the "decoy" system, inside which the existence of a hidden one cannot be proven due to encryption. Read the documentation carefully if you decide to go this route.

Answer 4

Contrary to other answers here, the use of a Virtualbox guest in Windows is absolutely a valid way of making it more difficult for software outside the VM, and even for the Windows system itself, to get and tamper with information inside it. It is not a way to protect state-level secrets - for that you need to use a trusted OS. But if you have to use Windows anyway, then a VM is a way to make certain things safer. As an example, I don't want to give Windows access to my password manager, so when I am in Windows, my password manager resides in my Mint guest OS.

How much a VM can protect you depends on the level of attention you have attracted, and whether or not you've taken some basic precautions.

Precautions:

1. The most basic precaution is that the guest operating system MUST itself be encrypted. This is completely beside the fact of whether or not you use whole-disk-encryption or if your Windows OS is itself encrypted. Host or whole-disk encryption protects the entire system's data in case the computer is lost or stolen. Encryption of the guest OS protects the guest's data from other software and (to an extent) from the OS itself. Otherwise the guest is sitting inside an image container which is itself just a large file in Windows. That file makes up sectors on your hard drive, like any other file. This is how your recovery tools found the images. The tool was doing a sector-by-sector scan of the host OS looking for sectors that have data with jpeg (or other image format) signatures. This scan didn't care if those sectors were inside a guest OS container file. Most good Linux distros offer encrypted installation using LUKS. If you have swap, make sure that is encrypted too.
2. The next most important precaution is swap. As you identified, swapping can be a way for information to leak out. Remember that the guest swap is independent of the host. If the host becomes low on memory, then the guest's VM RAM usage is a big juicy chunk of RAM to swap out. You want to keep the memory assigned to the guest small enough that the host won't want need to swap it out. When the guest is active, avoid memory hungry activities outside on the host.
3. If you use a VPN inside the guest OS, then network information flowing into and out of the VM will be end-to-end encrypted and more difficult to intercept.

If these precautions are followed, then a VM can offer some protection. It can protect against:

• Some forms of automated memory scanning, even when the scanning process has access to all memory since many of those tools are looking for Windows process markers.
• Process monitors - most process monitors hook into Windows API calls and won't notice Linux processes being created and terminated
• Most forms of TCP/IP interception (when a VPN in the guest is used) hook into the Windows stack, and not into CPU data flow. This means that VPN data is safer from monitoring from outside the VM.

It must be noted that a VM makes it more difficult, but not impossible to intercept what is happening. You are still working with a Windows OS. Every key press, mouse movement, and pixel being displayed on your screen goes through the OS. A VM will not protect you from key-loggers. It won't protect against an opponent who knows or expects a VM to be used and makes tools specifically to look for that.

That all being said, it does offer a measure of protection from casual monitoring. It certainly doesn't make it less safe.