Virtual box privacy + data recovery concern

Discussion in 'sandboxing & virtualization' started by TheCatMan, Sep 6, 2013.

Thread Status:
Not open for further replies.
  1. TheCatMan

    TheCatMan Registered Member

    Joined:
    Aug 16, 2013
    Posts:
    327
    Location:
    sweden
    Hi was just wondering when I run virtual box and test different setups say windows 8, I set a virtual hdd space etc. But although this space is a virtual hdd, is it possible a data recovery could show any files or usage of that virtual instance ?

    example: running windows7, I install win8 iso under virtual box and then create a text or download an mp3 file, can a data recovery on windows 7 still show that text or mp3 file ?
     
  2. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    Yes, it's possible.

    This is a png inside a virtual disk:

    Untitled1.png

    Here is the same png as it looks on the real disk:

    Untitled2.png
     
  3. TheCatMan

    TheCatMan Registered Member

    Joined:
    Aug 16, 2013
    Posts:
    327
    Location:
    sweden
  4. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    I wonder how possible that is after restoring a snapshot.
     
  5. TheCatMan

    TheCatMan Registered Member

    Joined:
    Aug 16, 2013
    Posts:
    327
    Location:
    sweden
    I guess if vbox is using your normal hdd space as virtual space, it has to write its information onto so its able to be recovered like normal data is.

    tc would offer better protection or as suggested by another running everything in a ram drive, one could if they got 16gig ram, create a nice 8gig hdd ram drive and install ubuntu or other onto it. Upon reboot all data is lost and no chance of data recovery.
     
  6. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,030
    If your VM host machine is physically vulnerable, you must use full-disk encryption, and shut it down when you're not actively using it. You can also use full-disk encryption for VMs, but that's vulnerable to disk caching by the host.
     
  7. TheCatMan

    TheCatMan Registered Member

    Joined:
    Aug 16, 2013
    Posts:
    327
    Location:
    sweden
    Bit of a thread revival.

    I decided to test this out today.

    Installed a virtual box of linux saved the virtual disk on a separate hdd.
    I then used it and saved 30 jpg images, accessed about 20 different websites with 100s+ images.

    Then I tried 3 types of data recovery(all deepscan searches, one with vbox linux still running and one with it powered off (but not deleted) and last deleted completely from virtual box.

    Same results found as in nothing found at all ! Well it found the vdi disk image name and file but 0 bytes. I ran a deep scan of jpegs/html or any kind of file. It obviously was not able to scan inside the virtual box file....

    Maybe Virtual box has some kind of security or closed state to protect data leaks ?

    Either way to me its good news. I however would still advise to use encryption on your virtual disk. But its good to know data recovery is very difficult on virtual boxes and virtual images.


    Updated* turns out why I may have been getting poor data recovery results or just random data/0s was on I was using an SSD and with trim support it zeros out files.

    So encryption vboxes are still best plan forward id recommend to follow this well written guide here:

    https://www.ivpn.net/privacy-guides/creating-a-vm-within-a-hidden-truecrypt-partition
     
    Last edited: Oct 30, 2013
  8. TheCatMan

    TheCatMan Registered Member

    Joined:
    Aug 16, 2013
    Posts:
    327
    Location:
    sweden
    Further testing...

    Ran data recoveries within inside of virtual box, and yes data recovery works as normal.

    Running recuva deep scan with the hdd separate and external, the data recovery fails.

    Solution: you must use tc container on virtual boxes, recommend hidden tc container also.
     
Loading...
Thread Status:
Not open for further replies.