Hacking Virtual Machines Part 2 - Environments Where Virtualization Lives

Virtualization is considered to be the new renaissance in computing. Suddenly, all those over sized servers are put to great use by putting multiple Guest OS's on them. But running IT services in a virtualized environment brings a whole host of new opportunities for hackers.

In this article, we'll review the environment in which Virtualization lives, and which targets will yield most benefits for an attacker:

The environment

  1. Virtualization for production use is not a home tool - Virtualization is usually used by organizations of 500 employees or more. Smaller organizations also use it to create multiple environments on single hardware platforms. But smaller organizations are prone to make the classic mistake of mixing development and production platforms on same hardware.
  2. Virtualization platforms can be under scrutiny of several security sensors - Corporations, as common users of virtualization also use a whole bunch of security devices. It is very common that the attack on virtual servers will be or at least logged by Intrusion Detection Systems, pattern matching logic on firewalls and log analysis systems.
  3. It is rarely possible to initially plan for an attack on virtualization - In the information gathering and reconnaissance phase it is quite difficult to detect that some systems are virtualization platforms or virtual machines. You can confirm that there is virtualization only after you penetrate the perimeter and are able to scan for MAC addresses or specific signatures on the virtual hosts.

Targets of choice

The best virtualization attack targets, in order of preference are:
  1. Training platforms - These platforms are created by the 'Let's see if I can do this' philosophy. They are notoriously unpatched, since nobody bothers to patch them - they are expendable. These platforms have a tendency of urgently becoming production platforms in times of need - resources are needed and these are available. But then, they remain unpatched for quite some time.
  2. Test and development platforms - These platforms have a much better security posture then training platforms. But still, they are usually lagging behind production on patch levels. Also, test and development platforms are very good targets because they are full of production grade or near-production grade of data.
  3. Mixed test and production platforms - Both production and test versions of applications with lower processing requirements can be placed on the same VM Host. But unless they are isolated to different VLANS or on separate physical network adapters, the test platform can be exploited and used to attack the production.
  4. Proof of concept platforms - These platforms are usually outward facing platforms, like web servers that contain demo code or proof of concept code used for customer evaluations or marketing purposes. These platforms are usually compromised by a flaw in the web applications, and in a well maintained environment should be in an untrusted DMZ.
Attack guidelines

With this description of the environment, an attacker can prepare him/herself for attack on virtualization:
  1. Virtual machines are targets of opportunity - Virtual machines are not advertised. They can be detected only after the initial penetration. In such a case, the attack should be re-planned to possibly compromise the virtualization platforms.
  2. Virtual machines will hold a lot of valuable data - In a corporate environment, any host may be source of a wealth of information. Once inside, a good attacker will seize the opportunity to attack a virtual machine.
  3. Do not make too much noise - assume that sensors are all over the place and that someone is reading through the logs. This rule also applies to attacking physical machines
  4. Choose test/training platforms - these are usually on LAN segments where there are much less sensors
This enviroment description should be a guideline for security personnel to properly secure their virtualization environment:

  • Patch everything - this is a well known rule, but one that is still often forgotten. When patching, incude test and experimental platforms.
  • Do not expose test applications executing on a Virtual Machine to open internet - Simply, never risk the possibility of someone exploiting a web app vulnerability to gain access to your Virtualization infrastructure. If you must expose such a test platform the open internet, treat the entire VM Host and all guests as hostiles/honeypots and isolate the rest of the network from them.
  • Do not mix production and test on the same VM Host unless you have isolated them at every level - especially network level.
  • Isolate the VM test environments in network isolation layers. - Even if someone gains access to the network, he/she should have very difficult time exploiting a VM host, simply by not being able to reach it. Test environments should be self-sufficient - all test servers, test clients and supporting systems should be in the isolated block. Minimal services should be exposed to the rest of the organization, so that remote scanning shows nothing to the attacker.

Talkback and comments are most welcome

Related posts
Hacking Virtual Machines Part 1 - Sniffing
DHCP Security - The most overlooked service on the network

Designed by Posicionamiento Web