New Virtualization System-Specific Attacks

■ VM jumping/guest hopping

–Attackers take advantage of hypervisor escape vulnerabilities to “jump” from one VM to another

■ VM attacks

–Attacks during deployment and duplication

–Deletion of virtual images

–Attacks on control of virtual machines

–Code/file injection into virtualization file structure

■ VM migration

–VM migration is transfer of guest OS from one physical server to another with little or no downtime

– Implemented by several virtualization products

–Provides high availability and dynamic load balancing

■ VM migration attack

– If migration protocol is unencrypted, susceptible to man-in-the-middle attack

–Allows arbitrary state in VM to be modified

– In default configuration, Xen Motion is susceptible (no encryption)

–VMware’s VMotion system supports encryption

–Proof-of-concept developed by John Oberheide at the Univ. of Michigan

■ Management server attacks

–Exploit management console vulnerabilities that divulge password information

–Exploit management console vulnerabilities to gain access to management server

–Exploit vulnerabilities that allow local management server users to gain elevated privileges

■ Administrative VM attacks – exploit vulnerabilities to:

–Cause a denial of service by halting the system

–Cause a denial of service by crashing the administrative VM

–Obtain passwords that are stored in clear text

–Exploit buffer overflows in exposed services to execute arbitrary code

–Exploit vulnerable services to gain elevated privileges

–Bypass authentication

■ Guest VM attacks – exploit vulnerabilities to:

–Gain elevated privileges

–Crash the virtual machine

–Truncate arbitrary files on the system

–Execute arbitrary code with elevated privileges

■ Hypervisor attacks – exploit vulnerabilities to:

–Cause the hypervisor to crash

–Escape from one guest VM to another

■ Hyperjacking

–Consists of installing a rogue hypervisor

• One method for doing this is overwriting page files on disk that contain paged-out kernel code

• Force kernel to be paged out by allocating large amounts of memory

• Find unused driver in page file and replace its dispatch function with shell code

• Take action to cause driver to be executed

• Shell code downloads the rest of the malware

• Host OS is migrated to run in a virtual machine

–Has been demonstrated for taking control of Host OS

–Hyper jacking of hypervisors may be possible, but not yet demonstrated

• Hypervisors will come under intense scrutiny because they are such attractive targets

–Known hyper jacking tools: BluePill, SubVirt, Vitrio

Virtualization System Vulnerability Classes

■ Management console vulnerabilities

–Affect the management console host

–Can provide platform or information allowing attack of management server

–Can occur in custom consoles or web applications

■ Management server vulnerabilities

–Potential to compromise virtualization system configuration

–Can provide platform from which to attack administrative VM

■ Administrative VM vulnerabilities

–Compromises system configuration

–In some systems (like Xen), equivalent to hypervisor vulnerability in that all guest VMs may be compromised

–Can provide platform from which to attack hypervisor and guest VMs

■Guest VM vulnerabilities

–Affect a single VM

–Can provide platform from which to attack administrative VM, hypervisor, and other guest VMs

■ Hypervisor vulnerabilities

–Compromise all guest VMs

–Cannot be exploited from guest VMs

■ Hypervisor escape vulnerabilities

–A type of hypervisor vulnerability

–Classified separately because of their importance

–Allow a guest VM user to “escape” from own VM to attack other VMs or hypervisor

–Violate assumption of isolation of guest VMs

Configuring VMware vCenter Server to send alarms when virtual machines are running from snapshots

Prerequisites

• Determine the level of the inventory you want to configure the alarm for.
• The object hierarchy is: vCenter > datacenter > cluster > host > datastore > folder > resource pool > virtual machine.
• Alarms on an object are inherited by all child objects.
• When it is configured you can see its settings from the underlying/child objects but it is only configurable only from the object where it was created.
• To create alarms, vSphere Client must be connected to a vCenter Server with the appropriate user permissions on all relevant objects. After an alarm is created, it
  is enabled even if the user who created it no longer has permissions.

To open the Alarm Settings dialog, perform any one of these operations:

• Click File > New > Alarm.
• Click Inventory > > Alarm > Add Alarm.
• Right-click the object and select Alarm > Add Alarm.
• In the Alarms tab, click the Definitions tab, right-click in the pane and select New > Alarm.
• Click on the object in the inventory and press Ctrl+A.

Alarm Settings – General tab

To create a new alarm:

1. Enter an alarm name and alarm description.
2. Define the type of alarm:
1. In the Monitor list, select Virtual Machines.
2. Select Monitor for specific conditions or state.
3. Select Enable this alarm.

Alarm Settings – Triggers tab

State triggers are set off as soon as a state threshold or condition is achieved. You cannot define condition lengths for state alarms.

Note: You cannot use a virtual machine's Total Size on Disk or VM Snapshot Size triggers in combination with any other triggers.

To add a new alarm trigger:

1. Click Add.
2. In the Trigger Type drop-down, select VM Snapshot Size (GB).
3. In the On Condition drop-down, select Is above.
4. Double-click the Warning and Alert fields and enter the desired values.

Define tolerance ranges and trigger frequencies for condition or state triggers.

Alarm Settings – Actions tab

To define an action:

1. Fill in the configuration tab with the details required for the configured Action.
2. Select if you want the action to be executed with a specific frequency or just when there is a status change from normal to warning warning to alert, alert to warning, and warning to normal.
3. Click OK and the alarm is ready.