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.

Red Hat Enterprise Virtualisation: RHEV 3.0 Release

Red Hat Enterprise Virtualisation platform V.3

Red Hat has announced version 3 of its Red Hat Enterprise Virtualization (RHEV) server and desktop virtualisation software family. RHEV for Servers is the main product in the range that was introduced in autumn 2009 and updated in summer 2010. It includes a hypervisor, sometimes called RHEV-H, for hosting guest systems. Hosts are managed using management software (RHEV-M) which is another part of the server variant of RHEV and which also manages systems that are virtualised using Red Hat Enterprise Linux (RHEL). The RHEV for Desktops RHEV server "add-on" implements Virtual Desktop Infrastructures (VDIs) – sometimes called Hosted Virtual Desktop (HVD) – this technology involves running desktop operating systems on a server as guests; users then access these remote systems via (thin) clients.

As before, the RHEV hypervisor, which is only a few hundred megabytes in size, virtualises using KVM (Kernel-based Virtual Machine) and integrates many RHEL core components – however, the new RHEV uses components from the current RHEL version 6.2 rather than RHEL series 5. Consequently, the new RHEV-V offers many improvements that have been available in RHEL 6 for some time – for example, guest systems can now access up to 64 virtual CPU cores and up to 2 TB of working memory. Technologies such as vhost-net, Transparent Huge Pages (THP), x2apic and KSM (Kernel Shared Memory) are designed to improve performance and increase efficiency.

Red Hat says that it has incorporated more than a thousand new features into the management server software, which now includes a RESTful API. However, the most important change is that the code has been ported from C# to Java. This has had an important effect on the system requirements for running RHEV-M. Instead of the Microsoft Windows Server that RHEV-M 2.2 required, the new version relies on RHEL 6 server, with the Java code running on Red Hat's JBoss Enterprise Application Platform. However, Red Hat hasn't fully lost the Windows dependency it acquired with Qumranet, because the management server software's "Administrator Console" web front-end can only be operated from a Windows computer running a version of Internet Explorer 7 with .NET Framework 4. Red Hat plans to fix this issue in the next version of RHEV.

RHEV for Desktops continues to use Spice – developed by Qumranet – for communication between clients and virtualised desktop operating systems. Red Hat says that it has improved Spice in several ways, for example, users can now connect almost any USB 1.1/2.0 device to Spice clients which can pass the connections through to the remote virtualised desktop operating system. Apparently, even resource-hungry applications can be operated remotely this way.

According to Red Hat, the various RHEV products are based on open source software. Last autumn, Red Hat handed the management software it acquired when purchasing Qumranet, as well as a variety of other RHEV-specific components, over to the oVirt project, where the company has continued to develop them together with contributors such as Canonical, Cisco, IBM, Intel, NetApp and SUSE. Some background information on the oVirt components is available from one of the project's blog posts.

Like Red Hat's RHEL, RHEV is distributed using a subscription model. The server product's annual subscription fee depends on the number of host system processor sockets and on the chosen support option; options include the "Standard" and "Premium" versions that Red Hat customers will already know from RHEL. Red Hat has repeatedly emphasised that it considers this approach far simpler and more cost-effective than the licensing models of comparable products. Red Hat's remarks appear to be mainly aimed at market dominating virtualisation specialist VMware.

Original link: http://www.h-online.com/open/news/item/Red-Hat-releases-third-version-of-its-Enterprise-Virtualisation-platform-1416749.html

Configuring a Microsoft SQL database for vCloud Director 1.5

This articles outlines the steps for creating a Microsoft SQL database for use with vCloud Director 1.5. It is essential that these steps are followed exactly for your database to function correctly.

Cause

SQL Server databases have specific configuration requirements when you use them with vCloud Director. Install and configure a database instance, and create the vCloud Director database user account before you install vCloud Director.

