Experiments with VMware

In this post, I present to the habrasoobshchestvo the results of their inept and unsystematic experiences with VMware vSphere 4.1

About work

I conducted this research in the framework of a special section of my graduation project.
The research part is based on the translation of the NIST SP 800-125 standard (see post ).
A special section was tasked with examining the most likely threats, so a model of an intruder was chosen.

About stand

The stand is a cluster of 3 ESX 4.1 servers on which 4 VMs spin (two for Ubuntu 12.10, two for WinServer 2008 R2), each with two vNICs: a common lab VLAN routed to the local segment and an isolated VLAN.
From the application software used:

• Wireshark 1.8.7 for Windows
• Tcpdump and dsniff packages

Experiences

Sniffing
The first thing I started to explore is the promiscuous virtual switch mode. Already in the process I came across a good comprehensive article on the VMware Community. Since the original is always better than retelling, I recommend using a direct link .

MAC spoofing
Physical enough "smart" switches have mechanisms that prevent attacks such as Substitution of MAC addresses. These are, for example, the port security settings in Cisco Systems switches, which can be used to strictly specify the allowed addresses for each port of the device.
In a virtual environment has its own specifics. All VM settings, including the MAC address, are stored in VM files, which only the virtualized infrastructure administrator is authorized to change. Only VMs can create VMs and connect them to groups of virtual ports, as well as to VLANs. In addition, there is a MAC Address Changes - Accept / Reject setting that permits or prohibits the guest OS from accessing the network with an address different from that recorded in the VM file (which, by the way, allows substitution by default).
It would be logical to prohibit the change of address, however, it is not difficult to imagine a situation where the customer of the IaaS service (Infrastructure as a service - infrastructure as a service) will need this opportunity (for example, to test their software).
One of the options: do the same as with the previous threat - split the VLAN into parts with different settings.
Consider the second option, when the administrator of the IVI for incompetence or in the hope of the providence of VMware developers, leaves the default settings (the Promiscuous mode for the port group is not enabled).

Let ICMP exchange between one of the VMs under Windows with an external host (from the local network) be the target information flow.
All that an attacker should have: the victim's MAC address and the rights of the local administrator of the guest OS in his VM.
Attack:
sudo su -
ifconfig eth0 down
ifconfig eth0 hw ether NEW_MAC
ifconfig eth0 up
tcpdump –n src host 10.106.30.104

Result: the attacker intercepts the entire exchange. In addition, the attack is very difficult to detect. The frequency of requests coming to the attacked VM has not changed and is equal to the frequency of intercepted requests on the attacker, which means that the virtual switchboard simply duplicates the packets. The interconnection of machines is also not disturbed. Only direct exchange between these VMs becomes impossible.
')
MAC flood
The most "unclean" experiment, conducted without thought, but which led to interesting consequences and, of course, requiring a more detailed study.

Each physical switch operates with data CAM (Content Addressable Memory) or, simply, a switching table. Its volume for different models varies. For example (the data is charred where it does not claim to be a scientific truth):

• Cisco Catalyst 2960 - up to 8000 MAC addresses;
• Cisco Catalyst 3560 - up to 12000 MAC addresses;
• Cisco Catalyst 6500 - up to 96000 MAC addresses.

When the CAM table overflows, new entries will not be added, all traffic will pass to all ports (although, in general, switches may behave differently). The attacker can "listen" to all network traffic and receive confidential information.
To suppress such an attack, you need to specify that the switch port to which the user is connected may have, for example, no more than one MAC address, and if more than one appears, put the port into a disabled state and send a message to the administrator about the security breach (for example, port security settings in Cisco).
In VMware, there is a setting Forged Transmits - Accept / Reject, but, as already discussed above, there may be situations where it is not possible to use it. Therefore, there is a need to clarify the possible consequences of such attacks in order to manage risks.
To implement the attack, the macof program from the dsniff package was used.

I must say about the shortcomings of the experiment:

1. The first one is the main one: the attackers were in the routed VLAN, the attacked ones were in the isolated one. It would be much better to do the opposite.
2. The second is a circuit flaw. Due to the use of a cluster, it is difficult to judge the results.

But first things first.

With the beginning of the attack, packet jitter immediately increased,but so far nothing critical.
After a couple of minutes, the VM consoles began to noticeably “slow down”, individual packets began to get lost.
Finally, somewhere in 5-7 minutes after the start, everything collapsed: before the client connection to the vCenter fell off, it managed to notice the unavailability messages of individual VMs, the VM consoles did not open - the rack switch refused (Top of Rack).
In practice, this means not only the DoS of the public service, but also, possibly, some of the internal services of the provider, which cannot be an acceptable risk, which means that countermeasures are required.

I must say, I did not fix the switch to virtual hub mode (at least, the VLANs were divided to the last).

Due to the shortcomings of the test described above, it is difficult to say what exactly happened and what was the true reason (at least for me). I would be very happy if anyone in comments (or hp) will be able to decompose the result on the shelves.

This is all the most interesting work I have done.
Waiting for feedback: suggestions, advice, corrections, and all else. =) Thank you for your attention.