Re: Know Your Enemy: Learning with VMware

[Jeremy Bennett <jeremy () deities org>]

Bill McCarty wrote:
> --On Monday, January 27, 2003 7:00 PM +0100 Alexandre Dulaunoy
> <adulau () foo be> wrote:
>
>
> > ... Another  point  is  the  fingerprint   of  the  VMware
> > hardware. How do you  solve that issue ? Is it a  way to do change the
> > hardware description in VMware ? 
>
>
> Apparently, your notion is that a production host would not likely be
> running VMware, and therefore the presence of VMware must be masked in
> a honeynet designed to attract skilled attackers. However, that notion
> isn't always accurate. 
>
> In particular, VMware offers an enhanced version of their product,
> VMware ESX, that's designed for data centers and other high
> availability applications. VMware ESX is available from VMware, as you
> might expect. However, VMware ESX is also sold by IBM, bundled with IBM
> servers based on Intel x86 processors. So, some of the juiciest
> potential targets for attackers are running VMware.

Reality is less important than perception. Though generally applicable 
to honeypots this rule is particularly interesting now. The fact that 
some companies are running production hosts on VMWare and UML is a fact. 
The perception by the attacker community, though, is that this practice 
is rare and thus any system that can be fingerprinted as VMWare is more 
likely to be a honeypot than a system that does not fingerprint as a 
honeypot. When running production services from within VMWare becomes 
common practice then VMWare honeypots will be a great solution. Until 
then fingerprinting remains an issue.

This is much akin to Fred Cohen's idea that we would all deploy DTK on 
honeypots and then use a null listener on the DTK control port on every 
other system.
> A deeper question, I think, is the degree to which VMware's
> virtualization is itself resistant to attack. The possibility exists
> that an attacker may be able to escape a virtual host and obtain access
> to the associated physical host. However, this risk is not peculiar to
> VMware. UML and other emulation or virtualization technologies would
> seem to share this risk.

The fact of the matter is that none of the current virtualization 
solutions are designed to be resistant to attack. They are designed to 
be the best emulation possible. As such they do not provide the same 
rich set of control capabilities provided in a dedicated honeypot 
solution. A VMWare (UML, etc) honeypot should be treated like any other 
sacrificial lamb. Protection should be placed on-host as well as off-host.

VMWare and friends, in my opinion, make good platforms for testing and 
demoing honeypots but today they are not a great solution for live systems.

-J