vCloud Director database performance is an important factor in overall vCloud Director performance and scalability. vCloud Director uses the SQL Server tmpdb file when storing large result sets, sorting data, and managing data that is being concurrently read and modified. This file can grow significantly when vCloud Director is experiencing heavy concurrent load. It is a good practice to create the tmpdb file on a dedicated volume that has fast read and write performance. For more information about the tmpdb file and SQL Server performance, see http://msdn.microsoft.com/en-us/library/ms175527.aspx.

Resolution

Prerequisites

• You must be familiar with Microsoft SQL Server commands, scripting, and operation.
• To configure Microsoft SQL Server, log on to the SQL Server host computer using administrator credentials. You can configure SQL server to run with the LOCAL_SYSTEM identity, or any identity with the privilege to run a Windows service.

Configuring the Microsoft SQL Server Database

1. Configure the database server.
   
   A database server configured with 16GB of memory, 100GB storage, and 4 CPUs is adequate for most vCloud Director clusters.
2. Specify Mixed Mode authentication during SQL Server setup.
   
   Windows Authentication is not supported when using SQL Server with vCloud Director.
3. Create the database instance.
   
   This script creates the database and log files, specifying the proper collation sequence:
   
   USE [master]
   GO
   CREATE DATABASE [vcloud] ON PRIMARY
   (NAME = N'vcloud', FILENAME = N'C:\vcloud.mdf', SIZE = 100MB, FILEGROWTH = 10% )
   LOG ON
   (NAME = N'vcdb_log', FILENAME = N'C:\vcloud.ldf', SIZE = 1MB, FILEGROWTH = 10%)
   COLLATE Latin1_General_CS_AS
   GO
   
   The values shown for SIZE are suggestions. You might need to use larger values.
4. Set the transaction isolation level.
   
   This script sets the database isolation level to READ_COMMITTED_SNAPSHOT:
   
   USE [vcloud]
   GO
   ALTER DATABASE [vcloud] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
   ALTER DATABASE [vcloud] SET ALLOW_SNAPSHOT_ISOLATION ON;
   ALTER DATABASE [vcloud] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
   ALTER DATABASE [vcloud] SET MULTI_USER;
   GO
   
   For more about transaction isolation, see http://msdn.microsoft.com/en-us/library/ms173763.aspx.
5. Create the vCloud Director database user account.
   
   This script creates the database user name vcloud with password vcloudpass:
   
   USE [vcloud]
   GO
   CREATE LOGIN [vcloud] WITH PASSWORD = 'vcloudpass', DEFAULT_DATABASE =[vcloud],
   DEFAULT_LANGUAGE =[us_english], CHECK_POLICY=OFF
   GO
   CREATE USER [vcloud] for LOGIN [vcloud]
   GO
6. Assign permissions to the vCloud Director database user account.
   
   This script assigns the db_owner role to the database user created in Step 5:
   
   USE [vcloud]
   GO
   sp_addrolemember [db_owner], [vcloud]
   GO

Making a bootable OpenBSD 5.0 CD

Here are the scripts on how to make the bootable OpenBSD v 5.0 CD

#!/usr/local/bin/bash
#
## Calomel.org -- Making a bootable OpenBSD CD
## calomel_make_boot_cd.sh
#
arch="amd64" # Architecture
version="5.0" # OS version
#
echo "building the environment"
mkdir -p /tmp/OpenBSD/$version/$arch
cd /tmp/OpenBSD/$version/$arch
#
echo "getting the release files"
wget --passive-ftp --reject "*iso" ftp://ftp.openbsd.org/pub/OpenBSD/$version/$arch/*
#
echo "building the ISO"
cd /tmp/OpenBSD
mkisofs -r -no-emul-boot -b $version/$arch/cdbr -c boot.catalog -o OpenBSD.iso /tmp/OpenBSD/
#
echo "burning the bootable cd"
nice -18 cdrecord -eject -v speed=32 dev=/dev/rcd0c:0,0,0 -data -pad /tmp/OpenBSD/OpenBSD.iso
#
echo "DONE."
#