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.

The tool is designed as a password dictionary attack tool that targets windows authentication via the SMB protocol. It is really a wrapper script around the ‘smbclient’ binary, and as a result is dependent on it for its execution.

The simplest way to run the tool is as follows:

./acccheck.pl -t 10.10.10.1

This mode of execution attempts to connect to the target ADMIN$ share with the username ‘Administrator’ and a [BLANK] for the password.

./acccheck.pl -t 10.10.10.1 -u test -p test

This mode of execution attempts to connect to the target IPC$ share with the username ‘test’ and a password ‘test’.

Each -t, -u and -p flags can be substituted by -T, -U and -P, where each represents an input file rather than a single input from standard in.

./acccheck.pl -T iplist -U userfile -P passwordfile

Only use -v mode on very small dictionaries, otherwise, this has the affect of slowing the scan down to the rate the system writes to standard out.

Any username/password combinations found are written to a file called ‘cracked’ in the working directory.

acccheck-0-2-1.tar.gz
April 26, 2013

9.8 KiB
MD5 hash: ad14f58e04bc683fce5f72ef3cdb745d
Details

Date:

April 26, 2013

The post acccheck appeared first on Portcullis Labs.

MIBparse.pl has been designed as an offline parser to quickly parse output from SNMP tools such as ‘snmpwalk’ (NET-SNMP project ‘net-snmp.sourceforge.net’). The output returned depends on the options that are selected by the user. Typically, information relating to the system, services, open ports, users, shares and installed components is some of the information that can be extracted by the tool.

Requirements

The only requirement is Perl.

Running

The simplest way to run the tool is as follows:

./MIBparse -f public.txt

Where “public.txt” is the output from ‘snmpwalk’ piped to a file. In this mode all available information is displayed to the user as standard out.

The information that is output can be tailored using the ‘-a’ flag. The following values can be used in conjunction with this flag:
1 = All
2 = System
3 = Routing information
4 = Services
5 = TCP ports
6 = UDP ports
7 = Users
8 = Shares
9 = Domain
10 = Installed components
11 = Community strings

Each value corresponds to the type of information that is output. As an example, ‘-a 7′ will output all of the users from a Windows system. The example execution in this case would include:

./MIBparse.pl -f public.txt -a 7

If you wish to execute the tool from a working directory which is not in your $PATH then the ‘-b’ option can be used to specify the location of the ‘tags’ file. This option can also be used to specify any file as a tags file as long as the format of the file conforms to the example that is provided. The example execution in such a case would be:

./MIBparse.pl -f public.txt -b ./tags

or:

./MIBparse.pl -f public.txt -b ./mytagsfile

Finally, the ‘-b’ flag can be used in conjunction with the ‘-a’ flag. The example execution in such a case would be:

./MIBparse.pl -f public.txt -b ./mytagsfile -a 7

MIBparse-0_1_1.tar.gz
April 26, 2013

25.6 KiB
MD5 hash: 39d4410a7dda51c2cafe728ff5814096
Details

Date:

April 26, 2013

The post MIBparse appeared first on Portcullis Labs.