I stumbled upon something the other day that i think will be critical for most penetration testers. Chances are, you run many VMs which are responsible for carrying out a variety of tasks during a penetration test. Linux for attacking, Windows for reporting/attacking, etc. whatever. I use a windows box to do my reporting, because, lets face it, Office for Mac sucks and I have more Microsoft Office licenses then I know what to do with. Therefore, I eventually need to move all of the files and data from my many other VM's to an encrypted vault on my Windows VM for consolidation, screenshot editing, etc.
...until the next paragraph.
Last week I was finishing up a test and conducting some routine clean-up of my Windows reporting VM. As a part of my regular clean-up, I conducted a search for .DS_Store files on the Windows VM local disk. This helps me identify items transferred from my Mac that I may have missed. While I fully expected a few instances of the file to be found in the mounted, encrypted volume and maybe in a folder or 2 on the primary drive, what I saw alarmed me. Several dozen instances of the .DS_Store file in various folders underneath c:\Users\[username]\AppData\Local\Temp\VMwareDnD\. In order for the .DS_store file to be in that location, either my Mac must have somehow accessed the folder and left it behind, or it was copied there from my Mac by something else. When I investigated further, what I found was the worst case scenario. A cache of all the files I had copied from the host and other VMs to the Windows VM, in raw form, fully accessible. Ummm, WTF, right? Wait, don't check yours yet, just give me a second to finish.
While most computer users would say, "So what? Now I have an unintentional backup of my data." I say, "Crap, why is there client data sitting on my drive in an unencrypted form!?" The answer is, there shouldn't be. I think we can all understand why files would need to be cached to support the VMWare Tools drag-and-drop feature, but why the persistence? Why not have the temporary files go to the bit bucket immediately following the copy process? Why are files several months old still there? What could possibly be the need? Unfortunately, I could not track down any official documentation of why the files persist. What I was able to find were several other examples of people experiencing the same issue. Apparently, according to the guy that wrote
this, he had asked the question on the VMware Community forums and was told by a VMware technician that they are supposed to be removed upon reboot. (The forum thread link was dead, so I'm taking his word for it.) However, I found many instances where this was also not the case, and in testing, my files persisted reboot.
But even if the files did disappear on reboot, how often do we reboot our VMs? I can sometimes go weeks or months, pausing and unpausing, before an update forces me to reboot. So what's really going on here? Is this a bug? I don't know. But what I do know is that anytime I copy sensitive data to a VM, I clear out that folder to make sure I exercise due diligence in protecting my client's data. I recommend you do the same.
I realize that this may not be relevant to everyone. I'm sure some of you use alternative products. Encrypting your entire VM may reduce the risk shown here as well, depending on how its implemented. But I can hear some of you saying, "Silly lanmaster, I use VMware, but I don't use Windows VMs. I'm an all Linux shop. This doesn't apply to me." Au contraire mon frere. Take a look at /tmp/VMwareDnD... No VMware user is safe.
...when it's all that's left to drink.
