VMware vSphere Basics – “The bits and pieces”

Everyone will have had some exposure to virtual technologies in their pentesting adventures. Due to the proliferation of this technology, it is hard to do a security assessment today without touching a virtualised component of some sort. The forerunner in this area is VMware with their vSphere platform. It has grown over the years into a rather large complicated beast. For those who have scoped or performed a security assessment of a VMware solution will know what I mean.

The vSphere platform is not a single application, but rather a suite of different products that VMware sell under a single unified product called vSphere. The latest version of this product is vSphere 5.5, which was released in late 2013. The following components make up vSphere:

• VMware ESXi
• VMware vCenter Server
• VMware vSphere Client
• VMware vSphere Web Access
• VMware Virtual Machine File System (VMFS)
• VMware Virtual SMP
• VMware vMotion, and Storage vMotion
• VMware High Availability (HA)
• VMware Distributed Resource Scheduler (DRS)
• VMware vSphere SDK
• VMware Fault Tolerance
• VMware vNetwork Distribution Switch (VDS)
• VMware Host Profiles
• VMware Pluggable Storage Architecture (PSA)

By far the largest and most important component of vSphere is the ESXi Hypervisor. This is the underlying Operating System (OS) called VMkernel. Whatever remains of the vSphere product suite interacts with this central core. VMware describe this component as:

“a virtualisation layer run on physical servers that abstracts processor, memory, storage, and resources into multiple virtual machines”

In short, creating multiple individual entities from a single pool of hardware resources. These entities are called “Virtual Machines” (VMs), and function as any hardware based server would, on the network fabric.

The ESXi host is a purpose-build embedded system that looks and feels like a Linux system under the hood. Busybox is used as a lightweight shell that is able to interpret and execute common UNIX commands. It has no graphical environment of its own. Out of the box, access to the ESXi hypervisor is provided via a yellow and grey console called the “Direct Console User Interface (DCUI)”.  This is a very basic easy to use console for configuration, and the option of last resort for administrators when things go wrong. Access to the DCUI is restricted to the physical console and over the Secure Shell (SSH) interface. For this reason, the later versions of the vSphere product ship with SSH access disabled by default. As a security professional, if you manage to achieve interactive SSH access to the ESXi host, it is game over. A compromise at this level allows complete access to all resources and allows the user to power off the ESXi host, creating a DoS on a very large scale, depending on the number of hosted VMs of cause. So how can the ESXi hypervisor be administered safely? Answer, by using the vCentre Server and the vSphere client.

The vSphere client refers to a Windows application that enables management of an ESXi hypervisor.  It can be used to connect to the ESXi hypervisor directly or to a vCenter Server. Depending on the access method configured on the ESXi hypervisor, an account configured directly on the ESXi host, or a Windows Domain account can be used to connect to the remote ESXi host. Once connected, the user, depending on privileges of the accounts used, is able to perform administrative operations such as create new VMs, administer existing VMs. Short of powering off the ESXi hypervisor, the user would have control to configure aspects of the ESXi hypervisor and complete control over the VMs that it hosts.

The vCenter Server is a software product that can be installed onto the Windows based physical server or a VM (generally inside the same Virtual Pool) but VMware also ship a virtual appliance preconfigured with vCentre to allow easy deployment. vCentre cannot be installed onto a Linux Platform. Furthermore, when using vCentre on a Windows platform, an SQL database is required which hosts all the required Pool Data. This can either be MS SQL Express for small implementations or a full blown MS SQL installation. Needless to say, if you compromise SQL, you’ve compromised the whole vSphere deployment. VMware also support Oracle and DB2 databases. It is used to administer and manage multiple ESXi hypervisors in an enterprise wide vSphere implementation. vCenter Server is required for an organisation to use the enterprise features like vMotion, VMware High Availability, VMware Update Manager and VMware Distributed Resource Scheduler (DRS). Access to vCentre Server is possible through the vSphere Client or the vSphere Web Access component. When using the vSphere client to connect to the vCentre Server, the vCenter Server acts as a proxy that enables a user to administer multiple ESXi hypervisor hosts without the need to authenticate individually to each one. The level of access is much the same when compared to accessing the ESXi host via vSphere. The biggest difference between these two components is that the vCenter Server provides a broader level of access to the ESXi hypervisor estate of an organisation. This broad access opens up further possibilities, such as the ability to seamlessly migrate VMs between different ESXi hosts. This is managed by the VMware vMotion, and Storage vMotion components. The vSphere Web Access component on the other hand provides a web enabled application that can be accessed through the common desktop web browser. Web access is only made available after the deployment of vCentre. ESXi does not have a web access component. A typical URL for this service would be:

• https://<ip/hostname of vCenter Server>:9443/vsphere-client/

vCentre, together with the Hosts in question need to be configured as part of a “VMware Cluster” of Hosts before they can be managed via the web interface. Seasoned VMware Technicians still use the full vSphere client to manage an estate as the vCentre web console is still quite clunky.

In summary, we have briefly explored the most important components that make up the VMware vSphere product. The product line offers more diversity than it was possible to cover in this small article. To conclude, it would be fair to say that a good level of understanding of the vSphere product is necessary before one can perform an adequate security assessment. The good news is that there are many hardening guides out there that provide an insight into the various areas that should be covered during an assessment. The reader is directed to the hardening guides produced by VMware for further information.

The post VMware vSphere basics – “The bits and pieces” appeared first on Portcullis Labs.