VM Detection --> A New Way to Defeat Testbeds?

Hey Hey,

My roommate mentioned this to me about a week ago and I hadn't seen any mention of it here, so I thought I'd pots it.

Basically someone has created a small segment of code that allows the software to determine if it's running on a real computer or in virtual machine hardware such as VMWare or Virtual PC.

Quote:

---

Both Virtual PC and VMWare allow you to install "add-in"s to accelerate emulation, allow drag-n-drop from your real desktop to your virtual desktop, and allow file sharing between your real machine and the virtual machine.

In order to accomplish this task, a communication mechanism between the virtual machine software and the virtual machine itself must exist.

This sort of interfacing is called a "backdoor interfacing", since, using a special/undocumented mechanism, certain commands can be carried and interpreted in a different manner (by the virtual machine software) unlike having them interpreted by the real machine.

Next, I'll be covering how you can tell whether your software is being executed using a real machine or a virtual machine software (covering both Virtual PC and VMWare).

---

The article goes on to cover how to detect both instances of software, including the code to do it and an explanation of how to implement the code.

What kind of problems does this create for user that create VM sandboxes and test beds. The malware can now trick the user and lie dormant. Will we now see malware that lies dormant in a VM but comes to life and spread quickly and damages much when running on the host OS? Has anyone seen any software yet that is implementing this code and is it something we have to look forward to in the future?

Anyways... what do ya think? Check out the full article at http://www.codeproject.com/system/Vm...asp?print=true

Peace,
HT

Greets Regz.


Cool, yet..............Convenient.


IMO, I think the risk begins on the users lap(top). Kinda like the Movie Tron.

If you are willing to accept the convenience, you should be willing to deal with the consequences. In so many cases technology is offered to the ignorant, without question.

That is why you techies have jobs! hehe Cool concept, yet I would never allow it as Admin of Morons.


The word "Virtual" has always made me wonder.


Good info.

P:

What about abusing the "backdoor interface"..

I have heard about some software doing nasty things on old versions of VMWare..

I'd think someone might come up with dedicated VM malware !!

So how about a option to turn the backdoor interface in the vm off ?

This would get rid of the problem correct ?

It would be generally very nasty for malware to be able to detect a virtualised environment (Vmware, MSVPC, Qemu etc), because that's usually what the AV companies use to test it.

With the ability to detect such an environment, the company would have to instead use an emulator (such as bochs) which would be extremely slow.

One trivial way to detect a virtualiser or emulator would be to read the BIOS strings, which would have something like "Qemu", "Bochs", "Microsoft VPC", "Vmware" etc, if they were inside the virtualiser.

However this is easier to defend, as you could simply use a patched BIOS on your virtualiser that said "AWARD BIOS" instead.

Some virtualiser vendors provide specialised device drivers for guest OSs - for example, Microsoft VPC has a display driver for Window which provides various extra features.

This would be easily detectable by malware. However, it is typically optional.

It would be compelling for a malware author to detect a virtualiser and ensure that their malware does as little as possible in a virtualised environment (unless he has found a way of breaking out of the virtualiser, in which case it can proceed to infect the host)

Slarty

Joanna Rutkowska, the sexy Polish hacker wrote "redpill" a while a go for this.
Her's I believe detects almost any VMM w/o the VMWare communcication trick. http://invisiblethings.org/papers/redpill.html
She's a regular on rootkit.com and is also the the author of klister (for discovering hidden W32 processes) and some other neet stuff.

-Maestr0

Vmware and VPC use the same idea that IBM had implemented on its VM project 30 years ago (or more).
so they allways use one of these communication mechanism between host and guest:
1) unused opcode
2) special I/O instructions
Even you dont install vmware/vpc "special drivers", the support will be allways there, just like the IBM structure. Since IBM mainframes use this for years, and some companies use VM to provide infrastructure to several companies on the same phisical hardware, i dont think that the communication is a vulnerability per se; is more how the interface was written .

If a malware detects that its running in a containers (a virtual machine) doesnt expose the real machine to any danger, except if the communication was bad designed.

Just for example, VPC uses that interface for graphical acceleration (as VMWare). So what? A malware can only use it in a bad way if it has a crappy coding.

BTW, even you dont have any interface, you may detect the VM just by hardware behavior, since some timing functions doesnt appear exactly like in a real hardware. A L1/L2 cache performance tool can easly detect that "something is wrong", since it can detect the processor (VM allow that) but the cache timing will be totally wrong since some priviledge instructions are been emulated.

Defeating Honeypots
http://www.securityfocus.com/infocus/1826
http://www.securityfocus.com/infocus/1805

UML, jail, chroot, VMWare are looked at

Soda just posted good info, including details about Vmware communication interface <--- i dont agree call that a "backdoor".
However i didnt find (that isnt equal to "doesnt exist" :) ) a way to use communication interface to break the VM cage.
Even about honeypot, an O.S. running into a VM doesnt mean a honeypot system; i run some in production (SOHO) under VM. And VMWare has a specific supervisor (ESX) that is used to host "heavy" servers on MP hardware.

Horse alerted me to redpill a while ago, since I do most of my testing inside vmware machines. I have tested the redpill code and it does indeed work. There is, unfortunately, no easy way around this little snippet. It works by detecting the address of a particular processor instruction which only exists in one place on a real processor. Since vmware essentially creates two machines on one processor, it must relocate this instruction for the purposes of the guest machine. This code is designed to detect the location of that instruction. If it not where it would be on a normal processor, a vmware instance is detected. To defeat this code one would have to program vmware to report false memory addresses, which could create a plethora of memory access violations with other software.

I have not seen as of yet any method by which you could exploit this code to actually break out of a vmware instance, although I am told that they do exist. Such an attack would be quite dangerous, since vmware is always running with root (or administrator) privileges as it requires direct access to the hardware. Any compromise of the vmware software would spell a complete compromise of the machine without the need for further privilege escalation, thus limiting the time you have available for a response. The code could, however, at the least, be used to identify machines which would be prime targets for attack, again lessening the time required for a successful attack.

A vmware compromise would mean the compromise of *every* virtual host running on that machine. If I own your vmware machine, I own every host running on it.