mailing list archives
RE: RE: 4tphi: Detecting VMWare
From: Bridges Lloyd <Lloyd.Bridges () services fujitsu com>
Date: Mon, 11 Nov 2002 09:33:26 -0000
Hi, long time lurker - first time poster.
On the subject of VMware honeypots, another method you could also use to
potentially detect a VM honeypot is by its MAC address. The MAC
00-50-56-xx-xx-xx range has been officially registered by VMware.
You could always change the MAC to something unique to protect against this,
by manually editing the .vmx or .cfg file using a text editor though. I seem
to recall the documentation stating that this could be done, although it
suggests you change the xx-xx-xx part of the MAC.
FUJITSU SERVICES - Information Security Practice
From: Kurt Seifried [mailto:bt () seifried org]
Sent: 08 November 2002 21:42
To: Andrew Hintz (Drew); honeypots () securityfocus com
Subject: Re: 4tphi: Detecting VMWare
There are numerous other methods, from looking at a dump of the BIOS (kind
of hard to hide, and if the attacker has root they can do it no matter
Identifying VMware systems
Against most attackers a VMware system will not raise any suspicion, most
will take the system at face value and assume it is running on it's own
dedicated hardware like a "normal" system. Unfortunately there are a number
of ways to identify systems running under VMware.
Of course one dead giveaway is if the system is running VMware tools, under
windows this will show up in "Add/Remove programs", the Program Files
directory and so forth. For UNIX there are Xfree86 patches to improve
performance, as well as a complete Xfree86 server optimized for VMware guest
operating systems, both of which can be identified by attackers. Much more
obvious traces are also left, such as /etc/rc.d/init.d/dualconf, "Copyright
(C) 1998-99, VMware Inc." and the /etc/vmware-tools/ directory. It is
advisable to avoid installing VMware tools on VMware honeypots if at all
AMD 1 gigahertz with 32 megabytes of ram?
One problem with VMware is the inability to hide the CPU type effectively,
an astute attacker is likely to wonder why a server with 32 megabytes of ram
has a 1 gigahertz AMD CPU. Unfortunately this is what will happen, and
hiding this fact from an attacker is difficult. An attacker can simply "cat
/proc/cpuinfo" for example under Linux, and among other things they will be
told the speed, approximately, in MHz. Removing /proc support in Linux is
one way to deal with this, but there are other ways to query cpu speed, and
in other operating systems hiding the cpu type and speed is not so easy.
One way to identify VMware systems is by their BIOS, there are a number of
free windows utilities that can query the BIOS for information and even
extract a copy of the BIOS from the VMware system. The good news is that
from within Windows NT/2000 you cannot easily access the BIOS and send
commands as direct access to the hardware is blocked. You can however easily
query the BIOS for information from within the guest operating system you
will be given the following information:
BIOS ID: unknown
BIOS Date: 10/16/01
BIOS Signon: unknown
BIOS Type: PhoenixBIOS 4.0 Release 6.0 licensed to Intel
Super I/O: unknown
Chipset: Intel 440BX/ZX rev 1Which is quite different then the actual BIOS
in use on the host operating system.
As well there are a number of utilities to make a copy of the bios, BIOS
Wizard is available for free and can easily make a copy of the system bios,
considering that the BIOS VMware uses is relatively unique it becomes quite
easy to check a signature of the BIOS file to see if it is a VMware BIOS.
Unfortunately there is almost no way to hide this information from a savvy
attacker, making it an Achilles' heel for VMware honeypot systems. Both
these utilities are available from:
http://www.bioscentral.com/misc/downloads.htm. There is a utility for Linux
and BSD at: http://www.cgsecurity.org/.
Kurt Seifried, kurt () seifried org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
- 4tphi: Detecting VMWare Andrew Hintz \(Drew\) (Nov 08)
- <Possible follow-ups>
- RE: RE: 4tphi: Detecting VMWare Bridges Lloyd (Nov 11)