My new e-book “Deep VMware™ Guest Tools and Guest-Hypervisor communication” at Amazon

Just published my new e-book “Deep VMware™ Guest Tools and Guest-Hypervisor communication” at Amazon.

Check it out.

Most virtualization platforms provide some sort of mechanism of communication between the the hypervisor and its guest virtual machines. “Open VM Tools” is a set of tools that implements such communication mechanisms for VMware™ virtual machines and hypervisors. In this book we analyze each of these these tools and APIs, from high-level usage to low-level communication details, between the guest and the host. This information can be used for a better understating of what actually happens when using a guest machine with these tools. It can also be used as inspiration for using and extending guest-hypervisor communication and penetration testing.

Screen Shot 10-05-17 at 12.44 PM

cover.jpg

Advertisements

New e-Book: “VMware™ hypervisor fingerprinting”

Just published a new e-book at Amazon.com: “VMware™ hypervisor fingerprinting”.

You can find it here:

«In this book, we show how to determine hypervisor properties by running commands in the guest operating system, without any special privileges in the host machine running the hypervisor. This can be useful for penetration testing, information gathering, determining the best software configuration for virtualization-sensitive and virtualization-aware software. Finally, we present a reporting tool that unifies all the presented methods, by running them all in sequence and gathering the information in a useful report that can be run from any guest system.»

Nested virtualization using VMware hypervisors

Nested virtualization is the act of running a hypervisor nested within another hypervisor.

For example, it is possible to run a Nested VMware ESXi 6.0 hypervisor over a VMware Player 7 hypervisor:

nested-esxi-6-0-screenshot

We may need to make some changes to the Nested Hypervisor virtual machine configuration file, as described in (VMware: Running Nested VMs – VMware: Running Nested VMs ).

It would be interesting for a guest machine to be able to detect to be running over a Nested Hypervisor.

I haven’t found a direct method (virtual hardware-based) yet. Some network testing and MAC Address and ESXi services correlation could do the trick, when networking is available.

For example, consider the following NMAP scan:

# nmap -vv -sV --version-all 192.168.189.134 -p 443
Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-22 10:45 EST
Scanning 192.168.189.134 [1 port]
(...)
PORT STATE SERVICE VERSION
443/tcp open ssl/http VMware ESXi Server httpd
MAC Address: 00:0C:29:BD:16:1F (VMware)

NMAP detects that there is an ESXi Server at IP 192.168.189.134 and that its MAC Address is 00:0C:29:BD:16:1F, inside the VMware virtual MAC address range. This indicates that this machine may well be a Nested ESXi.

More details in the full paper at VMware hypervisor fingerprinting Tool ( & Paper)

References

VMware hypervisor fingerprinting Tool ( & Paper)

Just published a new tool vmhost_report.rb (and a paper about it) for VMware hypervisor fingerprinting. The tool is released with an open source license (GPL), you can use it freely.

In the paper, I show you how to determine hypervisor properties (such as hypervisor version or virtual CPU Limits) by running commands in the guest operating system, without any special privileges in the host machine running the hypervisor.

This can be useful for penetration testing, information gathering, determining the best software configuration for virtualization-sensitive and virtualization-aware software.

I have developed a reporting tool vmhost_report.rb that unifies all the presented methods, by running them all in sequence and gathering the information in a useful report that can be run from any guest system. Currently, Linux and Nested ESXi are supported.

You can run it as “ruby vmhost_report.rb“. It will return a lot of useful information in the vmhost_report.log file.

These reports can be used to learn a lot about VMware internals or a particular guest system or network. You can find report examples in the Paper’s “Annex A”.

Some of the described methods can be used even if the VMware Tools are disabled or not installed, or if some of the methods are disabled by host configuration. Some of the methods require “root” privileges, while others do not need it.

Downloads

Screenshots

 

VMware Cloud Products Survey (Slides)

Regarding VMware vCloud Suite components, VMware terminology can be confusing


This presentation tries to clarify some VMware component names and analyse VMware vRealize
Operations in-depth

The vCloud suite includes almost all VMware products, including:
○ Hypervisor: vSphere (ESXi + vCenter )
ESXi: Single-machine Hypervisor 
vCenter : Handles multiple ESXi’s
● Handles vMotion, High Availalability, Load Balancing
○ vCenter Site Recovery Manager 
■ Policy-based disaster recovery and testing for all virtualized applications
Full presentation at:

Preview:

Screen Shot 08-25-16 at 06.25 PM.PNG

VMware vulnerabilities survey

Software is usually affected by some kinds of security vulnerabilities. Vulnerabilities can be classified into several types, in order to ease their impact analysis, providing a common thought framework. Virtualization products aim to allow users to abstract the  physical hardware details and provide them with means to install multiple virtual machines. Some virtualization users often tend to forget or ignore that this additional software layer exposes them to additional attack vectors and potential vulnerabilities. In this paper, we analyze the known vulnerabilities for VMware, a well known virtualization product.

Check the Full Paper:

Preview:

Screen Shot 07-07-16 at 05.06 PM.PNG

Anonymity tools: “whonix”(first impressions)

Just started trying “whonix”, an anonymity-hardened Linux distribution.

“whonix” is based on Debian Linux and uses TOR for all external connections.

Interestingly, it consists of two separate virtual machines, “whonix workstation” and “whonix gateway”. That machine where the user can perform anonymous tasks  (“whonix workstation”) is isolated from the external physical network and can only communicate with the internet via the “whonix gateway”, which relays TOR traffic to the TOR network and the internet.

The main design decision for “whonix” is that the user’s physical IP should not be disclosed even if the “whonix workstation” is compromised with some types of malware. Indeed, the “whonix workstation” does not have access to the external network, which is a very interesting concept.

I’ll be writing more about “whonix”, TOR and Anonymity soon.

Why Anonymity Matters (quoted from https://www.torproject.org/)

Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location.

Screen Shot 06-30-16 at 07.26 PM.PNG

Screen Shot 06-30-16 at 07.33 PM

References:

“vsockets-tools” for VMware hypervisors

I have developed a new open source project: “vsockets-tools”

You may check it out at:

Source repository + pre-compiled binaries:

Paper:

Abstract:
VMware guest machines are able to communicate with their host using a special kind of sockets called “vsockets”. These sockets can be used even if the typical TCP/IP network protocols are not available at the guest. Since “vsockets” don’t use the TCP/IP protocol stack, they are not “visible” to common network testing and penetration testing tools.In this paper we present a set of tools designed to provide a bridge between TCP/IP tools and the “vsockets”. These tools can also be useful for learning “vsockets” behavior and concepts.

Paper Preview:

Screen Shot 06-29-16 at 12.00 PM.PNG