Results 1 to 10 of 10

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

  1. #1
    Senior Member
    Join Date
    Jan 2003
    Posts
    3,915

    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.

    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

  2. #2
    T3h Ch3F
    Join Date
    Sep 2001
    Posts
    718

    Responsability.

    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:
    Get some good religion from Bad Religion.

  3. #3
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Location
    Beverwijk Netherlands
    Posts
    2,534
    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 !!
    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  4. #4
    Senior Member
    Join Date
    Feb 2004
    Posts
    270
    So how about a option to turn the backdoor interface in the vm off ?

    This would get rid of the problem correct ?
    Since the beginning of time, Man has searched for the answers to the big questions: \'How did we get here?\' \'Is there life after death?\' \'Are we alone?\' But today, in this very theatre, you will be asked to answer the biggest question of them all...WHO LIVES IN A PINEAPPLE UNDER THE SEA?

  5. #5
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  6. #6
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    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
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  7. #7
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    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.
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  8. #8

  9. #9
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    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.
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  10. #10
    Senior Member
    Join Date
    Oct 2002
    Posts
    1,130
    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.
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •